Конспект известной статьи V.Vernon о моделировании агрегатов:
https://m.habr.com/ru/post/543424/
(Источник)
#DDD
https://m.habr.com/ru/post/543424/
(Источник)
#DDD
Хабр
Эффективная конструкция агрегатов. Моделирование одиночного агрегата
Эта статья является конспектом материала Effective Aggregate Design Part I: Modeling a Single Aggregate . Объединение сущностей (entities) и объектов значений (value objects) в агрегат с тщательно...
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
> "Увидел пару switch case — сразу городи иерархию классов. Так ведь в книжке написано." Здесь есть два важных момента, но рассмотрим мы только технический. По всей видимости, речь идет о книге "Refactoring: Improving the Design of Existing Code" by Martin…
Статья С.Теплякова о Switch Statement:
"Что не так с оператором switch?"
- http://sergeyteplyakov.blogspot.com/2016/08/whats-wrong-with-switch-operator.html
#SoftwareDesign
"Что не так с оператором switch?"
- http://sergeyteplyakov.blogspot.com/2016/08/whats-wrong-with-switch-operator.html
#SoftwareDesign
Blogspot
Что не так с оператором switch?
В обсуждении одного из моих ответов на ru.stackoverflow в G+ был поднят вопрос по поводу того, является ли оператор switch design или code...
К вопросу о паттернах проектирования:
"Шаблоны проектирования. История успеха"
- http://sergeyteplyakov.blogspot.com/2010/01/blog-post.html
#SoftwareDesign
"Шаблоны проектирования. История успеха"
- http://sergeyteplyakov.blogspot.com/2010/01/blog-post.html
#SoftwareDesign
Blogspot
Шаблоны проектирования. История успеха
Эта статья опубликована в 3-м номере журнала RSDN Magazine за 2009 год. Введение Шаблоны проектирования уже длительное время занимают по...
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Ну и, чтобы уже закрыть тему Outbox, то стоит упомянуть несколько полезных ссылок по Transaction log tailing (Transaction log mining): - https://www.postgresql.org/docs/11/sql-notify.html - https://www.postgresql.org/docs/11/sql-createpublication.html - …
Тут как раз Chris Richardson написал blog-post, затрагивающий проблему atomicity and resiliency of event publishing:
"Events on the outside, on the inside and at the core" by Chris Richardson
http://chrisrichardson.net/post/microservices/2021/02/21/events-are-the-core.html
Слайды заслуживают внимания. Также они демонстрируют сегодняшние тренды в микросервисной архитектуре, и какую роль в этом играет DDD.
#DistributedSystems #EIP #EDA #DDD #Microservices #Golang #SoftwareArchitecture #SoftwareDesign
"Events on the outside, on the inside and at the core" by Chris Richardson
http://chrisrichardson.net/post/microservices/2021/02/21/events-are-the-core.html
Слайды заслуживают внимания. Также они демонстрируют сегодняшние тренды в микросервисной архитектуре, и какую роль в этом играет DDD.
#DistributedSystems #EIP #EDA #DDD #Microservices #Golang #SoftwareArchitecture #SoftwareDesign
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Тут как раз Chris Richardson написал blog-post, затрагивающий проблему atomicity and resiliency of event publishing: "Events on the outside, on the inside and at the core" by Chris Richardson http://chrisrichardson.net/post/microservices/2021/02/21/events…
Слайд 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
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
GitHub
event-sourcing-examples/java-spring at master · cer/event-sourcing-examples
Example code for my building and deploying microservices with event sourcing, CQRS and Docker presentation - cer/event-sourcing-examples
Листаю сейчас книжечку "Теоретический минимум по Computer Science", Фило Владстон.
В оригинале называется "Computer Science Distilled" by Wladston Ferreira Filho.
У профильного специалиста она вряд ли вызовет большой интерес, а вот для свитчеров (т.е. для перешедших из других отраслей и не имеющих профильного образования по IT) - вполне полезное чтиво на пару сотен страниц. Минималистичный ликбез по теоретическим основам.
Содержит основы математики (логика, комбинаторика, вероятность), алгоритмы и структуры данных, основы Баз Данных (RDBMS, NoSQL), описание Парадигм Программирования и основы архитектуры железа.
Если бы немного увеличить глубину знаний в ней, то была бы ценным произведением не только для свитчеров.
#Algirithms #Basics #Math
В оригинале называется "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
- https://docs.microsoft.com/en-us/azure/architecture/patterns/retry
#Microservices
Docs
Retry pattern - Azure Architecture Center
Learn how to use the Retry pattern to enable an application to handle anticipated, temporary failures when the app tries to connect to a service or network resource.
Forwarded from SWE notes
Хороший обзор базовых retry патnернов, с примерами на питоне
#patterns #retry
https://engineering.mercari.com/en/blog/entry/20210126-retry-pattern-in-microservices/
#patterns #retry
https://engineering.mercari.com/en/blog/entry/20210126-retry-pattern-in-microservices/
Mercari
Retry pattern in microservices
If at first you don’t succeed, try, try again. Then quit. No use being a damn fool about it— W.C. FieldsHi,
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
📝 "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
GitHub
GitHub - robpike/lisp: Toy Lisp 1.5 interpreter
Toy Lisp 1.5 interpreter. Contribute to robpike/lisp development by creating an account on GitHub.
📝 "Сначала художник рисует плохо и просто. Потом сложно и плохо. Потом сложно и хорошо. И только потом - просто и хорошо."
- И.Е. Репин
#SoftwareDesign #SoftwareArchitecture
- И.Е. Репин
#SoftwareDesign #SoftwareArchitecture
👍1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
📝 "Сначала художник рисует плохо и просто. Потом сложно и плохо. Потом сложно и хорошо. И только потом - просто и хорошо." - И.Е. Репин #SoftwareDesign #SoftwareArchitecture
> "Сначала художник рисует плохо и просто. Потом сложно и плохо. Потом сложно и хорошо. И только потом - просто и хорошо." - И.Е. Репин
Второе предложение этого выссказывания, "потом сложно и плохо", демонстрирует собою "Синдром второй системы". Мы его уже вспоминали.
#SoftwareDesign #SoftwareArchitecture
Второе предложение этого выссказывания, "потом сложно и плохо", демонстрирует собою "Синдром второй системы". Мы его уже вспоминали.
#SoftwareDesign #SoftwareArchitecture
Wikipedia
Эффект второй системы
Эффект второй системы (также синдром второй системы) — тенденция того, что на смену маленьким, элегантным и успешным системам приходят раздутые системы с овер-инжинирингом, вследствие завышенных ожиданий и чрезмерной уверенности в необходимости изменений.
2_RBRU_Sparx_EA_MeetUp_171101_v08_1_t_me_it_ace_geronimus.pptx
4.3 MB
Архитектурный репозиторий - пример
Как организовать архитектурный репозиторий? Вот как устроено в Райффайзенбанк.
Видео доклада 👉 здесь
Дополнительно читатйте 👉 здесь
#кейс #архитектура #лучшее
via 📢@it_ace
💬 Комментировать
Как организовать архитектурный репозиторий? Вот как устроено в Райффайзенбанк.
Видео доклада 👉 здесь
Дополнительно читатйте 👉 здесь
#кейс #архитектура #лучшее
via 📢@it_ace
💬 Комментировать
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Знатный холиварчик титанов получился на тему FP vs OOP. Не без интересных исторических подробностей. https://twitter.com/Grady_Booch/status/1302678071049216000?s=19 #FunctionalProgramming #OOP
В последнее время часто обсуждается 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 являются известные письма 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
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
В последнее время часто обсуждается OOP в разных чатах. У меня на эту тему уже поднакопилось немного информации, которой можно поделиться. Для многих людей отправной точкой понимания OOP являются известные письма Alan Kay (стоит сразу отметить, что этот вопрос…
Начнем с определения 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
Скажу честно, самым ясным я считаю объяснение Н.Вирта, до которого мы скоро доберемся. Но объяснение от первоисточника является принципиально важным.
📝 "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
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Начнем с определения OOP и его целей от Kristen Nygaard, который считается соавтором (вместе с Ole Johan Dahl) OO-парадигмы, хотя и не автором OOP термина. Скажу честно, самым ясным я считаю объяснение Н.Вирта, до которого мы скоро доберемся. Но объяснение…
В предыдущем сообщении было рассмотрено мнение людей, которые считаются первооткрывателями 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
О том, что 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
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
В предыдущем сообщении было рассмотрено мнение людей, которые считаются первооткрывателями OO-парадигмы (если не учитывать https://wiki.c2.com/?SketchPad ). Теперь можно рассмотреть мнение человека, который считается автором OO-термина (если не учитывать …
Наверное, самое понятное объяснение природы 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 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
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Наверное, самое понятное объяснение природы OOP дает Niklaus Wirt: 📝 "ЧТО ТАКОЕ «ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ»? Глубинный смысл этой концепции с точки зрения автора заключается в децентрализованном управлении. Первым примером, наглядно поясняющим идею, может…
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
📝 "Как это ни печально, но в области компьютерных наук слишком уж господствуют модные поветрия. Появляясь, как правило, в период обострения проблем, они преподносятся как сильнодействующее средство для тяжелобольных и живут за счет надежд тех, кто находится в отчаянном положении. В программном обеспечении и в программировании вообще часто употребляется термин «кризис программного обеспечения», о котором впервые открыто заговорили в 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
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Niklaus Wirt о том, при каких обстоятельствах внедрялось OOP: 📝 "Как это ни печально, но в области компьютерных наук слишком уж господствуют модные поветрия. Появляясь, как правило, в период обострения проблем, они преподносятся как сильнодействующее средство…
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
📝 "Многие люди относятся к стилям и языкам программирования как к религиозным конфессиям: если вы принадлежите к одной из них, то не можете принадлежать к другой. Но это ложная аналогия, и она сознательно поддерживается по причинам коммерческого порядка. Объектно-ориентированное программирование вышло из принципов и понятий традиционного процедурного программирования. Скажу больше: в ООП не добавлено ни одного действительно нового понятия; просто по сравнению с процедурным оно делает значительно более сильный акцент на двух понятиях. Первое - это привязка процедуры к составной переменной, что и послужило оправданием для введения терминов "объект" и "метод". Средством для такой привязки является процедурная переменная (или поле записи - 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
Издательство «Открытые системы»
Никлаус Вирт о культуре разработки ПО
Никлаус Вирт (Niclaus Wirth) бесспорно является одним из наиболее известных и почитаемых мыслителей в мире информатики. Профессор ETH Institute в Цюрихе, Швейцария, он является автором новаторских языков и систем программирования Pascal, Modula 2 и Oberon.…
👍4🔥1
Forwarded from DDDevotion
Саша Поломодов (руководитель управления разработки цифровых экосистем в Тинькофф) много читает и делится впечатлениями от прочитанного.
В последнем посте вы найдете отличную подборку книг по архитектуре и дизайну ПО. Лично я прочитал чуть больше половины и это очень достойные книги – смело включайте в свои списки.
https://apolomodov.medium.com/software-design-books-743be52e4c71
В последнем посте вы найдете отличную подборку книг по архитектуре и дизайну ПО. Лично я прочитал чуть больше половины и это очень достойные книги – смело включайте в свои списки.
https://apolomodov.medium.com/software-design-books-743be52e4c71
Medium
Как прокачаться в проектировании программного обеспечения — список книг
В последнее время я часто провожу интервью по проектированию распределенных систем. И часто финальным шагом такого интервью я даю…