SOLID принципы

@ht1515 · Регистрация: 31.01.2010

Студворк — интернет-сервис помощи студентам

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

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

@asmquest · 26.01.2017, 16:48

Сообщение от Igor3D

Чего это я должен отказываться от наследования если оно прямо-таки напрашивается?

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

@hoggy · 26.01.2017, 17:16

Сообщение от Igor3D

А вот почему до Вас простой пример не доходит - не знаю

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

@Fulcrum_013 · 26.01.2017, 18:04

Сообщение от asmquest

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

Любюой язык где методы переименовываются и добавляются в обьект а не в класс а тем более в рантайме ООП языком не являеется. и вся псевдо-ООП мишура в нем не более чем костыль легаси ФП-средствами.

@asmquest · 26.01.2017, 18:09

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

@Fulcrum_013 · 26.01.2017, 18:30

Сообщение от asmquest

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

ФП-никам это скажите. Они вас всей толпой запинают.

@asmquest · 26.01.2017, 18:43

Сообщение от Fulcrum_013

ФП-никам это скажите. Они вас всей толпой запинают.

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

@Usaga · 26.01.2017, 18:53

Не по теме:

Люди, вы ещё не устали друг другу непонятно что доказывать? :)

@Fulcrum_013 · 26.01.2017, 19:06

Сообщение от asmquest

Те лазейки, которые используются в тн "чистых" ФП-языках, для имитации ООП, такие как монады "state", "IO"(являющиеся расширением, и не входящие в парадигму),

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

@asmquest · 26.01.2017, 19:20

Сообщение от Fulcrum_013

А дело не в изменяемости или не изменяемости состояний

И в этом тоже. Если говорить о сколько-нибудь полноценном ООП, без состояния оно не взлетит.

Сообщение от Fulcrum_013

А в том что в таких языках объект не более чем неструктурированный массив объектов первого класса

Я говорил о семантической составляющей. С точки зрения семантики, в ФП есть только абстракция(функция) и аппликация(применение), никакого состояния, поведения, времени и объектов в ООП-смысле там нет.

@Fulcrum_013 · 26.01.2017, 19:29

Сообщение от asmquest

С точки зрения семантики,

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

@asmquest · 26.01.2017, 19:37

Сообщение от Fulcrum_013

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

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

@Fulcrum_013 · 26.01.2017, 20:49

Сообщение от asmquest

И уж тем более, там нет никакого изменяемого состояния, это нонсенс.

Чистое ФП нонсенс само по себе. Тьюринговская трясина. И вот чтобы из этой трясины как то выбраться снимают ограничения и на неизменнсть данных и даже на чистоту функций. Причем не монадами а просто на уровне языка.

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

Сообщение от asmquest

в ФП не существует такой семантической единицы, как замыкание.

А это вообще обычно не семантическая единица а подкапотные дела компилятора.

@asmquest · 26.01.2017, 20:58

Сообщение от Fulcrum_013

А это вообще обычно не семантическая единица а подкапотные дела компилятора.

Когда я говорил о том что в чистом ФП невыразимо ООП, я говорил именно о семантике. Никто не спорит, что в реальных так называемых "ФП-языках" можно костылить ООП, если бы они оставались в рамках парадигмы и не имели бы расширений в виде монад/присваиваний/замыканий, на них проблематично было бы написать не только ООП, но и вообще что-либо.

@Fulcrum_013 · 26.01.2017, 21:30

Сообщение от asmquest

если бы они оставались в рамках парадигмы и не имели бы расширений в виде монад/присваиваний/замыканий

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

@Shamil1 · 27.01.2017, 01:49

Сообщение от asmquest

С точки зрения семантики, в ФП есть только абстракция(функция) и аппликация(применение), никакого состояния, поведения, времени и объектов в ООП-смысле там нет.

А если в языке есть только сложение и вычитание, то в нём нельзя квадратный корень посчитать?

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

@asmquest · 27.01.2017, 11:00

Сообщение от Shamil1

Комбинируя абстракцию и аппликацию можно реализовать присваивание, состояние и так далее.

Покажите, как это можно сделать.

@Fulcrum_013 · 27.01.2017, 15:53

Сообщение от Shamil1

ООП никак нельзя имитировать ни в процедурных,

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

@Shamil1 · 27.01.2017, 16:01

Сообщение от asmquest

Покажите, как это можно сделать.

Присваивание.

Пусть у нас есть функция:

F#
1
let f x y = (x + 2*y) * (x + 2*y)

Нам не хочется два раза вычислять (x + 2*y). Поэтому мы вычисляем это выражение один раз и передаём в качестве аргумента в другую функцию, которая выполняет оставшиеся вычисления:

F#
1
2
3
4
let f2 x y =
    let g z = 
        z * z
    g (x + 2*y)

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

F#
1
2
3
let f3 x y =
    let z = x + 2*y
    z * z

@Fulcrum_013 · 27.01.2017, 16:05

Сообщение от Shamil1

В каждом языке оно либо есть, либо его нет

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

@Shamil1 · 27.01.2017, 16:22

Сообщение от Fulcrum_013

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

Насколько я знаю, первая реализация плюсов ("Си с классами") была транслятором, перерабатывающим исходный код Си с классами в исходный код простого Си.
Транслятор назывался cfront.
Необходимость транслятора была вызвана тем, что препроцессор не справлялся. ("The preprocessor did not understand all of the language and much of the code was written via translations.")

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

Сообщение от Fulcrum_013

ООП это не более чем способ группировки функций по применимости к наборам данных.

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

Сообщение от Fulcrum_013

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

Компиляторы большинства (всех?) ОО языков позволяют нарушить Принцип Лисков. Для этого достаточно в перегрузке метода/свойства делать не то же самое по-другому, а что-нибудь совсем другое.
Например, пронаследовать Квадрат от Прямоугольника и в методе ЗадатьШирину менять Ширину и Высоту.

Новые блоги и статьи Все статьи Все блоги /
Вступаем в новую фазу генерации favicons, векторную. russiannick 02.11.2026 Теперь нет нужды скрывать что используется простой svg. Исходный код изображения помещаем в поле и жмем кнопку. Исходник преобразуется в вид корректный для помещения в favicon или в url(). Нажатие. . .	Генератор паролей (вариант №4) Maks 01.11.2026 После публикации 3-го варианта генератора паролей, разослал его своим коллегам (с целью оценки), в итоге были получены следующие рекомендации: 1. Вернуть возможность использования знаков \| 1 l I;. . .	Генератор паролей (вариант №3) Maks 30.10.2026 Финальная версия генератора паролей 1С. Доработка решения в этот раз коснулась только визуальной части, а именно, добавлен реквизит ДопПараметры (тип Булево), который скрывает/ отображает реквизиты:. . .	Магическое мышление и магия, современная наука не отличима от магии (говорит ИИ Джемени) zorxor 30.10.2026 Джемени, расскажи, пожалуйста, что такое магическое мышление, что такое магия, почему современная наука чем-то напоминает магию? Фраза «Любая достаточно развитая технология неотличима от магии». . .
За какое время ИИ может подобрать пароль по хешу (рассказывает Джемени ИИ) zorxor 30.10.2026 Расскажи, Джемени, если известен хэш МД5, например, за сколько ИИ сможет подобрать соответствующий пароль? Искусственный интеллект (ИИ) может подобрать простой или средний по сложности пароль по. . .	Кто убил Suno? Почему наше солнышко погасло? (диалог с ИИ Джемени) zorxor 30.10.2026 Как убивали Suno. Хронология. «Убийство» музыкальной нейросети Suno — это затяжной процесс, в котором технологический хайп стартапа разбился о жесткую реальность судебных исков от гигантов. . .	Генератор паролей (вариант №2) Maks 30.10.2026 Обновленная версия ранее созданной обработки. Добавлены следующие реквизиты типа Булево: - Буквы; - Цифры; - Символы. Изменена логика команды "Сгенерировать" и процедуры "ПриОткрытии":. . .	Генератор паролей (вариант №1) Maks 29.10.2026 Реализация из решения ниже выполнена исключительно по моей инициативе, дабы облегчить себе работу в создании паролей для администрируемых мною сервисов и пользователей. Самым главным критерием для. . .

@ht1515 шарпопочитатель 59 / 26 / 7 Регистрация: 31.01.2010 Сообщений: 1,035

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

@asmquest Заблокирован
	26.01.2017, 18:09
	Fulcrum_013, это абсолютно безосновательное и беспочвенное заявление, и, более того, на самом деле все строго наоборот, но Вы имеете право на свое собственное мнение. Мне вот только одно непонятно, при чем тут вообще ФП. Почему Вы его сюда приплетаете? И что Вы под этим подразумеваете? К слову, если говорить о ФП в каноническом смысле этого слова, как о подстановочной модели, то там никакая имитация ООП вообще невозможна. 0

@Usaga
	26.01.2017, 18:53
	Не по теме: Люди, вы ещё не устали друг другу непонятно что доказывать? :) 0