Что выносить в интерфейс, а что оставлять в классе? Критерии? (2 стр)

zlos
> Интерфейс описывает "что может делать объект".
Кажется слишком расплывчато: так можно все методы, через которые происходит взаимодействие с другими объектами\воздействие на свое состояние другими объектами вынести в интерфейсы.
Вопрос ко всем. Может тогда поделитесь опытом? Примеры какие-нибудь - без кода, просто на уровне понимания.

да все просто... подели себя еще на пользователя кода... пользователь не хочет знать ничего лишнего... названия функций для него тоже важны, но слишком длинные - выглядят страшно...

вот заглядывает он в заголовочный файл, типа ему пришлось, потому шо нет референса, ты не написал его... и что он там видит?... и что поймет?...
ведь краткость - сестра ясности...

еще имей в виду - что ты спрашиваешь то, чему сразу не научишься... это постепенно с опытом... это наведение порядка, простоты, надежности...
оно постепенно... программишь, программишь... потом тебе вдруг хочется где-то порядок наконец навести уже... потому самому уже в память не помещаются сложные взаимосвязи, а комменты лень писать всегда...
и вот это желание - результат накопленного опыта, рекомендации слишком опережающие собственные умения - не очень помогают...
упрощение кода - это в многом работа над архитектурой его внутренних интерфейсов...

loonypy
> жется слишком расплывчато: так можно все методы, через которые происходит взаимодействие с другими объектами\воздействие на свое состояние другими объектами вынести в интерфейсы.

Есть два понятия - наследование и агрегация. Так вот, агрегация имеет приоритет, пока не упирается в производительность, тогда бывает от нее отказываешься. Если у поля появляются новые свойства - он просится в собственный объект со своим функционалом.

Я проектирую классы от состояния объекта. То есть:
1) Полный инвариант объекта должен быть всегда, без этого будет сложно.
Инвариант -> состояние объекта четко определено. То есть ты лочишь объект, изменяешь его свойства (в четко определенном допустимом интервале), снимаешь лок.
+ Легко применять в потоках, легкая сериализация.
+ Читаемость и легкое использование кода.
+ Меньше кода пишешь для использования класса (вот где зарыт главный критерий для класса - класс должен очень легко использоваться и по возможности не давать выстрелить себе в ногу).

- Надо думать как написать.

2) МИНИМАЛЬНО необходимый функционал.
Если часть функционала общая - следует скрыть ее от пользователя в реализации, обращаясь к другому классу внутри.

>Может тогда поделитесь опытом?
Есть два способа.
Попроще - пересадить мозг.
Посложнее - книги почитать.
Мы не ищем легких путей!

Не забываем об использовании бритвы Оккама.
Задумайтесь, нужны ли в вашей программе классы вообще? Можно ли написать такой же по функционалу код без классов или на 1 класс меньше? Если да - то выбросьте этот лишний класс. Пишите только код, необходимый сегодня для вашей программы, не закладывайте возможности расширения на 5 лет вперёд, вероятно ваш проект не будет развиваться так долго и либо будет переписан либо останется как есть на долгие годы.
Задумайтесь, нужны ли интерфейсы, или достаточно просто описать класс и пару наследников. Если интерфейс не нужен - выбросьте.
Задумайтесь, будет ли ваша программа расти настолько, насколько вы закладываете в неё потенциал, добавляя интерфейсы. Это миф, то что интерфейсы делают расширение класса более легким - ничего подобного, чем дальше тем сложнее. И поэтому более простые классы всегда имеют преимущество над более сложными, а тем более над сложными абстрактными интерфейсами.

>И поэтому более простые классы всегда имеют преимущество над более сложными, а тем более над сложными абстрактными интерфейсами.
Boost.org опровергает Вас чуть более чем полностью )))

CasDev
> > поэтому более простые классы всегда имеют преимущество над более сложными, а
> > тем более над сложными абстрактными интерфейсами.
> Boost.org опровергает Вас чуть более чем полностью )))
Ну разве что как объект искусства, иногда, по нелепому совпадению, немного полезный, но не более. Сам пользовался, знаю.
В индустрии успех получают не самые сложные и изящные решения, а максимально простые и достаточные. Ключевое слово - достаточные.

простота - это искусство надежности...
а достаточность типа - отражение разумности...

kvakvs
Да это я так... В порядке стеба.
На самом деле полностью согласен.

loonypy
> Кажется слишком расплывчато: так можно все методы, через которые происходит
> взаимодействие с другими объектами\воздействие на свое состояние другими
> объектами вынести в интерфейсы.
> Вопрос ко всем. Может тогда поделитесь опытом?
Это достаточно просто. К примеру интерфейс описывающий что это объект умещий читать байты:

interface IRead {
  int Read(void *buffer, int size);
  int Tell()const;
  void Seek(int position, Origin origin);
}

Описывает что можно читать байты, узнавать текущее положение и перемещать указатель чтения. Не говорит ничего как оно это делает и как устроено. Клиенту это знать не надо.

так вот... что такое надежность?... это например невозможность объектов разрушать друг друга, по причине слишком открытых друг-другу кишок...
разрушить то из принципа - завсегда можно... но чиста случайно, из-за не продуманной архитектуры - это случается в тыщи раз чаще...
настоящий и самый постоянный хакер - это человеческая не внимательность... ее и надо учитывать в архитектуре интерфейсов...

а в начале карьеры - опираться на общие правила... а конкретные сами прирастают с опытом...

одно из общих правил... абсолютно достаточный минимум параметров - и является оптимумом...
все что может сделать функция самостоятельно - ей надо делать самостоятельно... полнейший из возможных сервисов - просто дать и не грузить...

следом возникает вопрос - а как же универсальность?...

ответ: да ну ее в жопу... тьфу... т.е. - две функции:
одна удовлетворяет 90% тех кому как правило не нужны слишком универсальные возможности...
другая - для настоящих кротов...