Привет!
Я пошёл дописывать пост по диаграмме эффектов, думаю это займёт ещё недели две, так что пока перехожу в режим линко постинга.
И сегодня будет ещё пара линок о том, что микросервисы не должны быть выбором по умолчанию.
Микро правило распределённого проектирования Фаулера: My First Law of Distributed Object Design: Don't distribute your objects.
Пост DHH на ту же тему.
Для того чтобы идти взону боли и страданий распределённое программирование нужны веские причины.
#posts@ergonomic_code #why_no_microservices@ergonomic_code
Я пошёл дописывать пост по диаграмме эффектов, думаю это займёт ещё недели две, так что пока перехожу в режим линко постинга.
И сегодня будет ещё пара линок о том, что микросервисы не должны быть выбором по умолчанию.
Микро правило распределённого проектирования Фаулера: My First Law of Distributed Object Design: Don't distribute your objects.
Пост DHH на ту же тему.
Для того чтобы идти в
#posts@ergonomic_code #why_no_microservices@ergonomic_code
martinfowler.com
bliki: First Law
a bliki entry for First Law
Привет!
Пост с наикрутейшей подборкой принципов и техник написания хороших тестов. Представитель вида постов занесённых в красную книгу - посты которые я целиком рекомендую безо всяких но и оговорок:)
#posts@ergonomic_code #ergo_testing@ergonomic_code
Пост с наикрутейшей подборкой принципов и техник написания хороших тестов. Представитель вида постов занесённых в красную книгу - посты которые я целиком рекомендую безо всяких но и оговорок:)
#posts@ergonomic_code #ergo_testing@ergonomic_code
Philipp Hauer's Blog
Modern Best Practices for Testing in Java
Modern best practices for unit tests and integration tests in Java and in general
👍2
Привет!
Увидев единомышленника в авторе поста о модульном программировании на спринге решил прочитать и его книгу о Чистой архитектуре. С робкой надеждой найти там методику декомпозиции системы на модули.
Но мои надежды не оправдались - как и во всех других книгах эта тема осталась не раскрытой. Всю книгу автор рассматривал структуру реализации одного, спущенного свыше модуля - account. Откуда он взялся, как связан с другими модулями, какой у него интерфейс - это всё осталось за кадром.
На мой взгляд, именно проектирование модулей является самой сложной и самой важной частью создания эргономичных программ (пост о том, как это делаю я - читайте в мае на всех экранах страны). А уш как реализовать эти модули - в эргономичном стиле, по чистой архитектуре или божественным объектом - это детали реализации.
Вообще в книге есть здравые мысли касательно сокрытия реализации модулей - это стоит почитать. Там есть подробная инструкция как нагенерять гору абстракций и бойлерплейта по чистой архитектуре - это можно почитать, если задача требует жёсткой изоляции домена. И есть глава которую лучше пропустить целиком - 7. Testing Architecture Elements. В этой главе собрана подборка рецептов, как попасть в ад - пирамида тестирования, тестирование отдельных классов, активное использование моков.
Вердикт - рекомендую, при условии, что вы понимаете зачем вам нужна Чистая архитектура и это не карго культ. С другой стороны, если в это понимаете, то и книга вряд ли будет содержать что-то новое для вас.
#books@ergonomic_code
Увидев единомышленника в авторе поста о модульном программировании на спринге решил прочитать и его книгу о Чистой архитектуре. С робкой надеждой найти там методику декомпозиции системы на модули.
Но мои надежды не оправдались - как и во всех других книгах эта тема осталась не раскрытой. Всю книгу автор рассматривал структуру реализации одного, спущенного свыше модуля - account. Откуда он взялся, как связан с другими модулями, какой у него интерфейс - это всё осталось за кадром.
На мой взгляд, именно проектирование модулей является самой сложной и самой важной частью создания эргономичных программ (пост о том, как это делаю я - читайте в мае на всех экранах страны). А уш как реализовать эти модули - в эргономичном стиле, по чистой архитектуре или божественным объектом - это детали реализации.
Вообще в книге есть здравые мысли касательно сокрытия реализации модулей - это стоит почитать. Там есть подробная инструкция как нагенерять гору абстракций и бойлерплейта по чистой архитектуре - это можно почитать, если задача требует жёсткой изоляции домена. И есть глава которую лучше пропустить целиком - 7. Testing Architecture Elements. В этой главе собрана подборка рецептов, как попасть в ад - пирамида тестирования, тестирование отдельных классов, активное использование моков.
Вердикт - рекомендую, при условии, что вы понимаете зачем вам нужна Чистая архитектура и это не карго культ. С другой стороны, если в это понимаете, то и книга вряд ли будет содержать что-то новое для вас.
#books@ergonomic_code
reflectoring.io
Structuring and Testing Modules and Layers with Spring Boot
Slice your Spring Boot applications into vertical modules and make them testable in isolation using Spring Boot's testing features.
👍4
Привет!
Прочитал одну из самых крутых книг по разработке информационных систем в своей жизни - Unit Testing Principles, Practices, and Patterns.
Не дайте ввести себя в заблуждение скромному названию - эта книга представляет собой кладезь мудрости и принципов программирования и проектирования в целом. Плюс в ней представлено лучшее из известных мне на данный момент описание прагматичной (без монад) функциональной архитектуры.
В некоторых деталях я с автором не согласен, но в целом эта книга чуть менее, чем полностью раскрывает два из трёх столпов Эргономичного подхода - тестирование на соответствие требованиям и декларативный стиль.
Вердикт - маст рид вне очереди.
Апдейт статуса поста по диаграмме эффектов - первый драфт с подробным описанием примера построения готов. Но предстоит ещё как минимум несколько итераций ревью и вычитки, плюс у меня буквально сегодня ночью появились идеи изменения нотации, поэтому релиз будет недели через две минимум. Стей тюнед, вобщем:)
#books@ergonomic_code #ergo_testing@ergonomic_code #functional_architecture@ergonomic_code
Прочитал одну из самых крутых книг по разработке информационных систем в своей жизни - Unit Testing Principles, Practices, and Patterns.
Не дайте ввести себя в заблуждение скромному названию - эта книга представляет собой кладезь мудрости и принципов программирования и проектирования в целом. Плюс в ней представлено лучшее из известных мне на данный момент описание прагматичной (без монад) функциональной архитектуры.
В некоторых деталях я с автором не согласен, но в целом эта книга чуть менее, чем полностью раскрывает два из трёх столпов Эргономичного подхода - тестирование на соответствие требованиям и декларативный стиль.
Вердикт - маст рид вне очереди.
Апдейт статуса поста по диаграмме эффектов - первый драфт с подробным описанием примера построения готов. Но предстоит ещё как минимум несколько итераций ревью и вычитки, плюс у меня буквально сегодня ночью появились идеи изменения нотации, поэтому релиз будет недели через две минимум. Стей тюнед, вобщем:)
#books@ergonomic_code #ergo_testing@ergonomic_code #functional_architecture@ergonomic_code
👍7
Привет!
Тестирование свойств мне кажется очень крутой техникой, за освоение которой я сам ещё толком не брался.
Но при случае читаю посты посвящённые ей и сегодня наткнулся на хороший пост, который раскрывает ход мысли при написании тестов свойств - рекомендую почитать:)
#posts@ergonomic_code #ergo_testing@ergonomic_code
Тестирование свойств мне кажется очень крутой техникой, за освоение которой я сам ещё толком не брался.
Но при случае читаю посты посвящённые ей и сегодня наткнулся на хороший пост, который раскрывает ход мысли при написании тестов свойств - рекомендую почитать:)
#posts@ergonomic_code #ergo_testing@ergonomic_code
Fsharpforfunandprofit
The Enterprise Developer from Hell
Outwitting malicious compliance with property-based testing
Привет!
Во-первых, с радостью обращаю ваше внимание, что наc стало 150:)
Во-вторых, написал микропост о том, как фичи и идиомы Kotlin способствует локализации рассуждений о коде
В-третьих, апдейт статуса макропоста о диаграмме эффектов: я его перелопатил чуть более чем полностью. Для диаграммы ввёл две нотации - краткую и полную и сделал её совместимой с моделью С4. А сам пост разбил на два - спецификация и пример построения.
Процесс вроде начал сходиться, есть шанс, что сойдётся на следующей недели
#kotlin@ergonomic_code
Во-первых, с радостью обращаю ваше внимание, что наc стало 150:)
Во-вторых, написал микропост о том, как фичи и идиомы Kotlin способствует локализации рассуждений о коде
В-третьих, апдейт статуса макропоста о диаграмме эффектов: я его перелопатил чуть более чем полностью. Для диаграммы ввёл две нотации - краткую и полную и сделал её совместимой с моделью С4. А сам пост разбил на два - спецификация и пример построения.
Процесс вроде начал сходиться, есть шанс, что сойдётся на следующей недели
#kotlin@ergonomic_code
Telegraph
Kotlin и локальность рассуждений
Этот пост написан по мотивам другого поста о том, как F# способствует локальности рассуждений (reasoning locality). Код обладает свойством локальности рассуждений тогда, когда его можно понять только глядя на целевой код. И код написанный в императивном стиле…
👍2
image_2022-05-13_18-16-19.png
13.9 KB
Привет!
Ну скажите же, эта структура намного понятнее, чем свалки из controllers, services и т.д.
Возвращаюсь спустя полгода к проекту, сделанному по ЭП и нарадоваться не могу.
#case@ergonomic_code #why_ergo_approach@ergonomic_code #ergo_approach@ergonomic_code
Ну скажите же, эта структура намного понятнее, чем свалки из controllers, services и т.д.
Возвращаюсь спустя полгода к проекту, сделанному по ЭП и нарадоваться не могу.
#case@ergonomic_code #why_ergo_approach@ergonomic_code #ergo_approach@ergonomic_code
👍1
Привет!
У меня есть мечта. Я хочу, чтобы данные и код моих программ располагались на одной машине, лучше - в одном процессе. Когда я закончу Эргономичный подход, я вернусь к созданию технологии, которая позволит это сделать. Если кто-то другой не сделает её раньше:)
#tools@ergonomic_code #ergo_persistance@ergonomic_code #ergo_approach@ergonomic_code
У меня есть мечта. Я хочу, чтобы данные и код моих программ располагались на одной машине, лучше - в одном процессе. Когда я закончу Эргономичный подход, я вернусь к созданию технологии, которая позволит это сделать. Если кто-то другой не сделает её раньше:)
#tools@ergonomic_code #ergo_persistance@ergonomic_code #ergo_approach@ergonomic_code
🔥2
Привет!
С радостью представляю вам спецификацию диаграммы эффектов v0.0.2:)
#effects_diagram@ergonomic_code #posts@ergonomic_code
С радостью представляю вам спецификацию диаграммы эффектов v0.0.2:)
#effects_diagram@ergonomic_code #posts@ergonomic_code
Алексей Жидков
Диаграмма Эффектов: Спецификация v0.0.2 - Алексей Жидков
Душой информационной системы являются её эффекты. Именно на основании эффектов конечные пользователи выносят суждения о корректности работы системы. И при столь большой важности эффектов, в мире не существовало инструмента для их визуализации и проектирования.…
🔥3💩1
Привет!
Прекрасное подтверждение для тезиса "Сначала объектно-ориентированная декомпозиция, потом модульный монолит на этой базе, потом, если потребуется, микросервисы".
О том как использовать диаграмму эффектов для рациональной объектно-ориентированной декомпозиции я напишу третьим постом в текущей серии о диаграмме эффектов.
#posts@ergonomic_code #why_no_microservices@ergonomic_code
Прекрасное подтверждение для тезиса "Сначала объектно-ориентированная декомпозиция, потом модульный монолит на этой базе, потом, если потребуется, микросервисы".
О том как использовать диаграмму эффектов для рациональной объектно-ориентированной декомпозиции я напишу третьим постом в текущей серии о диаграмме эффектов.
#posts@ergonomic_code #why_no_microservices@ergonomic_code
Хабр
От микросервисов к монолиту — маршрут построен
Привет, Хабр! Меня зовут Артём Шубский, я техлид в компании AGIMA. Заметили, что на Хабре и на конференциях часто рассказывают, как перешли с монолита на микросервисы. Мы тоже всем сердцем любим...
👍7
Привет!
Пост с примером построения диаграммы эффектов реального проекта перешёл в стадию полировки, думаю есть шанс опубликовать его на следующей недели.
А чтобы вы пока не скучали я накатал микропост, о том что "Program to an interface, not an implementation" - это не про ключевое слово.
Пост с примером построения диаграммы эффектов реального проекта перешёл в стадию полировки, думаю есть шанс опубликовать его на следующей недели.
А чтобы вы пока не скучали я накатал микропост, о том что "Program to an interface, not an implementation" - это не про ключевое слово.
Telegraph
Абстрактные войны: public interface против абстракции
Почти 30 лет назад в классической книжке по шаблонам проектирования (Design Patterns: Elements of Reusable Object-Oriented Software), авторы сформулировали один из самых известных, но недопонятых принципов в истории программирования:
Пульнул пост о диаграмме эффектов на хабр - как обычно, буду благодарен за лайки, комментарии и репосты:)
Хабр
Диаграмма эффектов: спецификация v0.0.2
Следить за обновлениями блога можно в моём канале: Эргономичный код Этот пост является первой попыткой описать диаграмму формально, поэтому в описании возможны неточности и пробелы, а детали и нотация...
👍5
abstactions.png
140.2 KB
Привет!
Разбираю сейчас легаси проект на .Net и подвернулась хорошая иллюстрация из реальной жизни предпредыдущего поста про абстракции.
Я вообще пока не понимаю был ли смысл оборачивать Context в UnitOfWork, но вводить IUnitOfWork вообще никакого смысла не было - из него утекают типы реализации.
Я бы ещё хоть как-то понял интерфейс, если бы у них были тесты на моках. Но даже их нет.
Заодно апдейт по статусу поста о построении диаграммы эффектов - он близится к релизу. Планирую в течении ближайшей недели опубликовать.
А потом, похоже, вырисовывается ещё пара нетривиальных спинофов - про сцепленность и объектные/объектно-ориентированные дизайн и программирование.
#project_e@ergonomic_code #design@ergonomic_code
Разбираю сейчас легаси проект на .Net и подвернулась хорошая иллюстрация из реальной жизни предпредыдущего поста про абстракции.
Я вообще пока не понимаю был ли смысл оборачивать Context в UnitOfWork, но вводить IUnitOfWork вообще никакого смысла не было - из него утекают типы реализации.
Я бы ещё хоть как-то понял интерфейс, если бы у них были тесты на моках. Но даже их нет.
Заодно апдейт по статусу поста о построении диаграммы эффектов - он близится к релизу. Планирую в течении ближайшей недели опубликовать.
А потом, похоже, вырисовывается ещё пара нетривиальных спинофов - про сцепленность и объектные/объектно-ориентированные дизайн и программирование.
#project_e@ergonomic_code #design@ergonomic_code
Привет!
Наконец-то мир начал отходить от массового помешательства
https://habr.com/ru/company/jugru/blog/670816/
#talks@ergonomic_code #why_no_microservices@ergonomic_code
Наконец-то мир начал отходить от массового помешательства
https://habr.com/ru/company/jugru/blog/670816/
#talks@ergonomic_code #why_no_microservices@ergonomic_code
Хабр
Обзор программы DotNext 2022 Spring: сольем микросервисы в монолит, приручим хаос и узрим многоликий DDD
В этот раз у DotNext непривычный формат: сначала два дня в онлайне, а позже офлайн-день в Петербурге (первая за два года возможность встретиться на DotNext очно!) Для тех, кто не может добраться до...
Привет!
Надоело мне мурыжить пост о построении диаграммы реального проекта, поэтому я волевым усилием его быстренько добил и с радостью представляю вашему вниманию:)
А дальше в серии будет два спиноффа - "Сцепленность" и "Объектный дизайн, как средство снижения сцепленности". Обе концепции у меня самого ещё не до конца разложены по полочкам, поэтому не берусь спрогнозировать сколько мне времени мне потребуется на эти посты.
После чего я смогу вернуться к третьему посту серии о применении диаграммы эффектов для объектной декомпозиции системы на модули. Но боюсь как бы это не осенью было.
#effects_diagram@ergonomic_code #case@ergonomic_code #project_geoservices@ergonomic_code #posts@ergonomic_code
Надоело мне мурыжить пост о построении диаграммы реального проекта, поэтому я волевым усилием его быстренько добил и с радостью представляю вашему вниманию:)
А дальше в серии будет два спиноффа - "Сцепленность" и "Объектный дизайн, как средство снижения сцепленности". Обе концепции у меня самого ещё не до конца разложены по полочкам, поэтому не берусь спрогнозировать сколько мне времени мне потребуется на эти посты.
После чего я смогу вернуться к третьему посту серии о применении диаграммы эффектов для объектной декомпозиции системы на модули. Но боюсь как бы это не осенью было.
#effects_diagram@ergonomic_code #case@ergonomic_code #project_geoservices@ergonomic_code #posts@ergonomic_code
Алексей Жидков
Диаграмма эффектов: пример построения - Алексей Жидков
Этот пост ялвяется второй частью из серии постов о диаграмме эффектов, в котором я рассмотрю пример построения диаграммы эффектов реального проекта
❤2
Привет!
Пульнул на хабр пост о построении диаграммы эффектов
Как всегда буду благодарен за лайки, карму, комменты и репосты:)
Пульнул на хабр пост о построении диаграммы эффектов
Как всегда буду благодарен за лайки, карму, комменты и репосты:)
Хабр
Диаграмма эффектов: пример построения
Следить за обновлениями блога можно в моём канале: Эргономичный код Это второй пост в серии, посвящённый диаграмме эффектов: "Спецификация" - назначение диаграммы, основные концептуальные элементы и...
❤2
Привет!
С третьей попытки откопал статью, которую на вики указывают как первое описание сцепленности и связности. Там можно бесплатно зарегаться и бесплатно бесконечное кол-во раз арендовать книгу целиком на час.
Пост который я сейчас пишу - это по сути краткий пересказ перевода идей, изложенных в этой статье и книге Structured Design, плюс небольшая модернизация под современные языки программирования.
Тем не менее, советую ознакомиться с первоисточником:)
#papers@ergonomic_code #structured_design@ergonomic_code
С третьей попытки откопал статью, которую на вики указывают как первое описание сцепленности и связности. Там можно бесплатно зарегаться и бесплатно бесконечное кол-во раз арендовать книгу целиком на час.
Пост который я сейчас пишу - это по сути краткий пересказ перевода идей, изложенных в этой статье и книге Structured Design, плюс небольшая модернизация под современные языки программирования.
Тем не менее, советую ознакомиться с первоисточником:)
#papers@ergonomic_code #structured_design@ergonomic_code
Привет!
К вопросу о чтении переведённых книг.
Занесла меня тут нелёгкая снова в "Чистую архитектуру". В оригинале там есть такой текст:
The issues we have discussed so far lead to an inescapable conclusion: The component structure cannot be designed from the top down. It is not one of the first things about the system that is designed, but rather evolves as the system grows andchanges.
Я его перевожу следующим образом:
Проблемы, которые мы только что обсудили ведут нас к неизбежному выводу - структура компонент не может быть спроектирована сверху вниз. Она не является одной из первых проектируемых штук о системе, а скорее формируется по мере роста и изменения системы.
И даже яндекс-переводчик переводит примерно так же.
А потом ещё более нелёгкая занесла мена почитать этот же кусочек в русской версии. Там написано следующее:
Проблемы, что мы обсудили к данному моменту, ведут к однозначному заключению: структура компонентов не может проектироваться сверху вниз. К этому выводу приходят не сразу, как только начинают проектировать систему, но это неизбежно случается с ростом и изменением системы.
К этому выводу приходят не сразу, как только начинают проектировать
Что? Откуда это вообще??? Во втором предложении вообще нет слов "вывод" и "приходить". Куда делось слово evolves? И кто приходит к этому выводу?
Тут фатально искажена суть - я русскую версию читаю как то, что разработчики приходят к выводу о том, что "структура компонентов не может проектироваться сверху вниз" не сразу, как только начинают проектировать систему, а по мере роста и изменения системы.
Судя по этому отрывку, переводчик плохо знает грамматику английского языка. Либо вообще, книгу перевели в Prompt-е из 90 (потому что современные переводчики лучше справляются с этой работй), а потом редактор-гуманитарий её причесал как смог.
В общем не читайте переведённые книги по программированию - совершенно непонятно чему они научат.
К вопросу о чтении переведённых книг.
Занесла меня тут нелёгкая снова в "Чистую архитектуру". В оригинале там есть такой текст:
The issues we have discussed so far lead to an inescapable conclusion: The component structure cannot be designed from the top down. It is not one of the first things about the system that is designed, but rather evolves as the system grows andchanges.
Я его перевожу следующим образом:
Проблемы, которые мы только что обсудили ведут нас к неизбежному выводу - структура компонент не может быть спроектирована сверху вниз. Она не является одной из первых проектируемых штук о системе, а скорее формируется по мере роста и изменения системы.
И даже яндекс-переводчик переводит примерно так же.
А потом ещё более нелёгкая занесла мена почитать этот же кусочек в русской версии. Там написано следующее:
Проблемы, что мы обсудили к данному моменту, ведут к однозначному заключению: структура компонентов не может проектироваться сверху вниз. К этому выводу приходят не сразу, как только начинают проектировать систему, но это неизбежно случается с ростом и изменением системы.
К этому выводу приходят не сразу, как только начинают проектировать
Что? Откуда это вообще??? Во втором предложении вообще нет слов "вывод" и "приходить". Куда делось слово evolves? И кто приходит к этому выводу?
Тут фатально искажена суть - я русскую версию читаю как то, что разработчики приходят к выводу о том, что "структура компонентов не может проектироваться сверху вниз" не сразу, как только начинают проектировать систему, а по мере роста и изменения системы.
Судя по этому отрывку, переводчик плохо знает грамматику английского языка. Либо вообще, книгу перевели в Prompt-е из 90 (потому что современные переводчики лучше справляются с этой работй), а потом редактор-гуманитарий её причесал как смог.
В общем не читайте переведённые книги по программированию - совершенно непонятно чему они научат.
👍4
Привет!
У меня тут мега инсайт. Я лет 8 назад разочаровался в ООП и с тех пор говорил, что это облажавшая хрень, которая, на самом деле не захватила мир и миром всё ещё правит ПП.
При этом я верю в ООД. Когда-нибудь я напишу пост, в чём для меня разница, но если вкратце, для меня ООП - это классы, а ООД - подсистемы
Поэтому я время от времени читаю книги по ООП/ООД и сейчас читаю Designing object-oriented software.
Я там сразу обратил внимание на примеры - банкомат и редактор документов.
Тут у меня появилась идея, что может ООП не в целом облажалось, а просто (внезапно) не является серебренной пулей и не стрельнуло в моей отрасли разработки ПО - информационных системах? Пошёл смотреть другие примеры.
Applying UML and Patterns - автоматизация кассы
Object Oriented Software Construction - система резирвации авиа билетов с фокусом на UI, undo в интерактивной систему
Object-Oriented Software Engineering: A Use Case Driven Approach - система управления складом с фокусом на UI, телеком
Object Design: Roles, Responsibilities, and Collaborations - система общения парализованных людей, по средствам моргания глазами
Object-Oriented Analysis and Design with Applications - спутниковая навигация, система управления трафиком, криптоанализ, наблюдение за погодой, система управления отпусками (вот кажись единственный похожий пример)
Working with objects: The OOram Software Engineering Method - "business information system" но на беглый взгляд, фокус всё равно на UI, система реального времени, фреймворк
The Object-Oriented Thought Process - игра в 21
Head First Object-Oriented Analysis and Design - информационная система магазина гитар, но на списках:(
Львиная доля примеров - сильно отличаются от того, с чем работаю я. Там либо высокоинтерактивная система, либо активная работа с оборудованием, либо UI.
Так что, наверное, для ООП есть место в мире, просто не моём:)
А для разработки информационных систем я советую:
1) следовать ООД при декомпозиции системы на подсистемы - каждая подсистема должна инкапсулировать в себе какую-то часть состояния всей системы, и предоставлять публичное АПИ для его изменения
2) следовать функциональной архитектуре в реализации отдельных подсистем - разбивать код на чистое ядро с бизнес-правилами, и императивную оболочку с вводом- выводом
3) максимум кода тащить в чистое ядро и делать это ядро понастоящему чистым - с неизменяемыми структурами данных и функциями без эффектов
4) а императивную оболочку делать максимально тонкой, прямолинейной и простой
#oop@ergonomic_code #books@ergonomic_code #ergo_approach@ergonomic_code
У меня тут мега инсайт. Я лет 8 назад разочаровался в ООП и с тех пор говорил, что это облажавшая хрень, которая, на самом деле не захватила мир и миром всё ещё правит ПП.
При этом я верю в ООД. Когда-нибудь я напишу пост, в чём для меня разница, но если вкратце, для меня ООП - это классы, а ООД - подсистемы
Поэтому я время от времени читаю книги по ООП/ООД и сейчас читаю Designing object-oriented software.
Я там сразу обратил внимание на примеры - банкомат и редактор документов.
Тут у меня появилась идея, что может ООП не в целом облажалось, а просто (внезапно) не является серебренной пулей и не стрельнуло в моей отрасли разработки ПО - информационных системах? Пошёл смотреть другие примеры.
Applying UML and Patterns - автоматизация кассы
Object Oriented Software Construction - система резирвации авиа билетов с фокусом на UI, undo в интерактивной систему
Object-Oriented Software Engineering: A Use Case Driven Approach - система управления складом с фокусом на UI, телеком
Object Design: Roles, Responsibilities, and Collaborations - система общения парализованных людей, по средствам моргания глазами
Object-Oriented Analysis and Design with Applications - спутниковая навигация, система управления трафиком, криптоанализ, наблюдение за погодой, система управления отпусками (вот кажись единственный похожий пример)
Working with objects: The OOram Software Engineering Method - "business information system" но на беглый взгляд, фокус всё равно на UI, система реального времени, фреймворк
The Object-Oriented Thought Process - игра в 21
Head First Object-Oriented Analysis and Design - информационная система магазина гитар, но на списках:(
Львиная доля примеров - сильно отличаются от того, с чем работаю я. Там либо высокоинтерактивная система, либо активная работа с оборудованием, либо UI.
Так что, наверное, для ООП есть место в мире, просто не моём:)
А для разработки информационных систем я советую:
1) следовать ООД при декомпозиции системы на подсистемы - каждая подсистема должна инкапсулировать в себе какую-то часть состояния всей системы, и предоставлять публичное АПИ для его изменения
2) следовать функциональной архитектуре в реализации отдельных подсистем - разбивать код на чистое ядро с бизнес-правилами, и императивную оболочку с вводом- выводом
3) максимум кода тащить в чистое ядро и делать это ядро понастоящему чистым - с неизменяемыми структурами данных и функциями без эффектов
4) а императивную оболочку делать максимально тонкой, прямолинейной и простой
#oop@ergonomic_code #books@ergonomic_code #ergo_approach@ergonomic_code
Internet Archive
Designing object-oriented software : Wirfs-Brock, Rebecca : Free Download, Borrow, and Streaming : Internet Archive
Includes index
👍8