Что лучше учить?

В простых структурах данных и функциях этот принцип сам по себе выполняется

Никогда не видел функций — на все руки мастеров? %)

этого кома нет, когда работаешь со структурами и функциями.

Согласен, гораздо проще.

есть более широкий принцип: работает - не трогай.

Те же яйца. И OCP этому помогает, не так ли?

зачем вообще мы делали таблицы функций

Чтобы человек мог не потеряться, очевидно же. Как с этой стороны интерфейса, так и с той.

Что такое абстракции, реализации, и зависимости по-твоему? Мне просто интересно узнать хотя бы одну модель из не класс-ориентированого софта, где применимы эти понятия вместе с принципом.

Например, протоколы в Clojure. Протокол — просто набор функций, без всякого наследования.

они применимы ко всем языкам с нормальным ООП

Тору

Таки Истину пишешь.

В/о не нужно же.

грубо говоря «можно петь не зная нот», как в караоке

Вообщем не морочьте себе голову.
Ваше - 1С.

не пора ли эту говорящую куклу забанить и снести этот топик в ад!

Пока. Узнала сегодня много нового.

Неужели этот траль лучше чем царь или эдик?

Эдик пропал, а Царь низкоактивен, нужно радоваться тому, что есть.

Вывели тетю «на чистую воду» /а то программирование ее якобы интересовало/.

Трудно активничать когда тебя моментально банят.

Если бы не его лексика, то ни кто его бы не банил.

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

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

Он не только про низкоуровщину пишет. Да и помогает начинающим.

Ни кто его не гонит.
Его лексика - все его беды.

Что лучше учить? (комментарий)

Не правда же. Шаман недавно ему войну объявил. Даже анонимусов в dev запретить хотели.

Сравните с https://tsar1997.blogspot.com/

Что мне сравнивать и зачем?

Лучше ничего не учить. Программист – это как говно – ничего хорошего. Просто пишешь свой код, и ничего хорошего в этом нету. Зачем тебе вообще лезть в это дерьмо? Хочешь промотать жизнь за компом? Отличный план! (нет – говно).

А де лучше проматывать жизнь?

Для меня вопрос «Быть царю или нет» не актуален.
Его посты ни когда не читаю /из-за лексики/.

Программист – это как говно – ничего хорошего. Просто пишешь свой код, и ничего хорошего в этом нету.

Так кому, как ...

Вот не сказал бы. В самопальных базах данных и даже сишных структурах нарушение SRP наблюдаю сплошь и рядом. Когда в одной таблице уживаются описание объекта, его использование в какой-то подсистеме и его связи. Например, «ФизическоеЛицо» с «ФИО», «ПоследняяПродажа» и «Должность».

Я напоминаю, что «Martin defines a responsibility as a reason to change». У данных нет причин изменяться и изменять, потому что они ничего не изменяют. Потому, SRP относится только к классам, функциям, и модулям.

В функциях тоже. save_form() с отображением изменений на экране и записью в базу — классический пример.

Вот это, действительно, плохой прием.

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

Да. Архитектура обычного приложения на Си идеальна по ISP.

Мне просто интересно узнать хотя бы одну модель из не класс-ориентированого софта, где применимы эти понятия вместе с принципом.

«Всё есть файл» (с).

Хорошо, принято. Из всего SOLID остались актуальными OCP и DIP, и, в какой-то степени, SRP. То есть, не ломай что работает, используй абстрактные интерфейсы для связи частей системы, не суй разнородный функционал в одну функцию.

А зачем, если есть устройство не неограниченным сроком автономной работы, возможностью производить до пары сотен съёмных носителей информации и стоимостью на два порядка меньше, чем «устройство с месяцем автономной работы»?

Это какое?

Дай отгадаю: просто, 1С такого не умеет.

Умеет: https://infostart.ru/public/543999/

iOS и Android крайне неэффективно расходуют ресурсы мобильного устройства.

Вот что меня удивляет, то что архитектурный подход фирмы 1С /хороший/ другие фирмы не используют в своих разработках.
Ведь все «просто» и гениально.
Создаем сотню наиболее востребованных объектов и разрабатываем скриптовый язык, который может их использовать.

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

Конечно у QT потенциал больше, чем у 1С, но:
- 1C не требует компиляции модулей;
- 1С много упрощает разработку кода и о многих «мелочах» программисту не нужно заботиться;
- ...
По совокупности всего имеем - отличную rapid технологию.

Это разница как между напильником и фрезерным станком. Да, напильник проще и меньше забот, но и возможностей намного меньше.

есть более широкий принцип: работает - не трогай.

Те же яйца. И OCP этому помогает, не так ли?

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

Чтобы человек мог не потеряться, очевидно же. Как с этой стороны интерфейса, так и с той.

Однако же, в критерии SOLID принцип «чтобы человек мог не потеряться» не входит. Даже наоборот, «чтобы человек мог не потеряться» приводит к условиям, противоречащим SOLID.

Да, напильник проще и меньше забот, но и возможностей намного меньше

Это да, но фирма 1С и не предлагает свою технологическую платформу использовать для математического моделирования.
А для подсчета пивных бутылок и пробок от шампанского - «самое то».

они применимы ко всем языкам с нормальным ООП

Это пишется как «они применимы ко всем ООП языкам, которые я знаю, а я знаю я только C++ и Java».

У данных нет причин изменяться

Структуры данных падают нам с неба в совершенном, законченном виде. Понемаю.

Мартин, если уж о нем пошла речь, говорит о том, что главная причина для изменений в ПО — это некоторая заинтересованная сторона (пользователь), требования которой изменились. И когда модуль может изменяться по требованию больше, чем одной заинтересованной стороны — это нарушение SRP. Потому что тогда правки, вносимые по инициативе одной стороны, могут ломать функциональность, нужную другой. HR поправил UserInfo, и у продажников отвалилась статистика.

Архитектура обычного приложения на Си идеальна по ISP.

Кто-то мешает тебе бахнуть все 100500 функций в один файл? %)

А де лучше проматывать жизнь?

Во дворике с нормальными поцанами, пивасикм и семечками, дело известное.

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

А чтобы смена деталей реализации ничего не ломала, нужен DIP.

«чтобы человек мог не потеряться» приводит к условиям, противоречащим SOLID

Чзх я только что прочетал? %)

Так кому, как …

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

У данных нет причин изменяться

Структуры данных падают нам с неба в совершенном, законченном виде. Понемаю.

Нет, я о том, что SRP не относится к данным.

Потому что тогда правки, вносимые по инициативе одной стороны, могут ломать функциональность, нужную другой. HR поправил UserInfo, и у продажников отвалилась статистика.

OCP же.

Архитектура обычного приложения на Си идеальна по ISP.

Кто-то мешает тебе бахнуть все 100500 функций в один файл?

Никто не мешает. По SOLID это прекрасная архитектура.

Лучше уж скриншотить свои тайлинговые WM'ы, чесн.

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

SRP не относится к данным.

Изменение схемы данных, спроектированной с нарушением SRP, не может теоретически порушить левую функциональность? Телл ми моар.

OCP же.

При чем тут OCP, я не понемаю.

По SOLID это прекрасная архитектура.

А как же разграничение интерфейсов? Если у тебя там и шитье, и жатва, и игра на дуде, то клиент, которому нужно только играть на дуде, вынужден зависеть от кучи левой функциональности, которой он не пользуется. Явное нарушение ISP.

Изменение схемы данных, спроектированной с нарушением SRP, не может теоретически порушить левую функциональность? Телл ми моар.

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

OCP же.

При чем тут OCP, я не понемаю.

Расширять, а не вносить изменения. Ты описал пример, где один модуль лез к другому в данные. Это нарушает OCP.

Да, не может

Разбили по требованию HR поле fullName на firstName и secondName и случайно внесли опечатку в название поля salesStats. Оно же там рядом, в соседней строчке. По сути, продажники получат люлей из-за товарища, который считает SRP излишним — это ведь у них на проде внезапно отвалилась статистика продаж. Они несут ответственность за эту функциональность.

Для любой структуры данных можно сделать функции с разделенной ответственностью

Не можно, а нужно! SRP об этом и говорит.

Ты описал пример, где один модуль лез к другому в данные. Это нарушает OCP.

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

Потому что они в одном модуле, Карл. Хотя не должны быть в одном модуле по SRP.

Разбили по требованию HR поле fullName на firstName и secondName и случайно внесли опечатку в название поля salesStats. Оно же там рядом, в соседней строчке. По сути, продажники получат люлей из-за товарища, который считает SRP излишним — это ведь у них на проде внезапно отвалилась статистика продаж. Они несут ответственность за эту функциональность.

Вопросы читаемости никогда в входили в круг ответственностей концепции SOLID.

Для любой структуры данных можно сделать функции с разделенной ответственностью

Не можно, а нужно! SRP об этом и говорит.

Само получится безо всяких SRP, при условии соблюдения OCP и DIP. Антипаттерн, требущий введения SRP, возникает только в ООП, и для решения проблемы, по сути, требует от ООП отказаться, убрав из структуры данных все методы, поскольку иначе будет совмещение ответственностей.

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

Потому что они в одном модуле, Карл. Хотя не должны быть в одном модуле по SRP.

Есть люди, которые бьют в форму «одна сущность - один файл». Читаемость у такой программы просто отвратительная - потому SRP убивает реальный проект. Нет никакой проблемы в том, чтобы засунуть близкий функционал, но все же разный, в один модуль.

Само получится

Дай-то б-г.

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

Это какое?

Блокнот. Бумажный.