SOLID принципы

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


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

0

Сообщение от asmquest Что значит избавиться от зависимости в данном случае?

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

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

Сообщение от asmquest какой прок от этого?

Наша кнопка включает то, не знаю что. То есть, включает всё, что может включаться (реализует интерфейс Включабельный). Это называют гибкостью.

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

0

Сообщение от Shamil1 Наша кнопка включает то, не знаю что. То есть, включает всё, что может включаться (реализует интерфейс Включабельный). Это называют гибкостью.

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

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

ЗЫ И гибкости это не придаст, скорей наоборот

0

Usaga,

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

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

hoggy,

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

вы провокатор )

hoggy,

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

Как говорил ленин: "мышление должно быть адекватным..."

0

Shamil1,
Да, и возвращаясь к аналогии с функцией. Аналогия эта не верна. Функция рассчитывает на прием абстрактного, а не конкретного объекта, например, функция работающая с типом Integer, может работать с любым числом -- 1, 2, 3, n. Она специализирована только по типу принимаемого аргумента, но не по значению его. В вашем же примере с лампочкой получается так, что, дескать, наша функция изначально работает только и исключительно с одним числом, а мы расширяем это до типа Integer. То есть, до того, что и так должно быть

0

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

тот же самый пример инверсии зависимостей я понимаю так:

Композиция:
Агрегация:
короче main писать не буду уж...
Короче идея проста...
Дом в нем может быть какое-то животное.
Дом не должен зависеть от какого-то одного животного. Банально животное может умереть и дому нужно будет завести новое )))
У дома есть функция - пинок (хз пусть большой башмак будет с механизмом пинания, пофиг...). Так вот пинок нужно отвязать от конкретного животного, пинок нельзя менять, пинок должен быть для любого животного один и тот же.

Добавлено через 4 минуты
hoggy, насчет интерфейсов... В первом посте неверно выразился...
Ну вот приведу Вам пример IClonable, IEnumerable, IDictionary - микрософт интерфейсы. Они удовлетворяют этому принципу. Согласны?


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

0

Сообщение от ht1515 Я то начал тему про Барабару Лисков, приведите пример мне пожалуйста системы где без ее принципа жить нельзя или сложно хотя бы?

ИМХО, просто есть случаи, где это удобней. Если воспользоваться аналогией с лампочкой и выключателем, то, к примеру, у нас есть Класс "Включающий" и класс "Включаемый". Пусть у "Включаемого" реализованы методы "среагировать на включение напряжения" и "среагировать на выключение напряжения" а в классе "Включающий" -- "подать напряжение" и "прекратить подачу напряжения". Допустим, мы унаследовали от "Включающего" "Выключатель" а от "Включаемого" -- лампочку. В этом случае метод класса "Включающий" может абстрагироваться от того, что включаемый прибор -- именно лампочка, а не что-то другое(например -- вентилятор), он абстрагирован от конкретной реализации. В противном случае, нам пришлось бы реализовывать в его подклассе "выключатель" отдельный метод "подать напряжение" или в классе "Включающий" отдельный метод для лампочки "подать напряжение на лампочку". То есть, это про обычный полиморфизм, по-сути дела.

0

Сообщение от asmquest Любой метод является первоклассным объектом

Только для начала нужно понять разницу между указателем на метод класса которым является оная ссылка в С++ и указателем на метод объекта коим является делегат.

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

Сообщение от asmquest То есть, это про обычный полиморфизм, по-сути дела.

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

Добавлено через 12 минут
Т.е. суть в чем. Класс моделирует тривиальные части поведения какой либо сущности, а нетривиальные, модифицируемые в широком, заранее непредсказуемом диапазоне на уровне каждого объекта, и имеющие возможности изменятся в рантайме делегирует внешним обработчикам. Что позволяет поднять гибкость до абсолютной.
К примеру шейдеры тоже по большому счету являются делегатами графического конвейера. И использовать их начали по той причине что модификация поведения конвейера при помощи флагов и стейтов стала просто невменяемой и потребностям гибкости настройки поведения конвейера абсолютно не удовлетворяла.

0

Сообщение от Fulcrum_013 Только для начала нужно понять разницу между указателем на метод класса которым является оная ссылка в С++ и указателем на метод объекта коим является делегат.

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

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

Сообщение от Fulcrum_013 Что позволяет поднять гибкость до абсолютной.

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

0

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

Разница между классом и объектом концептуальна а соответственно языконезависима.

Сообщение от asmquest Особенно это актуально для прототипирования.

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

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

Сообщение от asmquest Гибкость абсолютной будет только тогда, когда все сущности языка являются свободно и единообразно модифицируемыми в рантайме

Это уже не гибкость а каша. Абсолютная гибкость это когда связи между объектами классов предметной области являются стыкуемы/расстыкуемы в рантайме

0

Сообщение от Fulcrum_013 Разница между классом и объектом концептуальна а соответственно языконезависима.

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

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

Сообщение от Fulcrum_013 Абсолютная гибкость это когда связи между объектами классов предметной области являются стыкуемы/расстыкуемы в рантайме

Не вижу препятствий.

0

Сообщение от asmquest Разница между классом и объектам вводится в языках по разным соображениям

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

0

Сообщение от Fulcrum_013 Разница между классом и объектом что класс это вообще абстракция существующая только в мозгу программиста

В этом смысле тоже разницы нет. Как класс так и объект являются абстрактными сущностями

0

Сообщение от asmquest из-за тупости дизайнера языка,

Тупость дизайна - это когда к объектам методы/поля прилепляются в рантайме средствами языка как в том же JS или PHP. Вот это как раз и гарантирует ничем не контролируемую кашу.
В С++ такие средства тоже в принципе реализуются но только уже на уровне логики работы класса, что дает возможность контролировать непротеворичивость и соответствие таких модификаций спецификации класса.

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

Сообщение от asmquest объект являются абстрактными сущностями

Объект это абсолютно конкретная область памяти с абсолютно конкретными записанными в нее значениями состояний, существующая в рантайме. А класс существует только в словаре парсинга но не в рантайме.

0

Сообщение от Fulcrum_013 Вот это как раз и гарантирует ничем не контролируемую кашу.

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

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

Сообщение от Fulcrum_013 Объект это абсолютно конкретная область памяти с абсолютно конкретными записанными в нее значениями состояний.

В нормальных языках класс тоже абсолютно конкретная область памяти с абсолютно конкретными записанными в нее значениями состояний

Сообщение от Fulcrum_013 А класс существует только в словаре парсинга но не в рантайме.

Это касается только квази-ооп языков

0

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

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

0

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

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

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

0

Сообщение от asmquest Это касается только квази-ооп языков

ООП в чистом виде почило в бозе более 20 лет назад и было заменено КОП.

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

Наверное именно из за этих трудностей начинающих и обучают на языках с динамической типизацией а не статической.
На самом деле динамическая типизация дает на порядок больше геммороя чем профита и в 99,9% случаев статическая типизация (не путать с диспетчеризацией) предпочтительней динамической. А там где она нужна тип VARIANT никто в статических языках не отменял. При этом не следует забывать что все эти фичи динамической типизации под капотом реализованы средствам яззыка со статической типизацией. (даже если оно в машкод скомпилировано-у машкода типизация статическая). Соответсвенно если нужна именно динамическая типизация для чего то конкретного она средствами языков со статической типизацией реализуется просто, но при этом строго в необхходимом объеме и с контролем непротиворечивости в рамках конкретной задачи ее применения

0

Сообщение от Fulcrum_013 Наверное именно из за этих трудностей начинающих и обучают на языках с динамической типизацией а не статической.

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

Сообщение от Fulcrum_013 случаев статическая типизация (не путать с диспетчеризацией) предпочтительней динамической

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

Сообщение от Fulcrum_013 При этом не следует забывать что все эти фичи динамической типизации под капотом реализованы средствам яззыка со статической типизацией.

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

0

Сообщение от asmquest а самом деле, бОльшей квалификации требует тот язык, на котором трудней писать,

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

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

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

0

Сообщение от Fulcrum_013 А там где она нужна тип VARIANT никто в статических языках не отменял

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

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

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

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

Сообщение от Fulcrum_013 Поэтому для задач робототехники и промышленной автоматики языки с автоматической сборкой мусора, к которым по определению относятся языки с динамической типизацией, не пригодны в принципе

Жалко что мужики из AI LAB MIT, колыбели искуственного интеллекта и робототехники этого не знали, использовали лисп, по старинке.

Добавлено через 6 минут
Fulcrum_013, Кстати, говоря, динамические языки хоть и используют обычно GC, это в принципе то не обязательно, вполне возможны и реализации без него. Кроме того, можно сделать реалтайм сборку мусора, и такие системы существуют. Для этого, насколько я знаю, нужна конкурентность.

0