SOLID принципы

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

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

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

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

@asmquest · 02.02.2017, 00:12

Fulcrum_013, ах да, помимо жабы и хашкеля, я забыл упомянуть плюсы, они тоже в тройке лидеров. Хром как бы намекает нам на это.

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

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

это динамически типизированные

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

@Fulcrum_013 · 02.02.2017, 00:13

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

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

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

@asmquest · 02.02.2017, 00:20

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

по сравнению с гораздо более простыми питоновскими GUI-поделками.

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

@Fulcrum_013 · 02.02.2017, 00:30

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

сам дизайн языков -- потомков смоллтока -- это образец "память дорогая, процессоры дешевые"

Реалии говорят об обратном. При этом пока не превышен бандвидз доступа к памяти память дешевле. Смысл делать по принципу "память дорогая" есть только там где нужен гигантский бандвидз. К примеру текстурирование в GPU. Даже при том бандвидзе который дает 384-битная шина его не хватает и дешевле получается распаковывать/запаковывать текстуры на лету и хранить их компрессированными. Но даже там смалталк неприменим. На GPU нет индирект вызовов а соответсвенно и виртуальных методов.

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

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

А в пистоне как раз, во многом, жабская модель ООП реализована

В жабе вообще статические сигнатуры классов. Соответсвнно жер там не от реализации объектной модели.

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

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

Эта модель заточена на небольшой расход памяти by design

Ошибаетесь. Под малый расход памяти заточена как раз Modula-вская модель классов со статическим определением сигнатур классов которая и реализована в Java, С++, Pascal и т.д. А SmallTalk-овская модель с динамически изменяемыми сигнатурами оюъектов как раз и расточительна как в плане памяти так и в плане процессорного времени, при этом логически необходимость в динамическом изменении сигнатур объектов отсутствует напрочь.

@asmquest · 02.02.2017, 00:32

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

В жабе вообще статические сигнатуры классов. Соответсвнно жер там не от реализации объектной модели

А сама по себе статическая сигнатура классов, типа, к объектной модели не имеет отношения?

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

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

А SmallTalk-овская модель с динамически изменяемыми сигнатурами оюъектов как раз и расточительна как в плане памяти

очередное безосновательное заявление

@Shamil1 · 02.02.2017, 00:39

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

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

Про Джаву Вам уже написали. А в Хаскеле вообще нет классов. Зачем писать о том, о чём Вы не знаете?

@Fulcrum_013 · 02.02.2017, 00:39

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

А сама по себе статическая сигнатура классов, типа, к объектной модели не имеет отношения?

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

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

очередное безосновательное заявление

Там же где сигнатура объекта динамически изменяема необходимо иметь копию VMT в каждом объекте и при клонировании объекта копировать всю VMT в создаваемую копию.

@asmquest · 02.02.2017, 00:45

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

А в Хаскеле вообще нет классов

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

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

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

необходимо иметь копию VMT в каждом объекте

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

@Shamil1 · 02.02.2017, 00:49

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

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

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

@Fulcrum_013 · 02.02.2017, 00:55

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

Да и не про классы речь шла, а про расход памяти,

НУ хацкеля и прочая ФП баламуть в основном стек кушает. И кушать будет. Потому как если данные изменять незя а очень хочется то вместо них просто создаются новые. Причем на стеке, а значится все старые уже давно ненужные данные деаллоцируются только по концу вычислений. Хороший подход для случаев когда электронная ОЗУ с рандомным доступом дорогая но есть очень дешевая ЗУ большой емкости с последовательным доступом (магнитная лента) а то и с однократной записью (перфолента). Т.е. ФП это фактически привет из 50-х

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

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

поиск происходит непосредственно по хешам, которые живы в рантайме.

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

@asmquest · 02.02.2017, 00:59

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

Там нет аналога.

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

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

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

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

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

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

Вот хеш в данном случае и есть VMT

так нафига в каждом объекте копия то нужна?

@Fulcrum_013 · 02.02.2017, 01:00

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

так нафига в каждом объекте копия то нужна?

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

@asmquest · 02.02.2017, 01:04

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

Соответсвенно каждый объект должен иметь список того что в нем есть.

объект имеет доступ к тому, что в нем есть(собственным полям), естественно, интерпретатор этот доступ обеспечивает, но зачем копия?

@Fulcrum_013 · 02.02.2017, 01:11

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

интерпретатор этот доступ обеспечивает, но зачем копия

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

@asmquest · 02.02.2017, 01:18

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

объект должен хранить в себе список всех методов которые он имеет.

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

@Fulcrum_013 · 02.02.2017, 01:22

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

Эти поля, могут содержаться как в самом объекте или классе

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

@asmquest · 02.02.2017, 01:26

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

Поэтому объект должен хранить в себе весь список методов которые в него добавлены.

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

@Shamil1 · 02.02.2017, 01:27

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

это про жабу было сказано

Это было сказано про Джаву и Хаскель:

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

классика жера памяти -- это жаба и хашкель. жер памяти обусловлен тем

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

Но в хаскеле аналогичные механизмы.

В Хаскеле нет классов. Классы типов в Хаскеле совершенно не похожи на классы в ООП.

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

чтобы иметь новую структуру с одним измененным элементом, надо создать новую, изменить старую нельзя

Это плюс к экономии памяти.

@Fulcrum_013 · 02.02.2017, 01:30

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

классе/типе

Класс/тип это вообще абстракция которая содержится исключительно в мозгу программиста и больше нигде. Она никаких данных вообще не хранит. Это всего лишь список группировки полей и методов. Причем при статических сигнатурах этот список неизменен для объектов каждого типа, посему хранить нужно только то что изменяемо для каждого типа -т.е. общую VMT. А для того чтобы иметь возможность добавлять/убирать методы из объекта в рантайме каждый объект должен хранить весь список своих методов. Потому как в таком случае если у объекту A добавили метод B то это абсолютно не должно затрагивать объект С которому этот метод не добавляли. Соответсвенно список методов у A и С у каждого свой а не общий. Фактически динамическое конструирование сигнатур объектов абсолютно нивеллирует понятие класс и как результат вообще ООП-парадигму.

@asmquest · 02.02.2017, 01:41

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

Это было сказано про Джаву и Хаскель:

где там про копирование классов в отношение хаскеля? Снова голоса?

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

В Хаскеле нет классов.

так я же и сказал, что нет. Там суррогат

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

Это плюс к экономии памяти.

разговор на этом считаю состоявшимся. Продолжать смысла нет.

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

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

Класс/тип это вообще абстракция которая содержится исключительно в мозгу программиста и больше нигде

в программировании все -- абстракции.

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

Потому как в таком случае если у объекту A добавили метод B то это абсолютно не должно затрагивать объект С которому этот метод не добавляли.

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

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

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

Соответсвенно список методов у A и С у каждого свой а не общий

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

Новые блоги и статьи Все статьи Все блоги /
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 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .

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

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