Слайд 70 заслуживает отдельного поста. Варианты реализации OO/Functional Aggregates на примере Reference Applications by Chris Richardson:

Traditional OO mutable Domain Objects:
- https://github.com/cer/event-sourcing-examples/tree/master/java-spring

Functional Scala witn immutable Domain Objects:
- https://github.com/cer/event-sourcing-using-scala-typeclasses

Hybrid OO/Functional Scala with immutable Domain Objects:
- https://github.com/cer/event-sourcing-examples/tree/master/scala-spring

#DistributedSystems #EIP #EDA #DDD #Microservices #Golang #SoftwareArchitecture #SoftwareDesign

Листаю сейчас книжечку "Теоретический минимум по Computer Science", Фило Владстон.

В оригинале называется "Computer Science Distilled" by Wladston Ferreira Filho.

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

Содержит основы математики (логика, комбинаторика, вероятность), алгоритмы и структуры данных, основы Баз Данных (RDBMS, NoSQL), описание Парадигм Программирования и основы архитектуры железа.

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

#Algirithms #Basics #Math

P.S.: эту же информацию (Retry pattern) можно найти еще и в каталоге Cloud Design Patterns:
- https://docs.microsoft.com/en-us/azure/architecture/patterns/retry

#Microservices

Rob Pike, оказывается, кроме Golang, любит покодить интерпретатор функционального языка программирования... на Golang... Так что, теперь уже никто не скажет, что FP и Golang несовместимы 🙂))

📝 "This program was a joy to put together. Its purpose was fun and education, and in no way to create a modern or even realistic Lisp implementation."
- https://github.com/robpike/lisp

#FunctionalProgramming #Golang

📝 "Сначала художник рисует плохо и просто. Потом сложно и плохо. Потом сложно и хорошо. И только потом - просто и хорошо."
- И.Е. Репин

#SoftwareDesign #SoftwareArchitecture

> "Сначала художник рисует плохо и просто. Потом сложно и плохо. Потом сложно и хорошо. И только потом - просто и хорошо." - И.Е. Репин

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

#SoftwareDesign #SoftwareArchitecture

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

Для многих людей отправной точкой понимания OOP являются известные письма Alan Kay (стоит сразу отметить, что этот вопрос - дискуссионный, но мы беспристрастно рассмотрим различные точки зрения):

- http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

- http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

Я выделю главное из них:

📝 "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
- Alan Kay

📝 "I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful)."
- Alan Kay

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

Почему Alan Kay? Потому что он считается автором термина Object-Oriented, хотя история самой OO-парадигмы уходит, как мы увидим, несколько глубже (вплоть до https://wiki.c2.com/?SimulaLanguage , и даже https://wiki.c2.com/?SketchPad ), а Alan Kay придумал только часть этого термина ( https://wiki.c2.com/?HeDidntInventTheTerm )

На эту тему есть страницы на сайте Ward Cunningham (как всегда, информация с его сайта бесценна):

- https://wiki.c2.com/?DefinitionsForOo

- https://wiki.c2.com/?NobodyAgreesOnWhatOoIs

- https://wiki.c2.com/?NygaardClassification

- http://wiki.c2.com/?AlanKayOnMessaging

- http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

- https://wiki.c2.com/?AlanKayOnObjects

- http://wiki.c2.com/?MessageOrientedProgramming

- http://wiki.c2.com/?ObjectOriented

- https://wiki.c2.com/?ObjectOrientedProgramming

- https://wiki.c2.com/?ObjectOrientedPurity

- https://wiki.c2.com/?OoFitsOurMentalAbilities

И интересное видео от David Wast:
- "David West OOP is Dead! Long Live OODD!"
https://www.youtube.com/watch?v=RdE-d_EhzmA

Grady Booch упоминает две фундаментальные статьи, оказавшие значительное влияние на становление OOP:

📝 "His is one of the influential papers [David Parnas' 1972 paper]; the work by Liskov on abstract data types was also very important"
https://twitter.com/Grady_Booch/status/1302747652426145793?s=19

Вот они:
1. "On the Criteria To Be Used in Decomposing Systems into Modules (1972)" by D. L. Parnas
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.132.7232

2. "Programming with Abstract Data Types (1974)" by Barbara Liskov, Stephen
https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.136.3043
и
"Abstraction mechanisms in CLU." by B. Liskov, A. Snyder, R. Atkinson, and C. Schaffert. Communications of the ACM, 20:564–576, 1977.
https://web.eecs.umich.edu/~weimerw/2011-6610/reading/liskov-clu-abstraction.pdf

Более подробно историю OOP вы можете посмотреть в главе "2.2 Foundations of the Object Model" книги "Object-Oriented Analysis and Design with Applications" 3rd edition by Grady Booch and others. Там он приводит еще несколько статей, сыгравших значительную роль в истории OOP.

Есть еще интересная история от Ward Cunningham:
- https://wiki.c2.com/?InformalHistoryOfProgrammingIdeas

И история OOP от его пионеров - основателей Simula:
- https://web.archive.org/web/20021210082312/http://www.ifi.uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_OO_start.html

Как уже говорилось ранее ( https://news.1rj.ru/str/emacsway_log/393 ), самая большая проблема в разработке - это неясность намерений автора. С OOP - тоже самое. Информации много, но мало кто понимает, какую проблему оно призвано решить. Непонимание его целей приводит к некорректному его применению, что, в свою очередь, приводит к недовольству его применением. Непонимание его целей не позволяет оценить эффективность его применения.

Поэтому, мы начнем с цели OOP в следующих постах.

#OOP #SoftwareDesign

Начнем с определения OOP и его целей от Kristen Nygaard, который считается соавтором (вместе с Ole Johan Dahl) OO-парадигмы, хотя и не автором OOP термина.

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

📝 "Object-Oriented Programming. A program execution is regarded as a physical model, simulating the behavior of either a real or imaginary part of the world."

📝 "The notion of a physical model should be taken literally. Most people can imagine the construction of physical models by means of, for example, Lego bricks. In the same way, a program execution may be viewed as a physical model. Other perspectives on programming are made precise by some underlying model defining equations, relations, predicates, etc. For object-oriented programming, however, we have to elaborate on the concept of physical models."

- Kristen Nygaard, https://wiki.c2.com/?NygaardClassification

📝 "It is difficult to discuss the benefits of object-orientation without first defining it. Before introducing the BETA approach, however, we shall briefly discuss what the benefits of object-orientation are considered to be. There are three main benefits: real world apprehension, stability of design and reusability of both designs and implementations. When people disagree about what object-orientation is, it is often because they attach different levels of importance to these aspects. We consider all three aspects to be important, though perhaps not equally so."

📝 "(Krogdahl and Olsen, 1986) (translated from Norwegian) put it this way:
‘The basic philosophy underlying object-oriented programming is to make the programs as far as possible reflect that part of the reality they are going to treat. It is then often easier to understand and to get an overview of what is described in programs. The reason is that human beings from the outset are used to and trained in the perception of what is going on in the real world. The closer it is possible to use this way of thinking in programming, the easier it is to write and understand programs.’"

- "Object-Oriented Programming in the BETA Programming Language" by Ole Lehrmann Madsen, Birger Møller-Pedersen, Kristen Nygaard
https://www.researchgate.net/publication/220695504_Object-Oriented_Programming_in_the_BETA_Programming_Language

#OOP #SoftwareDesign

В предыдущем сообщении было рассмотрено мнение людей, которые считаются первооткрывателями OO-парадигмы (если не учитывать https://wiki.c2.com/?SketchPad ). Теперь можно рассмотреть мнение человека, который считается автором OO-термина (если не учитывать https://wiki.c2.com/?HeDidntInventTheTerm ).

О том, что Alan Kay понимает под OOP, уже говорилось в здесь: https://news.1rj.ru/str/emacsway_log/415

Но более интересно то, решение какой задачи он возлагал на OOP. Он озвучивает интересную метафору сравнения с интернетом (позже мы услышим похожую метафору, но с операционной системой, от N.Wirt).

📝 "The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas."
- Alan Kay, http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

📝 "Though OOP came from many motivations, two were central. The large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether. As with most new ideas, it originally happened in isolated fits and starts."
- "The early history of Smalltalk", by Alan C. Kay, Apple Computer

OOP имеет много общего с моделью вычислений (что не является парадигмой):

📝 "The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.

Versions of Smalltalk before Smalltalk-80 were still largely based on the (asynchronous, unidirectional) ActorsModel of computation, but with Smalltalk-80, the developers of SmalltalkLanguage switched entirely to the (synchronous, bidirectional) procedural model, while misleadingly retaining the ActorsModel terminology (such as "messages" for what essentially are procedure calls rather than one-way notifications).

This has caused endless terminological difficulties especially when considering that the the other major sources of OO thinking--capability architectures and the SIMULA 67 research--were not in the least inspired by ActorsModel thinking."
- http://c2.com/wiki/remodel/?AlanKaysDefinitionOfObjectOriented

И тем не менее, кто бы что не говорил, Alan Kay прямым текстом называет OOP парадигмой:

📝 "Though it has noble ancestors indeed, Smalltalk's contribution is a new design paradigm—which I called object-oriented—for attacking large problems of the professional programmer, and making small ones possible for the novice user. Object-oriented design is a successful attempt to qualitatively improve the efficiency of modeling the ever more complex dynamic systems and user relationships made possible by the silicon explosion."
- "The early history of Smalltalk", by Alan C. Kay, Apple Computer

Заканчивает эту книгу Alan Kay своим видением развития OOP:

📝 "This higher computational finesse will be needed as the next paradigm shift—that of pervasive networking —takes place over the next five years. Objects will gradually become active agents and will travel the networks in search of useful information and tools for their managers. Objects brought back into a computational environment from halfway around the world will not be able to configure themselves by direct protocol matching as do objects today. Instead, the objects will carry much more information about themselves in a form that permits inferential docking. Some of the ongoing work in specification can be turned to this task [Guttag][Goguen ]."
- "The early history of Smalltalk", by Alan C. Kay, Apple Computer

#OOP #SoftwareDesign

Наверное, самое понятное объяснение природы OOP дает Niklaus Wirt:

📝 "ЧТО ТАКОЕ «ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ»?
Глубинный смысл этой концепции с точки зрения автора заключается в децентрализованном управлении. Первым примером, наглядно поясняющим идею, может служить операционная система. Обычно она состоит из центральной процедуры, которая воспринимает ввод с клавиатуры и передает управление процедуре, отвечающей за интепретацию команд. Еще более простым примером может служить операционная система обычного настольного калькулятора, которая выбирает процедуру, соответствующую нажатой функциональной кнопке."

- Niklaus Wirth (1990) Modula-2 and Object-Oriented Programming // Microprocessors and Microsystems, Vol.14, No.3, p.149-152.
- http://www.uni-vologda.ac.ru/oberon/infoart/m2&oop.htm
- http://hosting.vspu.ac.ru/~chul/wirth/pdf/m2_oop.pdf

#OOP #SoftwareDesign

Niklaus Wirt о том, при каких обстоятельствах внедрялось OOP:

📝 "Как это ни печально, но в области компьютерных наук слишком уж господствуют модные поветрия. Появляясь, как правило, в период обострения проблем, они преподносятся как сильнодействующее средство для тяжелобольных и живут за счет надежд тех, кто находится в отчаянном положении. В программном обеспечении и в программировании вообще часто употребляется термин «кризис программного обеспечения», о котором впервые открыто заговорили в 1968 году и который сделал популярным структурное программирование. Был признан тот факт, что сложное программное обеспечение может быть понято только тогда, когда оно упорядочено и структурировано. Разработка огромных систем, где задействованы армии «аналитиков», со всей очевидностью доказывает необходимость координации работ, документирования и соблюдения соглашений, которые должны быть представлены в виде спецификаций интерфейсов. Руководство (management) становится доминирующим фактором, и все упомянутые аспекты так или иначе покрываются новой волной, которая носит название «инженерия программного обеспечения» (software engineering). Все это настоятельно требует по-настоящему профессионального подхода.

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

- Niklaus Wirth (1990) Modula-2 and Object-Oriented Programming // Microprocessors and Microsystems, Vol.14, No.3, p.149-152.
- http://www.uni-vologda.ac.ru/oberon/infoart/m2&oop.htm
- http://hosting.vspu.ac.ru/~chul/wirth/pdf/m2_oop.pdf

#OOP #SoftwareDesign

Niklaus Wirt про ООП:

📝 "Многие люди относятся к стилям и языкам программирования как к религиозным конфессиям: если вы принадлежите к одной из них, то не можете принадлежать к другой. Но это ложная аналогия, и она сознательно поддерживается по причинам коммерческого порядка. Объектно-ориентированное программирование вышло из принципов и понятий традиционного процедурного программирования. Скажу больше: в ООП не добавлено ни одного действительно нового понятия; просто по сравнению с процедурным оно делает значительно более сильный акцент на двух понятиях. Первое - это привязка процедуры к составной переменной, что и послужило оправданием для введения терминов "объект" и "метод". Средством для такой привязки является процедурная переменная (или поле записи - record field), доступная в языках программирования с середины 70-х гг. Второе понятие - это конструирование нового типа данных (названного "подкласс") путем расширения заданного типа ("суперкласс").

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

Тем не менее, я склонен рассматривать ООП как аспект более общего понятия "программирования в большом" (programming in the large) - тот аспект, что логически следует за "программированием в малом" (programming in the small) и уже поэтому требует надлежащего знания процедурного программирования. Статическая модуляризация - это первый шаг навстречу ООП; этот аспект намного легче понять и освоить, чем полное ООП, к тому же в большинстве случаев этого достаточно для написания хороших программ. Вот почему очень жаль, что этим аспектам в большинстве языков пренебрегли (за исключением Ada).

Я бы не сказал, что распространившаяся практика ООП реализовала все свои потенции. Наша конечная цель - расширяемое программирование (extensible programming). Под этим я понимаю возможность конструирования таких иерархий модулей, когда каждый модуль добавляет новую функциональность в систему. Расширяемое программирование подразумевает, что добавление модуля возможно без необходимости вносить какие-либо изменения в существующие модули - не должно быть необходимости даже их перекомпилировать. Новые модули не только добавляют новые процедуры, но - что более важно - добавляют также новые (расширенные) типы данных. Мы продемонстрировали практичность и экономичность этого подхода при проектировании Oberon System."
- "Никлаус Вирт о культуре разработки ПО", Карло Пешио, интервью с Niklaus Wirt
https://www.osp.ru/os/1998/01/179366/

#OOP #SoftwareDesign

Заслуживающая внимания новая статья от Nick Tune - "Nurturing Design in Your Software Engineering Culture"
https://medium.com/nick-tune-tech-strategy-blog/nurturing-design-in-your-software-engineering-culture-3f960d321af

#DDD #SoftwareDesign #SoftwareArchitecture

Awesome Domain Storytelling
- https://github.com/hofstef/awesome-domain-storytelling

#DDD #SoftwareDesign #SoftwareArchitecture #EventStorming #DomainStorytelling

Запись сегодняшнего ТелеграмХауса, посвященного вопросам DDD, который состоялся сегодня в большом архитектурном чате Максима Смирнова: https://news.1rj.ru/str/it_arch/1030

#DDD #SoftwareArchitecture

Alan Kay сравнивает OOP с биологическими клетками и интернетом, Niklaus Wirt - с операционной системой, а Bertrand Meyer - с рыночной экономикой:

📝 "Политика невмешательства в обществе модулей

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

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

Не следует чересчур увлекаться этой аналогией (как и всякой другой): эта работа не учебник по экономике и она не содержит даже намеков на точку зрения автора в этой области. Сейчас нам достаточно отметить поразительные аналогии подхода абстрактных типов данных с некоторыми теориями о взаимодействии агентов-людей.

A laissez-faire policy for the society of modules

The method just outlined for describing data structures shows a rather selfish approach to the world of data structures: like an economist of the most passionate supply-side, invisible-hand, let-the-free-market-decide school, we are interested in individual agents not so much for what they are internally as for what they have to offer to each other. The world of objects (and hence of software architecture) will be a world of interacting agents, communicating on the basis of precisely defined protocols.

The economic analogy will indeed accompany us throughout this presentation; the agents — the software modules — are called suppliers and clients; the protocols will be called contracts, and much of object-oriented design is indeed Design by Contract, the noscript of a later chapter.

As always with analogies, we should not get too carried away: this work is not a textbook on economics, and contains no hint of its author’s views in that field. It will suffice for the moment to note the remarkable analogies of the abstract data type approach to some theories of how human agents should work together. Later in this chapter we will again explore what abstract data types can tell us beyond their original area of application."
- "Object-Oriented Software Construction" 2nd edition by Bertrand Meyer

#OOP #SoftwareDesign