SOLID принципы

всего 5 принципов:
1) srp - класс должен описывать только те характеристики, которые на объект из предметной области возложены. То есть либо кот, либо пес, котопес быть не может.
2) ocp - Писать надо классы так, чтобы их можно было легко расширить, но не изменять
3) Лисков - ???
4) делайте много маленьких интерфейсов, один дольшой интерфейс это плохо. Так как рефакторинг усложняется...
5) Инверсия зависимостей. Типо композицию поменяйте на агрегацию


Я не понимаю принцип Лисков. Можете объяснить популярно?

0

Сообщение от ht1515 4) делайте много маленьких интерфейсов, один дольшой интерфейс это плохо. Так как рефакторинг усложняется...

не верно.

Сообщение от ht1515 Я не понимаю принцип Лисков. Можете объяснить популярно?

https://habrahabr.ru/post/208442/

1

А можно кратко и своими словами, как я?

Добавлено через 55 секунд
Почему неверно? Множество маленьким специализированных интерфейсов, вместо одного большого универсального.

0

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

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

Добавлено через 12 минут
Можно еще проще сформулировать принцип лисков: вся цепочка наследования должна повторять интерфейс верхнего класса(что не исключает расширения интерфейса подклассов, но запрещает изменение интерфейса. Изменение реализации допускается)

1

Сообщение от ht1515 Почему неверно?

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

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

а теперь прочитайте свой первоначальный тезис.

0

Сообщение от ht1515 3) Лисков - ???

Вместо родителей всегда можно использовать наследников. То есть, наследники дополняют поведение родителей, но не меняют.

Сообщение от ht1515 5) Инверсия зависимостей. Типо композицию поменяйте на агрегацию

Нет. Инверсия зависимостей - это когда мы меняем направление зависимостей.
Например, у нас модуль с Кнопкой зависел от модуля с Лампочкой, потому что Кнопка включала Лампочку. Мы переделали Кнопку так, что он включает любой Включабельный объект. Теперь модуль с Лампочкой зависит от модуля с Кнопкой, потому что Лампочка реализует интерфейс Включабельный. Зависимость теперь направлена в противоположную сторону - мы её развернули.

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

0

Сообщение от Shamil1 , у нас модуль с Кнопкой зависел от модуля с Лампочкой

Какой-то невнятный пример. Почему это у Вас кнопка зависит от лампочки, а не наоборот?

Сообщение от Shamil1 потому что Кнопка включала Лампочку.

Это что-то типа "потому что гладиолус".

Вообще говоря, лампочка всегда будет зависеть от кнопки, а не наоборот, потому что лампочка (как и включабельный) -- это пассивная сторона.

Добавлено через 12 минут
Shamil1, если исходить из формулировки в википедии(не настаиваю):

Формулировка:

Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Инверсия зависимости, это какое-то чрезжопное название простейшей вещи: при построении иерархии следует двигаться от общего к частному, но не наоборот. Собственно говоря, каким боком тут слово "инверсия" -- вообще непонятно, тем не менее это явно не о том, о чем вы говорите. Ваш пример -- это всего лишь пример обобщения, если я его правильно понял.

0

Спасибо) асмкуест, вот такое мне объяснение и надо было) чет принцип лисков фуфло какое-то, то есть если в дерайвед классе я не переопределяю интерфейсную функцию, то я нарушил принцип... Ну хз

0

Сообщение от asmquest Вообще говоря, лампочка всегда будет зависеть от кнопки, а не наоборот, потому что лампочка (как и включабельный) -- это пассивная сторона.

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

Сообщение от asmquest при построении иерархии следует двигаться от общего к частному, но не наоборот.

вы с лиской ничего не попутали?

Dependency Invertion вообще не об этом.

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


например:
есть некий клиент для работы с базой данных.
у него есть кучка высокоуровневых методов аля:
"получить список друзей персонажа",
и тп.

что бы реализовать свою функциональность,
клиент внутри себя дергает коннектор к бд,
делегируя ему более низкоуровневые запросы (например - sql)

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

а если кому то понадобится работать с клиентом,
то максимум, что он должен о нём знать - его интерфейс.

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

0

Солид принципы фуфло, но на собеседованиях о них спрашивают ж ...

0

Сообщение от asmquest Вообще говоря, лампочка всегда будет зависеть от кнопки, а не наоборот, потому что лампочка (как и включабельный) -- это пассивная сторона.

Ошибочный принцип для определения кто от кого зависит. Зависит тот кто знает другого. Кнопка должна знать как включить Включабельный объект (абстрактный базовый класс лампочки). Соответсвено кнопка зависит от интерфеса лампочки. Сама же лампочка должна уметь включатся поскольку она влючабельный объект. Но кто дает команду включится ей сугубо без разницы. Соответсвенно от кнопки которая ее включает код лампочки не зависит. Соответсвено включать ее теперь может не только кнопка а к примеру рубильник, таймер и даже телепатор и вообще все кто знают включабелный объект.

Добавлено через 3 минуты

Сообщение от hoggy и чем жёстче, тем проще в нем будет ориентироваться.

Но гораздо сложнее расширять функциональность.

Сообщение от hoggy гибкость нужна только по необходимости.

Гибкость нужна чтобы в коде вообще не надо было ориентироваться. Один раз сделал и больше этот конкретный класс вообще не трогаешь.

0

Сообщение от ht1515 Солид принципы фуфло

Слишком категоричное заявление. Понять зачем они нужны можно только повозившись в тонне говнокода. Тогда придёт понимание, что дисциплина нужна не только в армии, но и при написании кода. Но и перебарщивать тоже не нужно, во всём нужна разумная мера.

0

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

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

1

Сообщение от Fulcrum_013 Но гораздо сложнее расширять функциональность.

за это отвечает второй принцип:
принцип открытости/закрытости (Open-closed)
выполните его, и проблем с расширяемостью не будет.

Сообщение от Fulcrum_013 Гибкость нужна чтобы в коде вообще не надо было ориентироваться.

ага, конечно: интерфейс сидит на интерфейсе и интерфейсами погоняет.
куча классов ради классов.
в таком коде вообще не понятно,
кто делает настоящую (полезную работу)

Сообщение от ht1515 Солид принципы фуфло

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

0

Сообщение от Usaga Слишком категоричное заявление. Понять зачем они нужны можно только повозившись в тонне говнокода

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

0

Сообщение от asmquest вообще говоря, рассуждения в стиле "этот знает о том", сами по себе порочны в корне.

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

а вот рассуждения старой школы:
"А не должно зависеть от Б" уже практически утратило свою актуальность.

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

SOLID во многих своих аспектах банально устарел.

0

Сообщение от hoggy в таком коде вообще не понятно, кто делает настоящую (полезную работу)

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

0

Сообщение от hoggy так например, паттерн "коллбек" (делегаты) позволяет кнопке вообще не знать ничего о том, что произойдёт при нажатии.

колбек в данном случае выглядит особенно комично. Тут дело, видимо в стереотипах, навязанных современными языками. Если мы, к примеру, имеем button.switchOn, то метод switchOn тут -- и есть коллбек, по сути дела. Но мы легких путей не ищем, мы напишем, button.action(switchOn). Это реально смешно, до какой степени идиотизма доходят современные горе-дезигнеры.

0

Сообщение от asmquest колбек в данном случае выглядит особенно комично. Тут дело, видимо в стереотипах, навязанных современными языками.

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

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

0

Сообщение от asmquest колбек в данном случае выглядит особенно комично.

Особенно комично будет выглядеть попытка реализовать сохранение таких связь в ресурсе (файле) без использования делегата.

0