EMACSWAY_LOG Telegram 1403
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
До сего момента мы рассматривали управление Существенной Сложностью (Essential Complexity). Это наиболее существенное, хотя и не исчерпывающее, условие успешности разработки, потому что "Серебрянной пули нет". Существенная Сложность (Essential Complexity)…
Если есть изменяемое состояние, значит, систему можно привести в логически бессмысленное состояние. Чтобы этого избежать и сохранить систему в логически согласованном состоянии, эти изменения должны соответствовать инвариантам (бизнес-правилам).

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

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

А поскольку инварианты выражены методами, то чем меньше дистанция между изменяемым состоянием и этими методами, тем быстрее и легче можно их осмыслить. Это способ обойти ограничение краткосрочной памяти человека (Закон Миллера).

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

💬 encapsulation, the fact that one cannot see, much less design, the inner structure of the pieces.
—"The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr.


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

В Функциональной Парадигме нет изменяемого состояния, поэтому, нет необходимости в инкапсуляции.

Существует два способа управления сложностью:
1. Сократить дистанцию между изменяемым состоянием и его инвариантами (OOP).
2. Сократить саму изменяемость (FP).

💬 "OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts."
Michael Feathers


Под "moving parts" подразумевается изменяемое состояние, т.е. речь идет о конкретном виде инкапсуляции - сокрытии состяния и экспонировании поведения.

Как вы поняли, этот пост о про Anemic Domain Models, которые не используют ни функционального, ни объектно-ориентированного способа управления сложностью.

David Parnas в своем письме к Frederick P. Brooks писал:

💬 "Ответ прост. Это из-за привязанности ООП к сложным языкам. Вместо объяснения людям, что ООП является видом проектирования, и вооружения их принципами проектирования, их учили, что ООП — это использование определенного инструмента. Любыми срeдствами можно писать и плохие, и хорошие программы. Если не учить людей проектированию, то языки не имеют большого значения. Результатом будут плохие разработки с помощью этих языков и малая выгода. А если выгода невелика, то ООП не войдет в моду.

The answer is simple. It is because [O-O] has been tied to a variety of complex languages. Instead of teaching people that O-O is a type of design, and giving them design principles, people have taught that O-O is the use of a particular tool. We can write good or bad programs with any tool. Unless we teach people how to design, the languages matter very little. The result is that people do bad de-signs with these languages and get very little value from them. If the value is small, it won't catch on."
—"The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr.


Из этого письма следует, что ООП не приживается именно там, где не умеют проектировать, а значит, не умеют извлекать выгоду из проектирования.
🔥12👍3



tgoop.com/emacsway_log/1403
Create:
Last Update:

Если есть изменяемое состояние, значит, систему можно привести в логически бессмысленное состояние. Чтобы этого избежать и сохранить систему в логически согласованном состоянии, эти изменения должны соответствовать инвариантам (бизнес-правилам).

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

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

А поскольку инварианты выражены методами, то чем меньше дистанция между изменяемым состоянием и этими методами, тем быстрее и легче можно их осмыслить. Это способ обойти ограничение краткосрочной памяти человека (Закон Миллера).

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

💬 encapsulation, the fact that one cannot see, much less design, the inner structure of the pieces.
—"The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr.


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

В Функциональной Парадигме нет изменяемого состояния, поэтому, нет необходимости в инкапсуляции.

Существует два способа управления сложностью:
1. Сократить дистанцию между изменяемым состоянием и его инвариантами (OOP).
2. Сократить саму изменяемость (FP).

💬 "OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts."
Michael Feathers


Под "moving parts" подразумевается изменяемое состояние, т.е. речь идет о конкретном виде инкапсуляции - сокрытии состяния и экспонировании поведения.

Как вы поняли, этот пост о про Anemic Domain Models, которые не используют ни функционального, ни объектно-ориентированного способа управления сложностью.

David Parnas в своем письме к Frederick P. Brooks писал:

💬 "Ответ прост. Это из-за привязанности ООП к сложным языкам. Вместо объяснения людям, что ООП является видом проектирования, и вооружения их принципами проектирования, их учили, что ООП — это использование определенного инструмента. Любыми срeдствами можно писать и плохие, и хорошие программы. Если не учить людей проектированию, то языки не имеют большого значения. Результатом будут плохие разработки с помощью этих языков и малая выгода. А если выгода невелика, то ООП не войдет в моду.

The answer is simple. It is because [O-O] has been tied to a variety of complex languages. Instead of teaching people that O-O is a type of design, and giving them design principles, people have taught that O-O is the use of a particular tool. We can write good or bad programs with any tool. Unless we teach people how to design, the languages matter very little. The result is that people do bad de-signs with these languages and get very little value from them. If the value is small, it won't catch on."
—"The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr.


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

BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.


Share with your friend now:
tgoop.com/emacsway_log/1403

View MORE
Open in Telegram


Telegram News

Date: |

Ng Man-ho, a 27-year-old computer technician, was convicted last month of seven counts of incitement charges after he made use of the 100,000-member Chinese-language channel that he runs and manages to post "seditious messages," which had been shut down since August 2020. The public channel had more than 109,000 subscribers, Judge Hui said. Ng had the power to remove or amend the messages in the channel, but he “allowed them to exist.” Over 33,000 people sent out over 1,000 doxxing messages in the group. Although the administrators tried to delete all of the messages, the posting speed was far too much for them to keep up. The best encrypted messaging apps To edit your name or bio, click the Menu icon and select “Manage Channel.”
from us


Telegram emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
FROM American