tgoop.com/emacsway_log/1403
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