Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, np9mi7, Вы писали:
N>>Согласен, например в месте в котором могут быть получены невалидные данные. Так или иначе, метод или функция выполняющая эту проверку завязана на логику point, а значит входит в её интерфейс — это и хотел показать.
К>А вот входит ли валидация в интерфейс — и как она туда входит — это большой вопрос. К>В ряде случаев разумнее сделать внешнюю функцию (или даже набор функций), нежели раздувать интерфейс класса. К>
struct point { int x, y; };
struct point_hlp // or namespace
{
static point transform(const point& pt, int k, int b);
// other static specific functions and static consts
};
struct Point : point
{
void transform(int k, int b) { *this = point_hlp::transform(*this, k, b); }
// other specific functions
};
struct PointRef // optional
{
PointRef(point& pt) : m_pt(pt) {}
void transform(int k, int b) { m_pt = point_hlp::transform(m_pt, k, b); }
// other specific functionsprivate:
point& m_pt;
};
Дальше плодятся классы (или расширяется namespace point_hlp в том месте где нужно) для конкретной задачи (своя валидация, свои специфические ф-ии). Таким образом, интерфес не раздувается, а расширяется в соответствии с потребностями.
Здравствуйте, np9mi7, Вы писали:
N>Мне кажется, что это зависит от задачи.
Да, это очевидно. Но ведь и небыло конкретного вопроса. Была как бы просьба высказать рекомендации по организации (:
Здравствуйте, LaptevVV, Вы писали:
MBy>>Сообственно, мелочный вопрос. В общем случае, так ли должен выглядеть «идеальный» класс? LVV>Слово "идеальный" тут не подходит... Коплиен давно назвал: каноническая форма класса...
Именно потому я и взял это слово в кавычки. Не подходящее, согласен. Написал, что первое в голову пришло.
Ты единственный, кто ответил что-то вразумительное. А то все только прикалываються по-поводу неудачного названия темы (:
S>Безотносительно рассуждений о несостоятельности слова "иделльный" — не нравиться мне ваш клас. Я бы убрал из него protected секцию а всё что в ней отпавил с private
Сообственно, я тоже так всегда делал. Но мой приятель сказал мне, что необходимо писать именно так, как указано в моем вопросе. Посему меня и посетили сомнения, посему я и задал этот вопрос.
Здравствуйте, MBy, Вы писали:
MBy>Сообственно, я тоже так всегда делал. Но мой приятель сказал мне, что необходимо писать именно так, как указано в моем вопросе. Посему меня и посетили сомнения, посему я и задал этот вопрос.
правильно делал, я придержеваюсь следующей рекомендации: клас должен предоставлять интерфецс реализующий абстракцию и максимально скрывать совю реализацию, в том числе и от потомков, само собой "серебряной пули" не существует, но все написанные мною protected методы это всего лиш попытка решить то, чего так и не удалось решить на этапе дизайна-передезайна.
Здравствуйте, remark, Вы писали:
R>Иногда идеальный вариант: R>
R>struct point
R>{
R> int x;
R> int y;
R>};
R>
в текущем проэкте мы встали на подобные грабли воспользовались просто структурой, для просто физического обьединению данных для передачи, положили эти структуры в вектора... — потом когда начали юзать — таки пришли к выводу что всё таки не плохо было бы опереровать абстрактными сучностями...
R>Нет? А Вы поглядите сколько кода надо написать в таком варианте и при полной инкапсуляции. А главное, что эта инкапсуляция даст, кроме увеличения кода?
встречал рекомендацию даже в таком случае делать так... конечно о полной инкапсуляции тут речь не идёт
class point
{
int x;
int y;
public:
int& get_x(){return x;}
int& get_y(){return y;}
};
воспользовались просто структурой, для просто физического обьединению данных для передачи, положили эти структуры в вектора... — потом когда начали юзать — таки пришли к выводу что всё таки не плохо было бы опереровать абстрактными сучностями...