http://en.wikipedia.org/wiki/Anemic_domain_model
"Anemic domain model is the use of a software domain model where the domain objects contain little or no business logic (validations, calculations, business rules etc)."
Вот тут опять мне "раскрыли глаза".
Что сказать. Удивлён!
Не знал, что ЕСТЬ ПОДОБНЫЙ термин.
Почему?
Потому, что (не устаю это повторять) - "САМ ПОДОБНОЕ использую".
В ЧАСТНОСТИ в текстовом редакторе (процессоре).
В НЁМ чётко разделены "объекты данных" и "бизнес объекты". Объекты данных - ЛИШЬ ХРАНЯТ данные (и обладают СОСТОЯНИЕМ), а бизнес объекты их ОБРАБАТЫВАЮТ (и состоянием НЕ ОБЛАДАЮТ).
И это было сделано ОСОЗНАННО.
Чтобы РАЗДЕЛИТЬ данные и бизнес-логику.
Простейший пример - TextPara - объект хранящий данные текстового параграфа.
И целая вязанка "бизнес-объектов":
1. TextParaCursor.
2. TextParaSelection.
3. TextParaPainter.
4. TextParaFormatInfo.
5. TextParaHotSpot.
6. TextParaMarkers.
etc.
Аналогично - Table - объект хранящий данные таблицы.
И целая вязанка "бизнес-объектов":
1. TableCursor.
2. TableSelection.
3. TablePainter.
4. TableFormatInfo.
5. TableHotSpot.
6. TableMarkers.
etc.
При этом "бизнес-объекты" связываются с "объектами данных", через Dependency Injection. То есть имея созданный и заполненный "объект данных" можно всегда "опосредованно" (не приведением классов и не "прямым знанием", а через "фабрику") получить интересующий "бизнес-объект".
Который НЕ ОБЛАДАЕТ "хранимым" состоянием и НЕ ВЛИЯЕТ на состояние "объекта данных" (это - ВАЖНО!).
"Бизнес-объект", если и обладает "состоянием", то она НЕ ВЛИЯЕТ на остальные участки системы, оно лишь "кешируется" в ДАННОЙ КОНКРЕТНОЙ копии "бизнес-объекта".
Если "соседний код", получит ДРУГОЙ "бизнес-объект" средствами той же фабрики - эти два "бизнес-объекта" НИКОИМ образом не будут связаны и НЕ БУДУТ влиять ДРУГ НА ДРУГА.
Говорят - "анти-паттерн" от Фаулера (http://www.martinfowler.com/bliki/AnemicDomainModel.html) :-) Ну что же... Я "похоже люблю анти-паттерны".. В некотором роде.
Вот тут кстати про это немного написано:
http://18delphi.blogspot.ru/2013/04/blog-post_10.html
http://18delphi.blogspot.ru/2013/04/blog-post_8517.html
http://18delphi.blogspot.ru/2013/06/offtopic.html
И не могу НЕ ОТМЕТИТЬ CoreText - там есть "подобная схема":
NSAttributedString - "объект данных"
CTFrameSetter - "бизнес-объект" работающий с NSAttributedString и порождающий ДРУГОЙ "объект данных" - CTFrame.
"The CTFramesetter opaque type is used to generate text frames. That is, CTFramesetter is an object factory for CTFrame objects.
Подробнее тут - https://developer.apple.com/library/mac/documentation/Carbon/reference/CTFramesetterRef/Reference/reference.html
P.S. Правда сегодня мне коллега УКАЗАЛ на то, что я "не совсем верно трактую Фаулера". :-) ВПОЛНЕ МОЖЕТ БЫТЬ. Жаль мы не успели с ним детали обсудить. Обсудим - ОБЯЗАТЕЛЬНО напишу об ИТОГАХ.
"Anemic domain model is the use of a software domain model where the domain objects contain little or no business logic (validations, calculations, business rules etc)."
Вот тут опять мне "раскрыли глаза".
Что сказать. Удивлён!
Не знал, что ЕСТЬ ПОДОБНЫЙ термин.
Почему?
Потому, что (не устаю это повторять) - "САМ ПОДОБНОЕ использую".
В ЧАСТНОСТИ в текстовом редакторе (процессоре).
В НЁМ чётко разделены "объекты данных" и "бизнес объекты". Объекты данных - ЛИШЬ ХРАНЯТ данные (и обладают СОСТОЯНИЕМ), а бизнес объекты их ОБРАБАТЫВАЮТ (и состоянием НЕ ОБЛАДАЮТ).
И это было сделано ОСОЗНАННО.
Чтобы РАЗДЕЛИТЬ данные и бизнес-логику.
Простейший пример - TextPara - объект хранящий данные текстового параграфа.
И целая вязанка "бизнес-объектов":
1. TextParaCursor.
2. TextParaSelection.
3. TextParaPainter.
4. TextParaFormatInfo.
5. TextParaHotSpot.
6. TextParaMarkers.
etc.
Аналогично - Table - объект хранящий данные таблицы.
И целая вязанка "бизнес-объектов":
1. TableCursor.
2. TableSelection.
3. TablePainter.
4. TableFormatInfo.
5. TableHotSpot.
6. TableMarkers.
etc.
При этом "бизнес-объекты" связываются с "объектами данных", через Dependency Injection. То есть имея созданный и заполненный "объект данных" можно всегда "опосредованно" (не приведением классов и не "прямым знанием", а через "фабрику") получить интересующий "бизнес-объект".
Который НЕ ОБЛАДАЕТ "хранимым" состоянием и НЕ ВЛИЯЕТ на состояние "объекта данных" (это - ВАЖНО!).
"Бизнес-объект", если и обладает "состоянием", то она НЕ ВЛИЯЕТ на остальные участки системы, оно лишь "кешируется" в ДАННОЙ КОНКРЕТНОЙ копии "бизнес-объекта".
Если "соседний код", получит ДРУГОЙ "бизнес-объект" средствами той же фабрики - эти два "бизнес-объекта" НИКОИМ образом не будут связаны и НЕ БУДУТ влиять ДРУГ НА ДРУГА.
Говорят - "анти-паттерн" от Фаулера (http://www.martinfowler.com/bliki/AnemicDomainModel.html) :-) Ну что же... Я "похоже люблю анти-паттерны".. В некотором роде.
Вот тут кстати про это немного написано:
http://18delphi.blogspot.ru/2013/04/blog-post_10.html
http://18delphi.blogspot.ru/2013/04/blog-post_8517.html
http://18delphi.blogspot.ru/2013/06/offtopic.html
И не могу НЕ ОТМЕТИТЬ CoreText - там есть "подобная схема":
NSAttributedString - "объект данных"
CTFrameSetter - "бизнес-объект" работающий с NSAttributedString и порождающий ДРУГОЙ "объект данных" - CTFrame.
"The CTFramesetter opaque type is used to generate text frames. That is, CTFramesetter is an object factory for CTFrame objects.
The framesetter takes an attributed string object and a shape descriptor object and calls into the typesetter to create line objects that fill that shape. The output is a frame object containing an array of lines. The frame can then draw itself directly into the current graphic context."
Подробнее тут - https://developer.apple.com/library/mac/documentation/Carbon/reference/CTFramesetterRef/Reference/reference.html
P.S. Правда сегодня мне коллега УКАЗАЛ на то, что я "не совсем верно трактую Фаулера". :-) ВПОЛНЕ МОЖЕТ БЫТЬ. Жаль мы не успели с ним детали обсудить. Обсудим - ОБЯЗАТЕЛЬНО напишу об ИТОГАХ.
Александр, мы уже почти мозгом готовы принять эту схему. Но хочется "живого".
ОтветитьУдалитьДавайте сделаем что-нибудь в учебно-методическом ключе.
Есть у нас простой проект - калькулятор (прям, канонически по Ходжесу), но с ГУЁм.
Edit1, Edit2, Edit3 - с кнопками +,-,*,/
и тупой классический Дельфи-код - на TForm1.Button1Click (Sender : TObject);
тестируется ПРОТЫРКИВАНИЕМ (по А. Люлину)
но и этот тупой пример легко развивается в значимое бизнес-приложение
калькулятор платежей по кредиту
Edit1 - сумма
Edit2 - %
а потом в Мемо выводится план платежей помесячно
а RadioGroup дает возможность выбрать "кредитный план"
и тогда - да, большая бизнес-логика
различные схемы, где легко ошибиться и НАБАЖИТЬ.
+ (по А. Люлину) - система эволюционирует, и изначальное качество (безошибочность) уже не гаратнитована. Нужны ТЕСТЫ!
для начала возьмем простой куркулятор, держа в голове его дальшейшую бизнес-применимость
но хочется пройти весь путь от "блин тупого ГУЕ-подобного приложения" до fully-testable system
и посмотреть на эволюцию архитектуры.
ОБЯЗАТЕЛЬНО сделаю, ну раз уж ГОТОВЫЙ проект есть. Может и до RUMTMARC доберёмся. Со временем...
Удалить