SOLID принципы

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


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

0

hoggy, ваш пример немного не о том, что я имел в виду. У вас тут коллбек оnClick -- это метод объекта button. Вы просто конкретизируете его, конфигурируете существующий объект. С таким же успехом там мог быть любой другой метод, это просто метод объекта button.
Хз, что Вы имели в виду под:

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

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

Я имел в виду передачу коллбека в рантайме

0

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

То просто у костыля лямбдовского синтаксис сразу не понятный.
С нативными делегатами гораздо понятнее будет:
Т.е. ни кнопка о лампе ни лампа о кнопке вообще ничего не знают. Знает только дирижер который связывает источник и получатель калбека.

0

Сообщение от asmquest это метод объекта button

это не метод.
это - делегат.

он ничего ни о какой кнопке не знает.

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

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

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

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

да, я явно указываю, что произойдёт при клике.
только кнопка про это не знает,
и ей это не интересно.

она знает только про себя.
и про то, что когда кликнеццо,
нужно будет пнуть делегат.

а уж что он там будет делать - ей всё равно.

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

Сообщение от asmquest Я имел в виду передачу коллбека в рантайме

можно и в рантайме.

0

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

С другой стороны, с точки зрения интерфейса, выражение

Сообщение от Fulcrum_013 button.OnPress=lamp.SwitchOn;

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

0

Сообщение от asmquest и не имеет представления о тех физических процессах

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

0

Сообщение от asmquest и не имеет представления о тех физических процессах

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

0

Сообщение от hoggy это не метод. это - делегат.

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

0

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

дальше не читал.

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

0

Сообщение от hoggy как это соотносится с обсуждаемой темой. в данном случае - solid.

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

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


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

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

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

0

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

Потому что в классе Кнопка был метод void TurnOn(Lamp lamp).
И чтобы скомпилировать модуль с классом Кнопка, нужно указать ссылку на модуль с классом Лампочка.

з.ы. Класс Кнопка не имеет никакого отношения к GUI. Возможно, кроме метода TurnOn() там ничего больше нет.

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

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

Мягко говоря, это очень глупое заявление.
Если в моём классе Кошка будет метод Летать(Велосипед велик), то Кошка будет зависеть от Велосипеда. И ещё Кошка будет Летать Велосипедом. Пытаться привязать к коду аналогии из жизни на основе совпадения названий чего-нибудь - весьма странное занятие.

0

0

Сообщение от asmquest Насколько я понимаю, принципы solid претендуют на то, чтобы быть общими принципами проектирования.

на топовый c-like

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

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

обобщенное программирование
не имеет никакого отношения к DI.

0

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

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

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

Сообщение от Shamil1 Потому что в классе Кнопка был метод void TurnOn(Lamp lamp). И чтобы скомпилировать модуль с классом Кнопка, нужно указать ссылку на модуль с классом Лампочка.

Короче, Вы говорите о зависимости с тз неймспейсов. А речь, вроде, о концептуальной зависимости.

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

Добавлено через 1 час 18 минут

0

Сообщение от asmquest Короче, Вы говорите о зависимости с тз неймспейсов. А речь, вроде, о концептуальной зависимости.

Я говорю о той зависимости, которая упоминается в термине "Инверсия Зависимости". А мой пример показывает, как эту зависимость инверсировать (развернуть).

Сообщение от asmquest лампочка и выключатель -- это вещи одного порядка с точки зрения иерархии

Лампочка и Кнопка - это названия классов. Можно поменять их местами (Лампочка будет включать Кнопку) - и ничего от этого не изменится. О какой иерархии Вы говорите?

0

Сообщение от Shamil1 Я говорю о той зависимости, которая упоминается в термине "Инверсия Зависимости". А мой пример показывает, как эту зависимость инверсировать (развернуть)

Я пока не вижу там упоминания зависимости выключателя и лампочки.

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

Сообщение от Shamil1 О какой иерархии Вы говорите?

Я говорю об иерархии классов. Например, лампочка является частным случаем осветительного прибора, а выключатель -- частным случаем коммутационного устройства.

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

Сообщение от Shamil1 инверсировать (развернуть).

Кстати говоря, я вообще не понял, о какой инверсии/развертке идет речь. Я не вижу никакой инверсии ни в вашем примере, ни в определении "инверсии зависимостей". Видимо, как всегда, кто то что-то не понял, а потом название прижилось. Оно не соответствует сути этого принципа, там ничего не инвертируется

Добавлено через 4 минуты
Shamil1, да и вообще, кстати, не надо тянуть сюда низкоуровневые детали, такие как особенности компиляции и работа модульной системы конкретного языка/языков. Если мы хотим оставаться в рамках конструктивного обсуждения, мы должны придерживаться терминологии ООП, т.е. Класс/тип, экземпляр, объект, сообщение и тд

0

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

0

Сообщение от asmquest Например, лампочка является частным случаем осветительного прибора, а выключатель -- частным случаем коммутационного устройства.

Неправильно. Лампочка является классом, который мы назвали "Лампочка", а Кнопка - классом, который мы назвали "Кнопка". Если Вам слова мешают понимать смысл, замените их на буквы.

Есть класс А и есть класс Б с методом В(А а). Класс Б зависит от класса А (потому что содержит метод, принимающий аргумент класса А). Ну и дальше так, как я писал выше.

Сообщение от asmquest Кстати говоря, я вообще не понял, о какой инверсии/развертке идет речь. Я не вижу никакой инверсии ни в вашем примере, ни в определении "инверсии зависимостей".

В определении сложно не заметить слово "инверсия".
В моём примере сначала модуль МБ, содержащий класс Б, зависел от модуля МА, содержащего класс А. После добавления интерфейса в МБ и замены типа аргумента в методе В на интерфейс, модуль МА стал зависеть от модуля МБ. "Стрелочка" зависимости развернулась в противоположную сторону.

0

Сообщение от Shamil1 Есть класс А и есть класс Б с методом В(А а). Класс Б зависит от класса А (потому что содержит метод, принимающий аргумент класса А).

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

0

Именно это и называется зависимостью в программировании.

0

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

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

Сообщение от Shamil1 Именно это и называется зависимостью в программировании.

какой прок от этого?

0