Привет!

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

https://blog.cleancoder.com/uncle-bob/2023/01/18/functional-classes.html
https://blog.cleancoder.com/uncle-bob/2023/01/19/functional-classes-clojure.html

Советую почитать, даже если вы не интересуетесь ФП. Но интересоваться хотя бы ООП - надо:)

А после прочтения этих статей я наткнулся на ещё более огненный пост - https://habr.com/ru/companies/domclick/articles/732876/
Который так же упоминает посты анкл Боба.

Совпадение? Не думаю 🤯🤔

#posts@ergonomic_code #clojure@ergonomic_code #oop@ergonomic_code

Привет!

Листаю Designing object-oriented software и наткнулся на такой же тест как и у меня тест на разумность декомпозиции:)

За одно ещё раз попиарю - https://archive.org. Там после бесплатной регистрации можно легально откопать редкие и интересные книги:)

Единственное не удобство - читать только на сайте и раз в час надо заново "занимать" книгу.

#books@ergonomic_code #oop@ergonomic_code

Привет!

Проживаю очередной кризис нигилизма:
1) ООП - нахер, эта фигня никогда не работала для информационных систем
2) ООД - нахер, эта фигня не масштабируется ([1], [2])
3) DDD - нахер, таш самая дичь, что и микросервисы - нужно и возможно только в 1% проектов, а в остальных - только удоржает разработку и тешит самолюбие разработчиков
4) Сокрытие информации - нахер, в рамках одного проекта над которым работает одна команда (а то и один человек) - это попахивает шизофринией
5) Open-Closed Principle и Dependency Inversion Principle и Чистая архитектура - нахер (пока реализация одна), эта хрень только усложняет кодовую базу и удорожает разработку
6) Low Coupling/High Cohesion - нахер, это какая-то непонятная дичь. На самом деле - тут тоже "пока что-то" или ещё какое-то условие, но вот что за условие - я ещё не понял.
7) Information Expert - нахер, эта фигня не масштабируется

А что не нахер?
1) DRY - это то, что позволяет снизить стоимость (гемморой для разработчика) внесения изменений
2) KISS - это то, что позволяет снизить стоимость (гемморой для разработчика) внесения изменений
3) Отсутствие циклов в зависимостях - это первое средство борьбы с Big Ball of Mud (упращения кодовой базы)
4) Неизменяемя модель данных - второе средство борьбы с Big Ball of Mud (упращения кодовой базы)
5) Структурный дизайн/функциональная архитектура - третье средство борьбы с Big Ball of Mud (упращения кодовой базы)
6) Единство уровня абстракции/SRP - четвёртое средство борьбы с Big Ball of Mud (упращения кодовой базы)
7) Очевидность связей (сцепленности?)/локальность рассуждений о коде - пятое средство борьбы с Big Ball of Mud (упращения кодовой базы)
8) Классическая школа ТДД - единственное (известное мне) надёжное средство борьбы с регрессиями -> возможность свободно улучашть качество кодовой базы
9) Базовая модель информационных систем в виде операций, ресурсов и эффектов - это то, чем информационные системы являются по своей сути

Вобщем "гамак-дривен" девелопмен эргономичной структуры программ в3 продолжается (второе полугодие), но вроде процесс начал сходиться.

P.s.

1) добротный и двольно свежий пост с обзором и сравнением основных архитектур
2) И в дополнение - более подробный разбор вертикальной архитектуры

#ergo_approach@ergonomic_code #oop@ergonomic_code #ddd@ergonomic_code #design@ergonomic_code

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

Я поленился написать обзор на Fundamentals of Software Architecture: An Engineering Approach, которую недавно прочитал и которая, на самом деле, мне понравилась намного больше, чем Software Architecture: The Hard Parts, а меж тем там авторы пишут про Connascence - аналог Coupling для ОО-систем.

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

В общем рекомендую вам и Fundamentals of Software Architecture: An Engineering Approach прочитать и Connascence погуглить.

Ну и сам я рано или поздно её разберу подробно и напишу о ней пост.

#books@ergonomic_code #oop@ergonomic_code #couplingergonomic_code

Привет!

Если долгими томными вечерами вы как и я любите позаниматься странным - например, почитать древние научные статьи на английском - то рекомендую почитать статью VALUES AND OBJECTS IN PROGRAMMING LANGUAGES, которая рассматривает с математически-философской точки зрению разницу между объектами и данными (ака сущностями и объектами-значениями).

ТЛДР - объекты изменяемые, а данные - нет; и в реальной жизни надо и то и то.

Ещё пара хлёстких цитат оттуда:
1) "Computer science - это объектно-ориентированная математика"
2) Программирование - это объектно-ориентированная математика, математика - это "value-oriented" программирование.

Эта статья подтолкнула меня поискать объекты в Trainer Advisor. И хотя конструкция object встречается 17 раз, изменяемый объект я нашёл только один - билдер динамических запросов. И то он изменяемый только потому, что Котлин (пока?) не достаточно data-oriented и не поддерживает литералы списков и мап.

В общем жить в прикладном коде без объектов - вполне реально.
Если не знаете, как сделать сущности неизменяемыми - с помощью эпохальной модели времени (видео, текст)

#papers@@ergonomic_code #oop@ergonomic_code #dop@ergonomic_code

Привет!

Забрёл сегодня в блог анкл Боба, там наткнулся на древний пост, а там:

OO is not about state.
Objects are not data structures. Objects may use data structures; but the manner in which those data structures are used or contained is hidden. This is why data fields are private. From the outside looking in you cannot see any state. All you can see are functions. Therefore Objects are about functions not about state.
When objects are used as data structures it is a design smell; and it always has been. When tools like Hibernate call themselves object-relational mappers, they are incorrect. ORMs don’t map relational data to objects; they map relational data to data structures. Those data structures are not objects.
Objects are bags of functions, not bags of data.

#posts@ergonomic_code #oop@ergonomic_code

Мысль четвёртая

А ну и мысль четвёртая - если вы пишите бэки - вам надо ФП/ФА, а не ООП/DCI :)

Точнее DOP/ФА как здесь, а не чистый ФП как здесь

#dop@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code

Привет!

Предистория.

Как вы знаете, я недавно ходил в гости к javaswag. Но, возможно, вы (как и я до этой записи) не знаете, что javaswag – это не только звук, но и нарезка видео, и небольшие тексты с комментариями к ссылкам.

У меня ссылок было аж 19 штук и Дима предложил сделать развёрнутые комментарии к ссылкам.
Но внезапно оказалось, что я не умею писать комментарии к ссылкам и вместо комментариев у меня как обычно вышел небольшой пост-очерк “Что такое ООП?”.
Но пост – уже не формат для javaswag, поэтому я его представляю вам у себя.

—-

История

В книге “What every programmer should know about object-oriented design” Пейдж-Джонс на первой же странице пишет:

Термин “объектно-ориентированный”, по сути своей, бессмысленен. “Объект” — это одно из самых общих слов в английском языке. Если вы посмотрите его значение в словаре, то увидите что-то вроде:

Объект — вещь, представленная или которую можно представить чувствам [человека].

Другими словами, объект - это практически всё что угодно.

Слово “ориентированный” также не особо помогает. Опредёленное как “направленный в сторону”, оно обычно используется для превращения термина “объекто-ориентированный” в прилагательное.
Таким образом, мы имеем:

Объектно-ориентированный — направленный в сторону практически чего угодно, о чём вы можете только подумать.

Не удивительно, что наша индустрия не смогла договориться об определении термина “объектно-ориентированный”.

Наверное, если провести опрос среди разработчиков, то самым популярным ответом будет “ООП – это наследование, полиморфизм и инкапсуляция”. И последний выпуск javaswag (см. ответ на моё непопулярное мнение), кстати, это подтверждает.

Однако Алан Кей, автор термина, в одном из своих докладов заявил: “На самом деле это я придумал термин “объектно-ориентированный” и я могу сказать вам, что я не имел С++ ввиду”.
А имел он ввиду: обмен сообщениями, сокрытие состояния и экстремально позднее связывание.

И, как следствие, Джо Армстронг, создатель Erlang считает: “Erlang, возможно, является единственным объектно-ориентированным языком, потому что три принципа объектно-ориентированного программирования заключаются в передаче сообщений, изоляции между объектами и полиморфизмом. [...] ООП — это не про объекты и классы, ООП — это про сообщения”.

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

А что такое ООП для вас?

#oop@ergonomic_code #terminology@ergonomic_code #archeology@ergonomic_code #books@ergonomic_code

Привет!

Прочитал субстак про Radical Object-Orientation (автор его ещё дописывает)

Имхо - Эргономичная архитектура, только в профиль.

- PoMO - очень напоминает то, что у меня ресурс может быть включен только в один другой ресурс
- IOSP - очень напоминает сбалансированную форму системы
- У него тоже дизайн рекурсивен - атомарная операция ио с точки зрения оркестрации сама может оказаться оркестрацией на своём уровне абстракции
- Так же придерживатеся мнения, что абстракция != public interface - "Integrations are abstractions as well."
- Но у автора всё, включая интеграции - есть объект. У меня, по крайней мере синтаксически, объектами (штуками эксклюзивно владеющими собственными состоянием) являются только ресурсы, а операции - это скрипты которые заимствуют состояние ресурсов и тем самым разделяют его между собой. Но. Всё приложение в целом - можно считать объектом.

Из минусов:
- (Относительно) многа букаф и картинок и очень мало кода, а тот что есть - тривиальный и про консольные приложения
- Аналогия с клетками привлекательная, но не очень... Клетки действительно организуют очень крутые, сложные и адаптивные системы. Которые человечество за миллион человеко-часов понять не может - хотим ли мы поддерживать такие системы?
- А ещё я в #project_r@ergonomic_code опять (но теперь под другим углом) начал сталкиваться с тем, что инкапсуляция состояния плохо масштабируется, так как влечёт неограниченный рост поверхности АПИ ключевых/центральных/фундаментальных объектов-ресусров.

Вердикт: по принципу "повторение - мать учения" и "количество переходит в качество" - советую почитать. Но мне кажется у меня сейчас те же по сути идеи поданы лучше - как минимум у меня довольно много примеров реального кода, а не консольных утилиток.

#posts@ergonomic_code #ergo_approach@ergonomic_code #oop@ergonomic_code