Я Путь к чистой архитектуре (Clean Architecture) Технический рецензент китайской версии имеет небольшое представление о процессе рецензирования, поэтому я надеюсь поделиться им с вами, написав руководство.
происхождение названия
Путь к чистой архитектуреClean ArchitectureКитайский перевод . Вроде простое продолжение "Пути чистого кода" (Clean Code) традиция перевода, но на самом деле мы все же приложили немало усилий, чтобы выбрать китайские имена. При получении первого черновика перевода редактор предоставил несколько альтернативных названий перевода: «Путь лаконичной архитектуры», «Архитектура к чистоте» и «Чистая архитектура», в этих названиях есть свои соображения, не понимая сути этой книги. Прежде чем думать, у меня нет возможности сделать правильное суждение. Поэтому после прочтения оригинальной работы и перевода я инициировал предложение в консультационной группе ThoughtWorks. Процесс обсуждения был очень увлекательным. В конце концов, по совету хардкорного архитектора Шинга, результат, как правило, был чистым. структура.
Новый брат сказал: «Вся книга говорит о управлении зависимостями (управлении), то есть, если сложность зависимостей снижается, это согласуется с идеей разделения иерархической архитектуры поддоменов в DDD; так же, как вы организуйте свою комнату и разложите вещи по категориям. Что ж, с этой точки зрения аккуратность более уместна, чем простота, или ясность — это хорошо».
Кроме того, для кандидата «Архитектура чиста» отношение большого дьявола не должно быть чистым, оно всегда кажется грязным. Другими словами, испытайте это на себе. Однако Юэ Юэ и XR, которые являются студентами MBA (XR сказал, что никогда не читал MBA), исходят из мышления пользователя и считают, что «Путь чистого кода» и «Путь чистой архитектуры» могут улучшить память друг друга и легче стимулировать покупательское поведение пользователей.
Даже доработана «чистая архитектура», «все« дорога », чтобы иметь разные взгляды. «Код аккуратно», соответствующий первоначальному названию и субтитруClean Code - A handbook of Agile Software Craftsmanship, а соответствующее оригинальное название и подзаголовок «Путь чистой архитектуры»Clean Architecture - A Craftsman's Guide to Software Structure and Design. Мы знаем, что «Дао» — это метафизический духовный уровень, и, честно говоря,Craftsman(Ремесленник) переводится как «Дао» немного преувеличено.
Метафизика есть макрокатегория духовности, и используется абстрактное (рациональное) мышление.Метафизика означает принципы, которые исходят из учения, ведут в принципы и кончаются в Дао.Поэтому существуют метафизические, называемые Дао; объекты, погруженные в форму, возникшие в результате обучения, практики в Дхарме и завершенные в искусстве, поэтому те, что имеют форму и подповерхность, называются инструментами.
Дао волшебное оружие, чтобы выбрать один? На самом деле во всем всегда есть баланс, и часто неплохо следовать методу перевода предшественников. Точно так же, как принцип стабильной зависимости, изложенный в книге дяди Боба, чем больше раз мы полагаемся на метод перевода, тем стабильнее он будет.Такая стабильность не скажет, может ли она сформировать эффект бренда, но только SEO может спасти много денег.Кунг-фу, так почему бы не сделать это?
Текст дяди Боба прост и легко понять, и он особенно любит использовать свой собственный жизненный опыт в качестве примера. И в этой книге нет разрыва знаний. Даже младшие программисты могут завершить трансформацию их понимания архитектуры программного обеспечения под руководством дяди Боб. Поскольку он всегда вырезает из самых базовых точек знаний, снизу вверх, создает форму шага на шаге.
Сущность парадигмы - это ограничение
Парадигмы программирования — излюбленная тема программистов, как и затянувшаяся битва между редакторами Vim и Emacs. Их взлеты и падения в прошлом кажутся бурными реками и озерами. Герой структурного программирования постепенно исчезал из поля зрения программиста, вожделенное объектно-ориентированное программирование (ООП) с громом доминировало над боевыми искусствами, а жившее в одиночестве много лет функциональное программирование (ФП) наконец-то дождалось удобного случая. С 2012 по 2014 годы бесконечны голоса рек и озер, поющие об ООП.ФП подобен рыцарскому человеку, спасающему программистов от воды и огня, пытающихся потрясти мир. После порохового дыма это не трагическая ситуация твоей смерти и моей смерти, а счастливый конец, в котором у тебя есть я, а у меня есть ты. Когда Java, консервативная партия ООП, интегрировала характерные лямбда-выражения ФП, конфликт парадигм подошел к концу.
Программисты говорят о парадигмах программирования и любят бороться с различиями, и я, как фанат ФП, не исключение. Но дядя Боб лаконично сказал, что так называемая парадигма программирования есть не что иное, как ограничение выполнения программы и указание нам того, чего мы не можем делать.
- Структурированное программирование — это спецификация и ограничение прямой передачи управления программой
- Объектно-ориентированное программирование — это спецификация и ограничение косвенной передачи управления программой.
- Функциональное программирование — это спецификация и ограничение операций присваивания в программах.
Goto considered harmful
Изучайте язык программирования C в первый день, учитель сказал нам не использовать в программеgotoЗаявление, потому чтоgotoЭто разрушит структуру программы. Тезис ДейкстрыGo To Statement Considered Harmfulдоказано вgotoоператор предотвращает рекурсивную декомпозицию больших программ на более мелкие доказуемые единицы, что означает интенсивное использованиеgotoПрограмма утверждения не может быть доказана. Здесь семантика недоказуемого неразрешима, аналогична парадоксу лжеца — предложение «я лгу» не может быть доказано и фальсифицировано, поэтому нет необходимостиgotoНа самом деле это делается для того, чтобы малые программные единицы были разрешимы. Жаль, что Дийкстра не доказал программные единицы и эту работу заменил научный метод - тестирование. Тестирование — это научный метод, который можно опровергнуть при условии, что программная единица разрешима. Утверждение "Вороны в мире черны как черные" может быть фальсифицировано. Мы не можем перечислить всех ворон в мире. Когда мы находим белую ворону, мы можем сказать, что это суждение неверно. Это фальсификация. Дейкстра сказал: «Тестирование может показать только то, что ошибка существует, а не то, что ее не существует».
Тестирование может гарантировать, что программный модуль корректен в известных на данный момент обстоятельствах. Как только новый тестовый пример вызывает сбой программного модуля, мы можем исправить программу и приблизить ее к истине. Возможно, в этом прелесть TDD (разработка через тестирование).
удаленныйgotoПосле заявления мы обнаружили, что процесс вычисления с возможностью судить о последовательности, петле и ответвлении по-прежнему завершен по Тьюрингу, то естьgotoЕго наличие или отсутствие не влияет на вычислительную мощность. ТакgotoРоль программы в программе - больше вреда, чем пользы. ПлюсgotoЗлоупотребление им приведет к тому, что структура программы будет легко запутаться, что не способствует пониманию программистов, чего следует избегать, насколько это возможно. Таким образом, структурированное программирование ограничивает прямую передачу управления программой.
Pointer considered harmful
Всем известно, что объектно-ориентированное программирование имеет три характеристики: инкапсуляция, наследование и полиморфизм.
Инкапсуляция заключается в построении абстрактного барьера (Abstract Barrier) для достижения цели сокрытия информации. В любой парадигме программирования нет недостатка в инкапсуляции, потому что это то, чего хотят люди и как они упрощают познание проблем.
Наследование — это способ повторного использования функций (процедур или API-интерфейсов). Раньше мы хотели использовать одну и ту же функцию для нескольких данных с похожей структурой, и нам нужно было привести их к типу данных (указателю структуры), который может получить функция. обязательно будут риски. В объектно-ориентированном мире нам больше не нужно выполнять приведение типов вручную, языки программирования могут делать это автоматически во время выполнения, просто явно указав наследование.
ПолиморфизмВозможность связать различные специальные модели поведения с одним токеном обобщения., и эталонная реализация, соответствующая концепции полиморфизма — решение о том, какой фрагмент кода запускать, называется диспетчеризацией.Большинство диспетчеризации основано на типе, а также может быть основано на количестве и типе параметров метода.Конкретное выполнение процесс отправки опирается на указатели функций. Когда функция объявляется как один маркер обобщения, ее конкретная реализация может различаться. Посредством такой нотации, по сути, мы развязываем объявление и реализацию, и процесс этого разъединения как раз и осуществляется косвенным нахождением целевой функции через указатель на функцию. Таким образом, объектно-ориентированное программирование ограничивает косвенную передачу контроля над программой.
Mutability considered harmful
Нил Форд в «Мысли о функциональном программировании» (Functional Thinking) упомянул, что объектно-ориентированное программирование контролирует сложность, инкапсулируя переменные (делает код понятным), в то время как функциональное программирование контролирует сложность, исключая переменные. Примечательной особенностью функционального стиля является неизменность. Неизменяемость означает большее потребление памяти, худшую производительность? Не совсем. Языки функционального программирования на основе JVM, такие как Scala и Clojure, широко используют постоянные структуры (такие как Persistent Vector, см. сноску 1) для реализации неизменяемых структур данных без потери эффективности. Такие структуры данных имеют огромные преимущества в средах с высокой степенью параллелизма, особенно по сравнению с критическими разделами и условиями гонки, которые критикуются в объектно-ориентированном программировании.
Неизменяемые структуры данных не могут назначаться повторно, поэтому функциональное программирование ограничивает назначение программ.
резюме
Дядя Боб многозначительно указал, что то, чему мы научились за последние 50 лет, в основном...что не делать. Это задает тон всей книге. По аналогии, хорошая архитектура передает то же самое сообщение.
Зачем начинать с парадигмы программирования? Просмотрев всю книгу, я постепенно обнаружил, что дядя Боб на самом деле передает философию дизайна: в архитектурном проектировании нисходящий дизайн часто ненадежен. Как и в оглавлении в этой книге, от основных строительных блоков программы к компонентам и, наконец, к архитектуре, этот процесс во многом соответствует характеристикам самоорганизации системы.
Почему проектирование сверху вниз часто бывает ненадежным? В части 4 этой книги «Принципы построения компонентов» будут ответы, если это необходимо, и выслушаем следующую разбивку.