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

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

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

Новые блоги и статьи Все статьи Все блоги /
GitHub Copilot в JetBrains: модель по умолчанию, Fix и контроль MCP and_y87 12.10.2026 10 октября 2026 года GitHub обновил Copilot для JetBrains: добавил настройки стартовой модели, исправления из диагностики и управление автозапуском MCP. Поддержка IDE 2025. 1 прекращена — требуется. . .	GitHub Copilot в JetBrains: модель по умолчанию, Fix и контроль MCP and_y87 12.10.2026 10 октября 2026 года GitHub обновил Copilot для JetBrains: добавил настройки стартовой модели, исправления из диагностики и управление автозапуском MCP. Поддержка IDE 2025. 1 прекращена — требуется. . .	День 5 из 28: Codex подсказывает следующий запрос and_y87 12.10.2026 9 октября 2026 года OpenAI запустила бету Composer predictions — подсказок следующего сообщения в текущем диалоге Codex. Это помощь с формулировкой запроса, а не автоматическое продолжение задачи. . . .	Запустил конкурс "тем и промптов для текстовых квестов созданных почти чисто ИИ" Adler 06.10.2026 Всем привет! За последние три-четыре дня я создал более 16 текстовых квестовых игр используя преимущественно по одному запросу к ИИ на игру. Мне так понравилось смотреть все ветки/ сцены во всех. . .
ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .	Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .	Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .

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

	SOLID принципы 23.01.2017, 17:55. Показов 17651. Ответов 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