SOLID принципы

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


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

0

Сообщение от asmquest Это все хрень, которая привязана к статической типизации, это не имеет значения для нормальных языков

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

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

Сообщение от asmquest Допустим, есть класс, который предоставляет курс валюты, есть объект, который в этом классе постоянно меняет этот курс, опрашивая некий сторонний ресурс раз в 10 секунд. В итоге все подклассы и экземпляры этого класса будут всегда оперировать актуальными данными

И где тут изменение сигнатур? Здесь только изменение данных. Для этого ни динамическая типизация ни динамическое изменение типов не нужны. Для этого статики выше крыши.

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

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

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

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

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

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

0

Сообщение от Fulcrum_013 И где тут изменение сигнатур?

нет, имеется в виду ситуация, когда в классе есть поле, допустим, USD/RUB, а в подклассе метод foo = (USD/RUB + 10), экземпляр этого подкласса принимает сообщение foo и всегда отдает актуальные данные. Такая вот примерно схема. А в какой то момент, например, класс отписывается от обновлений, или подписывается на другой источник, или добавляет USD/EURO и тп

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

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

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

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

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

и цепочки наследования могут меняться во время выполнения

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

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

это противоречие, и искуственное ограничение. Например, в жизни, человек изначально был поваром, а потом научился играть в футбол, и стал футболистом. Должна быть возможность выражать абстракции времени и изменения состояния, иначе это не ООП, а ФП

0

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

Изменение цепочки наследования влечет за собой изменение интерфейса.

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

А все необходимы списки методов с существующим на момент компиляции кодом могут быть созданы и в компайл тайме.

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

Сообщение от asmquest Должна быть возможность выражать абстракции времени и изменения состояния, иначе это не ООП, а ФП

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

0

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

Влечет. Изменение цепочки наследования автоматически меняет интерфейс объекта

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

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

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

Сообщение от Fulcrum_013 Достаточно агреггировать новые дополнительные компоненты

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

0

Сообщение от asmquest Влечет. Изменение цепочки наследования автоматически меняет интерфейс объекта

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

Добавлено через 23 секунды

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

Зато от крешей защищено.

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

Сообщение от asmquest а если этот список должен зависеть от юзер-инпута?

Вот это как раз с агрегацией гораздо проще реализуется. Так же как и сериализация/десериализация того что юзер наинпутил

0

Сообщение от Fulcrum_013 Тут ему предка на носорога заменили а дирижер сказал мяукать. креш батенька.

какой дурак это все будет делать и зачем? Барабашка? можно сдуру и член сломать от этого никто не защитит

0

Сообщение от asmquest какой дурак это все будет делать и зачем? Барабашка? можно сдуру и член сломать от этого никто не защитит

Алгоритм. Напомню при создании алгоритмов программист 10% времени создает ошибки 90% времени их расхлебывает. А защитит статическая типизация. При которой либо объект умеет хотя бы мяукать по команде голос, либо его в списке собак нет.

0

Сообщение от Fulcrum_013 Вот это как раз с агрегацией гораздо проще реализуется.

агрегация -- это делегирование. В смоллток-лайк языках наследование реализуется делегированием полностью. А в говноязыках нужны костыли для этого.

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

Сообщение от Fulcrum_013 Алгоритм. Напомню при создании алгоритмов программист 10% времени создает ошибки 90% времени их расхлебывает.

А в жизни чтобы член не ломался надо протез носить? Ну-ну. Заодно неплохо было бы запилить защиту от того, чтобы в хелловорде, в функции принт, принимался специальный тип, исключающий что-либо, кроме фразы "Hello world!"

0

Сообщение от asmquest А в говноязыках нужны костыли для этого.

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

0

Сообщение от Fulcrum_013 говноязыки это то где нет классического наследования

совершенно верно. А классика наследования -- это смоллток

0

Сообщение от asmquest А в жизни чтобы член не ломался надо протез носить?

Знаете бородатый анекдот как от СПИДа уберечься? Пить морковный сок. Не до, не после, а вместо.

0

Сообщение от Fulcrum_013 Гораздо чаще от нее геммора больше чем профита.

Например?

0

Сообщение от asmquest А классика наследования -- это смоллток

Классика наследования это Modula. Аггреггация фактически наследованием вообще не является.

0

Сообщение от Fulcrum_013 Пить морковный сок. Не до, не после, а вместо.

Вот этим и занимаются адепты статической типизации

0

Сообщение от asmquest Например?

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

0

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

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

0

Сообщение от asmquest Вот этим и занимаются адепты статической типизации

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

0

Сообщение от Fulcrum_013 такого СПИДа нет по определению.

так я про это и говорю, там программирования нет по-определению, только морковный сок

0

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

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

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

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

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

0

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

Какую обертку?

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

Сообщение от Fulcrum_013 Если нет спида то и шырять можно в любых местах ничего не боясь

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

0