Привет!

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

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

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

Привет!

Наткунлся на прикольную статью об объектах и абстрактных типах данных. Не особо практичная, именно прикольная - автор приходит к выводу, что функции высших порядков чаще используются в ОО, чем ФП программах, и что лямбда исчесления были "untyped λ-calculus was the first object-oriented language.":)

Более практично же обеъекты и АДТ рассмотрены в этой статье.

Если в кратце - объекты не должны быть единственным инструментом разработчка. Объекты надо применять, когда вероятность появления новых типов (наследников, реализаций интерфейсов), выше вероятности появления новых данных - в этом случае "данные" (Алгебраические типы данных), позволят добавить их не трогая старый код.

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

#papers@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code

Привет!

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

И вот наткнулся на этот же тезис у Фаулера в статье об анемичной доменной модели:
> The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk. What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.

#posts@ergonomic_code #oop@ergonomic_code

Привет!

Прочитал Implementation Patterns Бека.
Я не сторонник императивного ООП, с активным использованием наследования, поэтому опять же не готов занести эту книгу в маст рид.

Но лучше писать код так, как пишет Бек, чем в процедурном стиле с классами.

Что поддерживаю:
1) Код должен хорошо передавать собственный смысл
2) Симметрия и эстетика являются признаками хорошего кода с практической и экономической точки зрения
3) В целом на главах 1-4 у меня было по несколько закладок на каждой странице - в базовых ценностях и философии программирования мы с Беком сходимся
4) Следует избегать использования геттеров и сеттеров
5) Явное разделение рекомендаций для разработки прикладных программ и фреймворков. Всегда надо держать в голове над каким типом кода вы работаете и принимать это во внимание при принятии всех решений. Например, тот же OCP, значительно менее актуален для разработки прикладных програм

#books@ergonomic_code #oop@ergonomic_code

Привет!

У меня тут мега инсайт. Я лет 8 назад разочаровался в ООП и с тех пор говорил, что это облажавшая хрень, которая, на самом деле не захватила мир и миром всё ещё правит ПП.

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

Поэтому я время от времени читаю книги по ООП/ООД и сейчас читаю Designing object-oriented software.

Я там сразу обратил внимание на примеры - банкомат и редактор документов.
Тут у меня появилась идея, что может ООП не в целом облажалось, а просто (внезапно) не является серебренной пулей и не стрельнуло в моей отрасли разработки ПО - информационных системах? Пошёл смотреть другие примеры.

Applying UML and Patterns - автоматизация кассы

Object Oriented Software Construction - система резирвации авиа билетов с фокусом на UI, undo в интерактивной систему

Object-Oriented Software Engineering: A Use Case Driven Approach - система управления складом с фокусом на UI, телеком

Object Design: Roles, Responsibilities, and Collaborations - система общения парализованных людей, по средствам моргания глазами

Object-Oriented Analysis and Design with Applications - спутниковая навигация, система управления трафиком, криптоанализ, наблюдение за погодой, система управления отпусками (вот кажись единственный похожий пример)

Working with objects: The OOram Software Engineering Method - "business information system" но на беглый взгляд, фокус всё равно на UI, система реального времени, фреймворк

The Object-Oriented Thought Process - игра в 21

Head First Object-Oriented Analysis and Design - информационная система магазина гитар, но на списках:(

Львиная доля примеров - сильно отличаются от того, с чем работаю я. Там либо высокоинтерактивная система, либо активная работа с оборудованием, либо UI.

Так что, наверное, для ООП есть место в мире, просто не моём:)

А для разработки информационных систем я советую:
1) следовать ООД при декомпозиции системы на подсистемы - каждая подсистема должна инкапсулировать в себе какую-то часть состояния всей системы, и предоставлять публичное АПИ для его изменения
2) следовать функциональной архитектуре в реализации отдельных подсистем - разбивать код на чистое ядро с бизнес-правилами, и императивную оболочку с вводом- выводом
3) максимум кода тащить в чистое ядро и делать это ядро понастоящему чистым - с неизменяемыми структурами данных и функциями без эффектов
4) а императивную оболочку делать максимально тонкой, прямолинейной и простой

#oop@ergonomic_code #books@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Накатал потока-сознания-пост о том, что я имею ввиду под ОО-подходом.

#terminology@ergonomic_code #oop@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Линко-пост

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

Только мужик говорит быстро и слушать сложно:(

Поэтому вот ещё ссылка из доклада на тему ОО/П.

Ну а для совсем ленивых, мой главный инсайт из этой статьи:
> Alan Kay was interested in personal computing. His work on FLEX, the Dynabook, and Smalltalk all revolve around that. In his vision, the PC would be a something totally under the user’s control, everything from core system logic to the graphic rendering tweakable and explorable at runtime. Message passing and late binding solve a lot of problems here. If a kid installs a new game, should they have to recompile the entire OS to use the new program? No: make it so that you can send any arbitrary message to any object and rely on runtime protocol-handling to fix it.1 If a person clobbers the sound logic, should the whole OS crash? Of course not, so allow objects to decide how to handle messages themselves. This is a place where objects shine.

Ole-Johan Dahl and Kristen Nygaard were trying to solve a completely different problem. They were interested in simulation. One of the case studies in the Simula manual is modeling the spread of infection across a fixed population. The system is completely closed: you have a fixed set of code, you run your simulation, you get your output. For them, message passing isn’t useful. But things like being able to define simulations in terms of other simulations, specialize entities, and model time as a first-class object are incredibly useful. This is also a place where objects shine!

И прям выжимка-перевод - Кей решал задачу с открытым миром, где новые типы объектов появлялись в системе прямо в рантайме. И тут объекты блистали. Авторы Симулы решали задачи симуляции. И тут объекты тоже блистали.

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

#talks@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code

Заодно находка-любопытка. Вы читали Чистый код анкл Боба? В частности раздел "Антисимметрия данных/объектов"?

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

В любой сложной системе возникают ситуации, когда вместо новых функций в систему требуется включить новые типы данных. Для таких ситуаций объекты и объектно-ориентированное программирование особенно уместны. Впрочем, бывает и обратное — вместо новых типов данных требуется добавить новые функции. Тогда лучше подходит процедурный код и структуры данных.

Вам не кажется, что в информационных системах чаще требуется добавлять новые функции, чем (варианты) типов данных?

Но в этом случае, естественно, ещё лучше функциональный код и неизменяемые структуры данных

#oop@ergonomic_code #dop@ergonomic_code

Привет!

Свинья везде найдёт грязь, а я - в любой книжке по ООП агитацию за ФП.

В рамках подготовки поста об ОО декомпозиции полез кое-чего глянуть в Object-Oriented Software Construction. И пока искал, наткнулся на раздел "23.1 SIDE EFFECTS IN FUNCTIONS". Там достаточно хорошо описано что такое побочный эффект, чем он опасен и как отделять чистые функции от функций с эффектом (это тот самый CQS, если вы понимаете о чём я).

И вообще в этой книге много мудрости, например OCP анкл Боб взял оттуда (хотя и подменил суть, по большому счёту).

Единственное что, Мейер там сильно заблуждается на счёт значимости и практики применения механизма наследования, но это всеобщее помутнение сознания тех лет (конца 80-ых) и вполне простительно.

В общем рекомендую почитать на досуге.

#books@ergonomic_code #whyfp@ergonomic_code #oop@ergonomic_code

Привет!

Пара ссылок, где анкл Боб рассказывает про ООП на чисто функциональном языке (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