Наверное, самое понятное объяснение природы 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

📝 "Если бы у Java был настоящий сборщик мусора, большинство программ удаляли бы себя во время исполнения." — Роберт Сьюэл 🙂

#Юмор

Многие знают про стандарт ISO/IEC/IEEE 42010:2011, но не все слышали про 42020 и 42030.

#SoftwareArchitecture

Вот как понимает OOP Robert C. Martin:

📝 "Объектно-ориентированное
программирование

Второй парадигмой, получившей широкое распространение, стала парадигма, в действительности появившаяся двумя годами ранее, в 1966-м, и предложенная Оле-Йоханом Далем и Кристеном Нюгором. Эти два программиста заметили, что в языке ALGOL есть возможность переместить кадр стека вызова функции в динамическую память (кучу), благодаря чему локальные переменные, объявленные внутри функции, могут сохраняться после выхода из нее. В результате функция превращалась в конструктор класса, локальные переменные — в переменные экземпляра, а вложенные функции — в методы. Это привело к открытию полиморфизма через строгое использование указателей на функции.

Подводя итог, можно сказать, что:

Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.

<...>

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

OBJECT-ORIENTED PROGRAMMING

The second paradigm to be adopted was actually discovered two years earlier, in 1966, by Ole Johan Dahl and Kristen Nygaard. These two programmers noticed that the function call stack frame in the ALGOL language could be moved to a heap, thereby allowing local variables declared by a function to exist long after the function returned. The function became a constructor for a class, the local variables became instance variables, and the nested functions became methods. This led inevitably to the discovery of polymorphism through the disciplined use of function pointers.

We can summarize the object-oriented programming paradigm as follows:

Object-oriented programming imposes discipline on indirect transfer of control.

<...>

What is OO? There are many opinions and many answers to this question. To the software architect, however, the answer is clear: OO is the ability, through the use of polymorphism, to gain absolute control over every source code dependency in the system. It allows the architect to create a plugin architecture, in which modules that contain high-level policies are independent of modules that contain low-level details. The low-level details are relegated to plugin modules that can be deployed and developed independently from the modules that contain high-level policies."
- "Clean Architecture: A Craftsman’s Guide to Software Structure and Design" by Robert C. Martin

Его статья "Three Paradigms"
https://blog.cleancoder.com/uncle-bob/2012/12/19/Three-Paradigms.html

#OOP #SoftwareDesign

"Шпаргалка по функциональному программированию" - Блог компании Яндекс

https://habr.com/ru/company/yandex/blog/547786/

#FunctionalProgramming

"От внедрения зависимостей к отказу от зависимостей" - Mark Seemann, перевод Максима Аршинова
https://habr.com/ru/company/jugru/blog/545482/

#FunctionalProgramming #SoftwareDesign

"Reporting models and Event Sourcing" by Alexey Zimarev ( @zimareff )
https://zimarev.com/blog/event-sourcing/changes-in-event-sourced-systems/

#DDD #EventSourcing #SoftwareDesign #SoftwareArchitecture

"Say hello to Eventuous" by Alexey Zimarev ( @zimareff )
- https://zimarev.com/blog/event-sourcing/say-hello-to-eventuous/

A minimalistic Event Sourcing library for .NET
- https://github.com/Eventuous/eventuous

#DDD #EventSourcing #SoftwareDesign #SoftwareArchitecture

"The dispassionate developer" by Mark Seemann
https://blog.ploeh.dk/2021/03/22/the-dispassionate-developer/

Только сегодня его вспоминали) Неплохая, кстати, статья.

#Career

"A recipe for gradually migrating from CRUD to Event Sourcing" by Dennis Doomen
https://www.eventstore.com/blog/a-recipe-for-gradually-migrating-from-crud-to-event-sourcing

#DDD #EventSourcing #SoftwareDesign #SoftwareArchitecture

Коллеги поделились мультиком о Скраме 😂))
https://coub.com/view/253kyu

#Agile #Юмор

"Trannoscript of Greg Young's Talk at Code on the Beach 2014: CQRS and Event Sourcing" by Greg Young
https://www.eventstore.com/blog/trannoscript-of-greg-youngs-talk-at-code-on-the-beach-2014-cqrs-and-event-sourcing

#DDD #EventSourcing #CQRS #SoftwareDesign #SoftwareArchitecture

Современное определение OOP:

📝 "Объектно-ориентированное программирование — это метод программирования, основанный на представлении программы в виде
совокупности взаимодействующих объектов, каждый из которых является экземпляром определенного класса, а классы являются членами определенной иерархии наследования.

Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."

📝 "Объектно-ориентированное программирование (object-oriented programming). Методология программирования, в которой программы представляют собой совокупности взаимодействующих объектов, каждый из которых является экземпляром определенного класса, входящего в иерархию классов, связанных отношением наследования. В таких программах классы обычно считаются статичными сущностями, а объекты имеют более динамичную природу, поддерживаемую механизмами динамического связывания и полиморфизма.

Object-oriented programming.
A method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships. In such programs, classes are generally viewed as static, whereas objects typically have a much more dynamic nature, which is encouraged by the existence of dynamic binding and polymorphism."

- "Object-Oriented Analysis and Design with Applications" 3rd edition by Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young Ph.D., Jim Conallen, Kelli A. Houston

Кстати, есть мнение, что тут не обошлось без коммерции:

📝 "OO is merely a clever and successful MarketingScheme which has made Grady Booch a wealthy man. -- Daniel Brockman"
https://wiki.c2.com/?NobodyAgreesOnWhatOoIs

#OOP #SoftwareDesign