Инкапсуляция vs Агрегирование , размышления в различных реализациях (языках программирования)

Цитата Wound @ 19.10.19, 19:41

Пример можно?

Нет, все ж привыкли строить иерархии наследования. Хотя, HTML, например, близок: только тэги и их атрибуты, никакого наследования.

Цитата Wound @ 19.10.19, 19:41

Глобальную переменную легко переписать нечаяно в каком то другом месте.

Нечаяно можно и метод в базовом классе поменять и поломать всё к чертям.

Цитата Wound @ 19.10.19, 19:41

Хотя и их используют там, где они оправданы, синглтон никто не отменял

Синглтон — антипаттерн уже давно.

Цитата Wound @ 19.10.19, 19:41

вот есть у меня класс Checkbox : public Button, у класса checkbox я реализовал функцию отрисовки, все. Теперь у меня есть checkbox, который имеет все те же методы что и кнопка, но выглядит по другому.

Вот и по рукам тебе за такой класс надавать. CheckBox — это не Button.

Цитата Wound @ 19.10.19, 19:41

Как это будет выглядеть с агрегированием?

CheckBox = Pane { check ; label }

Цитата Wound @ 19.10.19, 19:41

Чтоб у чекбокса были все те же методы?

Какие те же? Зачем CheckBox'у методы Button'а? Ты про click/keypress/etc? Так это не методы Button'а. Ещё раз посмотри на HTML: на любой элемент можно повесить onclick-обработчик, например.

Цитата Qraizer @ 19.10.19, 21:23

Я бы с удовольствием это выдумал, но увы, приходится цитировать.

И кого же ты процитировал?

Добавлено 22.10.19, 21:07

Цитата Wound @ 22.10.19, 17:59

В чем заключается говнокод?

В том что нет ISP.

Вместо

interface Vehicle
{
}
 
interface WheelVehicle : IVehicle
{
}
 
interface FlyingVehicle : IVehicle
{
}

Хотя бы

interface Vehicle
{
}
 
interface Ground
{
}
 
interface Flying
{
}

Почувствуй разницу.

P.S.

Как же раздражает ииотская шарповая нотация

interface I<name>

Сообщение отредактировано: korvin - 22.10.19, 21:07

Цитата korvin @ 22.10.19, 21:01

Нет, все ж привыкли строить иерархии наследования. Хотя, HTML, например, близок: только тэги и их атрибуты, никакого наследования.

HTML - это язык гипертекстовой разметки, если чего. Как ты его увязал с ЯП, не понимаю.

Цитата korvin @ 22.10.19, 21:01

Нечаяно можно и метод в базовом классе поменять и поломать всё к чертям.

С глобальной переменной это сделать проще.

Цитата korvin @ 22.10.19, 21:01

Синглтон — антипаттерн уже давно.

Незнаю, вот у меня перед глазами лежит книга "Приемы Объектно-Ориентированного проектирования. Паттерны проектирования" за авторством: Э.Гамма, Р.Хелм, Р.Джонсон, Д.Влиссидес.
Синглтон описывается на странице 130. Обозначен как паттерн проектирования

Цитата korvin @ 22.10.19, 21:01

Вот и по рукам тебе за такой класс надавать. CheckBox — это не Button.

С чего вдруг? Между прочим, в некоторых фреймворках, чекбоксу можно сделать стиль PressedButton, т.е. меняется только отрисовка - вжатая/отжатая кнопка, либо галочка - есть/нет. В остальном него точно такие же методы как и у кнопки, ну разве что вводятся дополнительные свойства - Checked/Unchecked

Цитата korvin @ 22.10.19, 21:01

CheckBox = Pane { check ; label }

Примитивный пример. Я уже давал на этот счет пояснения тут: Инкапсуляция vs Агрегирование (сообщение #3813134)
И если label понятно что это такое, то что такое check - остается только догадываться. Никогда не встречал такого класса Даже в HTML он идет как checkbox

Цитата korvin @ 22.10.19, 21:01

Какие те же? Зачем CheckBox'у методы Button'а? Ты про click/keypress/etc? Так это не методы Button'а. Ещё раз посмотри на HTML: на любой элемент можно повесить onclick-обработчик, например.

Да причем тут HTML то я никак не пойму? Ты сравниваешь разметку с языком программирования.

Цитата korvin @ 22.10.19, 21:01

В том что нет ISP.

Что такое ISP? Я там написал ниже, что не корректно пример понял, так как изначально комментировал его с телефона, а там у меня не все раскрылось.

Цитата korvin @ 22.10.19, 21:01

Почувствуй разницу.

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

Добавлено 22.10.19, 21:33

Цитата korvin @ 22.10.19, 21:01

Как же раздражает ииотская шарповая нотация

А меня бесят маленькие буквы в методах в Java. Придумали какую то хрень, не пойми зачем, и приходится потом с этим извращаться.

Добавлено 22.10.19, 21:40

Цитата Qraizer @ 22.10.19, 20:00

Хорошо, когда язык поддерживает агрегацию искаропки, да? Вот и ответь теперь, что тебе мешает сделать так же при наследовании реализаций. Гм, ну да... хорошо, когда язык поддерживает множественное наследование реализаций искаропки.

Я стараюсь избегать множественного наследования. Уж очень высока вероятность там поиметь проблемы. Не всегда можно что то учесть.

Цитата Qraizer @ 22.10.19, 20:00

Если сильная связь подразумевается, как в лице гуёвых иерархий, например, когда кнопка она же окно, то наследование не привнесёт дополнительного дисбаланса в архитектуру. Переделывай базовый класс окна на здоровье, кнопки автоматом подхватят все модификации, и разве не это ожидается в итоге?

Ну так я не против этого. Просто почитал про это. Народ везде пишет что фигня все это, типа больше проблем, чем пользы. Но лично вот я не понимаю, как тогда ГУИ писать. Вон korvin Знает, у него все просто
Берешь и делаешь как в HTML.

Сообщение отредактировано: Wound - 22.10.19, 21:46

Цитата Wound @ 22.10.19, 21:32

HTML - это язык гипертекстовой разметки, если чего. Как ты его увязал с ЯП, не понимаю.

На этом языке разметки уже давно клепают UI. Ну да, +JS для поведения. При чём тут ЯП, когда речь шла о UI, не понятно.

Цитата Wound @ 22.10.19, 21:32

С глобальной переменной это сделать проще.

Конечно. Как и многое другое.

Цитата Wound @ 22.10.19, 21:32

Незнаю, вот у меня перед глазами лежит книга "Приемы Объектно-Ориентированного проектирования. Паттерны проектирования" за авторством: Э.Гамма, Р.Хелм, Р.Джонсон, Д.Влиссидес.
Синглтон описывается на странице 130. Обозначен как паттерн проектирования

Библию ещё положи.

Тебя не смущает, что книга 1994-го года, а на дворе 2019-й? И что это не Конституция РФ и тем более не учебник по алгебре, например?
https://www.michaelsafyan.com/tech/design/patterns/singleton

Цитата Wound @ 22.10.19, 21:32

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

Обычно это ToggleButton, который к чекбоксам никакого отношения не имеет, кроме как обеспечения такой же смысловой нагрузки: On/Off (Checked/Unchecked, и т.п.) — представления булевого свойства. Ты стиль наследуешь или поведение? Ну да, в этих ваших фреймворках часто представление и семантика слиты в один класс. Каша, да и только. Потом наследуете мух от котлет и наоборот.

Цитата Wound @ 22.10.19, 21:32

ну разве что вводятся дополнительные свойства - Checked/Unchecked

«Дополнительные»? Лол, это и есть вся его смысловая нагрузка, определяющая суть чекбокса как элемента интерфейса.

Цитата Wound @ 22.10.19, 21:32

то что такое check - остается только догадываться. Никогда не встречал такого класса

Это то маленькое окошко, где ставится галочка.

Цитата Wound @ 22.10.19, 21:32

Даже в HTML он идет как checkbox

Потому что там checkbox — готовый примитив, который, кстати, не наследуется от button.

Цитата Wound @ 22.10.19, 21:32

Да причем тут HTML то я никак не пойму? Ты сравниваешь разметку с языком программирования.

При чём тут язык программирования? Мы о UI фреймворках/тулкитах говорим. HTML+CSS+JS — это UI-тулкит.

Цитата Wound @ 22.10.19, 21:32

Что такое ISP?

Interface Segregation Principle.

Цитата Wound @ 22.10.19, 21:32

И в чем разница? В других именах? Если сущность одна, и у тебя есть такие же, но более конкретизированные, почему не унаследовать?

Flying может быть не только Vehicle. Ты внимательней прочитай.

Цитата Wound @ 22.10.19, 21:32

А меня бесят маленькие буквы в методах в Java. Придумали какую то хрень, не пойми зачем, и приходится потом с этим извращаться.

А маленькие буквы в именах полей в C# тебя не бесят? Нахера вы захламляете имена идиотскими префиксами? У классов префикс C пишете? А у абстарктных классов — AC? А если публичный, нужно P добавлять? А S к sealed?

Цитата Qraizer @ 22.10.19, 20:00

Тут хоть ставь virtual, хоть не ставь – всегда найдётся фэйл-сценарий

Написал незафэйленный сценарий:

#include <iostream>
using namespace std;
 
struct IBaseInterface {
  virtual void madeMeCool() = 0;
};
    
struct ICoolInterface : IBaseInterface {
  /* тут что-то оригинальное  своё */
  virtual void madeMeCool() override {
    cout << "ICoolInterface сделал cool\n";
  }
};
 
struct ICoolerInterface: IBaseInterface {
  /* тут что-то совсем другое своё */
  virtual void madeMeCool() override {
    cout << "ICoolerInterface тоже сделал cool\n";
  }
};
    
struct CCoolImpl: virtual ICoolInterface, virtual ICoolerInterface {
  /* всё сделано по правилам, и ничего, как говорится, не предвещало */
  virtual void madeMeCool() override {
    ICoolInterface::madeMeCool();
    ICoolerInterface::madeMeCool();
    cout << "CCoolImpl сделал cool вдогоночку\n";
  }
};
 
int main() {
  CCoolImpl cool;
  cool.madeMeCool();
  return 0;
}

И как его зафэйлить? Приведи пример, плс.

Скрытый текст

Цитата korvin @ 22.10.19, 21:01

Как же раздражает ииотская шарповая нотация

Она как минимум дельфийская

Сообщение отредактировано: OpenGL - 23.10.19, 04:27

Цитата korvin @ 22.10.19, 22:30

На этом языке разметки уже давно клепают UI. Ну да, +JS для поведения. При чём тут ЯП, когда речь шла о UI, не понятно.

Не только на этом языке разметки клепают UI, это во первых. Потому как в практически любой ОС, есть окна/диалоги и т.п. которые работают не через HTML, а ты говоришь судя по всему исключительно про Web, только причем он тут?

Цитата korvin @ 22.10.19, 22:30

Тебя не смущает, что книга 1994-го года, а на дворе 2019-й? И что это не Конституция РФ и тем более не учебник по алгебре, например?
https://www.michaelsafyan.com/tech/design/patterns/singleton

Нет не смущает Может быть и SOLID тогда устарел и его нужно в топку выкинуть? А то ему тоже уже под 20 лет.

Цитата korvin @ 22.10.19, 22:30

Обычно это ToggleButton, который к чекбоксам никакого отношения не имеет, кроме как обеспечения такой же смысловой нагрузки: On/Off (Checked/Unchecked, и т.п.) — представления булевого свойства. Ты стиль наследуешь или поведение? Ну да, в этих ваших фреймворках часто представление и семантика слиты в один класс. Каша, да и только. Потом наследуете мух от котлет и наоборот.

Ну давай посмотрим как это в HTML описывается: https://www.w3schools.com/tags/att_input_type_checkbox.asp

HTML <input type="checkbox">

input?
А чего не checkbox ?

Цитата korvin @ 22.10.19, 22:30

«Дополнительные»? Лол, это и есть вся его смысловая нагрузка, определяющая суть чекбокса как элемента интерфейса.

Я с тобой не соглашусь, потому как помимо Checked/Unchecked - ему хорошо бы иметь все те же методы, что имеет кнопка. Нажать/Отпустить/Отрисовка/MouseMove и т.д. Зачем писать повторно все тоже самое, что ты будешь писать для кнопки какой нибудь? Дублирование кода на лицо получается.

Цитата korvin @ 22.10.19, 22:30

При чём тут язык программирования? Мы о UI фреймворках/тулкитах говорим. HTML+CSS+JS — это UI-тулкит.

Причем тут HTML+CSS+JS, мы о Веб не говорим(я так точно о нем не говорил), а ты приводишь Веб. Зачем рассматривать Веб, если речь идет о ГУИ фреймворках языков программирования?

Цитата korvin @ 22.10.19, 22:30

Interface Segregation Principle.

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

Цитата korvin @ 22.10.19, 22:30

Flying может быть не только Vehicle. Ты внимательней прочитай.

В реальной жизни? Очень может быть. Но обычно проектируют согласно ТЗ. Если ты пишешь какую то программу для управления исключительно транспортными средствами, то например птиц - можно не учитывать.

Цитата korvin @ 22.10.19, 22:30

А маленькие буквы в именах полей в C# тебя не бесят?

Это как тут что ле: http://hg.openjdk.java.net/jdk8/jdk8/jdk/f.../ArrayList.java ?

   private static final long serialVersionUID = 8683452581122892189L;
 
    ...
 
    /**
     * The size of the ArrayList (the number of elements it contains).
     *
     * @serial
     */
    private int size;

Цитата korvin @ 22.10.19, 22:30

Нахера вы захламляете имена идиотскими префиксами? У классов префикс C пишете?

По поводу префиксов - необязательно так делать. Я думаю так делают в основном С++сники, я вот не помню какую книгу по шарпам читал, так там автор говорил что поля могут совпадать с входными значениями, и никакого криминала в этом нет, более того, даже принято вызывать поля через this. Ну что то типа там:

public class SomeClass
{
   private int speed;
   SomeClass(int speed)
   {
      this.speed = speed;
   }
}

На сколько я знаю С++сники не любят писать this, поэтому видимо придумали название полей с подчеркивания писать. Ну типа чтоб не писать длинный this. и при этом чтоб было понятно что это поле класса, а не какая то левая переменная в методе или из параметров. По поводу префикса C у класса - это тоже дело рук С++сников, ЕМНИП, а пошло это еще из классов MFC, и венгерской нотации.

Цитата korvin @ 22.10.19, 22:30

А у абстарктных классов — AC? А если публичный, нужно P добавлять? А S к sealed?

Ну это ты уже сам придумал.

Цитата Wound @ 22.10.19, 19:19

Ну вот везде пишут - что такого, что ты предлагаешь надо избегать. Если будут переделки в базовых класах - то это повлечет кучу проблем. Лично я не люблю делать такие большие иерархии наследования. Слишком запутанно получается, слишком большая связанность классов. На лицо нарушение принципов SOLID.

Ну вот возьмем цепочку классов:

interface IEvent
{
  IEventType EventType {get;}
  string Textoverlay {get;}
  string AlarmMessage {get;}
  IDatabaseDto DatabaseDto {get;}
  ну и еще пара пропертей
}
 
class abstract ShoeEvent : IEvent
{
}
 
class abstract GameEvent : ShoeEvent
{
}
 
class abstract CardDrawEvent : GameEvent
{
  Rank Rank { get; }
  Suit Suit { get; }
...
 
  string Textoverlay {get { реализация } }
  string AlarmMessage {get { реализация } }
  IDatabaseDto DatabaseDto {get { реализация } }
}
 
class DiscardCardEvent : CardDrawEvent
{
}
 
class PlayerCardEvent : CardDrawEvent
{
}
 
class BankerCardEvent : CardDrawEvent
{
}

как тут можно заменить наследование агрегацией?
Ну в данном примере (в том виде, как показано тут) ShoeEvent и GameEvent можно заменить интерфейсами. А вместо DiscardCardEvent, PlayerCardEvent и BankerCardEvent можно сделать enum. Но ведь это не агрегация

Цитата Wound @ 22.10.19, 19:19

Я не знаю всей специфики твоей задачи, но обычно всякие ивенты решаются с помощью шаблона Посетитель(Visitor) или Наблюдатель(Observer). Возможно тебе нужно пересмотреть дизайн. Слишком много у тебя наследования. ИМХО.

Пересмотреть дизайн - это написать все с нуля Тут коду больше 10 лет и сейчас сделан один класс, который отвечает за все. Недостатком такой структуры является то, что Textoverlay, AlarmMessage и DatabaseDto живут "вне" эвента в результате для обработки всего этого добра пишется куча ненужного кода.

Сообщение отредактировано: Fester - 23.10.19, 08:05

Цитата Fester @ 23.10.19, 08:00

как тут можно заменить наследование агрегацией?
Ну в данном примере (в том виде, как показано тут) ShoeEvent и GameEvent можно заменить интерфейсами. А вместо DiscardCardEvent, PlayerCardEvent и BankerCardEvent можно сделать enum. Но ведь это не агрегация

Очень просто, то от чего ты наследуешься - делаешь полем класса + в конструктор параметр прокидываешь. Я не знаю специфики твоей задачи, но у тебя слишком много наследования в твоей иерархии классов. Может быть проще какой нибудь Visitor прикрутить или Наблюдатель там? Почему ты не хочешь пресмотреть свою задачу и юзнуть шаблоны проектирования, вместо бездумного наследования. У тебя потом по ходу работы, всплывет какая то хрень, и будешь ты костыли лепить к этой иерархии, и писать еще больше наследования.

Цитата Fester @ 23.10.19, 08:00

Пересмотреть дизайн - это написать все с нуля Тут коду больше 10 лет и сейчас сделан один класс, который отвечает за все. Недостатком такой структуры является то, что Textoverlay, AlarmMessage и DatabaseDto живут "вне" эвента в результате для обработки всего этого добра пишется куча ненужного кода.

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

Цитата Fester @ 22.10.19, 11:12

хммм... заходим на hh.ru и вбиваем "разработчик D"
Ну нахрен этот D

И какое это имеет отношение к обсуждаемой теме? И D не уникален в этом плане. Ruby и PHP тоже умеют обрабатывать вызовы несуществующих методов и при желании можно проксировать их в агрегируемый объект.

Цитата Wound @ 22.10.19, 15:28

Ну речь зашла о том, что наследование классов - это всегда плохо. Лучше ее избегать всегда и везде, где это возможно. И только если уж совсем приспичит, то можно оставить, и то с нацелом на то, чтоб потом переписать.

Ну, по крайней мере на этом форуме, полагаю, никто так не считает.

Цитата Wound @ 23.10.19, 07:56

По поводу префиксов - необязательно так делать. Я думаю так делают в основном С++сники,

Нет, классические C++сники так не делают. Посмотри boost и стандартную либу - никаких префиксов.
Префиксы это другая болезнь - Microsoft Головного Мозга.

Сообщение отредактировано: applegame - 23.10.19, 08:38

Цитата Wound @ 23.10.19, 08:07

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

Но рано или поздно мне надо будет отправить, скажем, Textoverlay. Т.е. конечный класс должен имплементировать этот интерфейс чтобы я "разматывать" цепочку агрегаций.

Цитата Wound @ 23.10.19, 08:07

Может быть проще какой нибудь Visitor прикрутить или Наблюдатель там?

Может и проще, но для этого надо все переписать. Сейчас сделано в лоб - пришел евент -> добавили эвент в игру -> проверили нарушаются ли правила (их штук 10), если нарушаются, то создали соответствующий эвент -> отправили все (начальные и созданные) на отправку в подсистемы (сохранение в БД, отправка Textoverlay, сообщение о нарушениях итд). Т.е. наверное это ближе к наблюдателю, но переделывать существующий код никто не даст.

Цитата Wound @ 23.10.19, 08:07

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

Рефакторингу не подлежит, т.к. там сейчас вообще нет никакого дизайна Все делается в лоб. Грубо говоря, есть класс, который отвечает за отправку данных на все подсистемы. Так вот в этом классе есть поле Textoverlay, которое заполняется по мере обработки сообщения, потом, когда вызывается вункция "отправить все на подсистемы", берется поле Textoverlay и отправляется куда надо и сколько надо раз. После чего содерживое поля обнуляется

Цитата Fester @ 23.10.19, 08:50

Но рано или поздно мне надо будет отправить, скажем, Textoverlay. Т.е. конечный класс должен имплементировать этот интерфейс чтобы я "разматывать" цепочку агрегаций.

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

Цитата Fester @ 23.10.19, 08:50

Может и проще, но для этого надо все переписать. Сейчас сделано в лоб - пришел евент -> добавили эвент в игру -> проверили нарушаются ли правила (их штук 10), если нарушаются, то создали соответствующий эвент -> отправили все (начальные и созданные) на отправку в подсистемы (сохранение в БД, отправка Textoverlay, сообщение о нарушениях итд). Т.е. наверное это ближе к наблюдателю, но переделывать существующий код никто не даст.

Ну тут можно только посочувствовать.

Цитата Fester @ 22.10.19, 19:11

важна конфиругация кузова, надпись с названием и цвет обивки

Никаких противоречий! Интерфейсы определяют "поведение" (или "способность поведения"), а праперти - "состояние".
Цвет - это состояние. Конкретная конфигурация - это состояние.

Цитата Fester @ 22.10.19, 19:11

Другое дело, что все это логично было добавлять агрегацией, а не наследованием

Вот тут я полностью согласен с Килей, он как-то пару листов назад расписал условия, когда нужно руководствоваться здравым смыслом и опираться на отношения "является" или "имеет". По факту:

1) Наследование используется, если имеем отношение "является"
2) Агрегация или композиция используются, если имеем отношение "имеет"

При агрегации что-то конструируем во-вне класса и сконструированное передаем в виде параметра конструктору.
При композиции конструируем нужное с самом классе.

Ну как-то так вроде, если я все правильно понял.

Цитата JoeUser @ 23.10.19, 09:03

Вот тут я полностью согласен с Килей, он как-то пару листов назад расписал условия, когда нужно руководствоваться здравым смыслом и опираться на отношения "является" или "имеет". По факту:

1) Наследование используется, если имеем отношение "является"
2) Агрегация или композиция используются, если имеем отношение "имеет"

При агрегации что-то конструируем во-вне класса и сконструированное передаем в виде параметра конструктору.
При композиции конструируем нужное с самом классе.

Ну как-то так вроде, если я все правильно понял.

Ну тут еще есть всякие оговорки, типа если у тебя отношение "является", но при этом дочерний класс замещает методы базового, или вообще не использует их, то такое наследование - плохое, ибо чревато проблемами. И тут надо уже вводить агрегирование, либо пересматривать дизайн.
В идеале наследование подходит там, где у тебя отношения "is a" плюс ко всему дочерний класс будет исключительно добавлять новую функциональность и вообще не будет замещать методы базового класса.
Называется это вроде Принцип подстановки Барбары Лисков

Сообщение отредактировано: Wound - 23.10.19, 09:10

Цитата Fester @ 23.10.19, 08:50

Грубо говоря, есть класс, который отвечает за отправку данных на все подсистемы. Так вот в этом классе есть поле Textoverlay, которое заполняется по мере обработки сообщения, потом, когда вызывается вункция "отправить все на подсистемы", берется поле Textoverlay и отправляется куда надо и сколько надо раз. После чего содерживое поля обнуляется

Цитата Wound @ 23.10.19, 09:09

Ну тут еще есть всякие оговорки

Согласен. Как раз вчера с чьей-то подачи про SOLID читал.