Здравствуйте, Нахлобуч, Вы писали:
Н>Interface Segregation -- это "клиенты не должны зависеть от контрактов, которые они не используют". Контракты должны обладать максимальной степенью сцепления. В твоем случае получив SomeEntity пред глазами возникает ажно целый ворох методов, от do() до save().
А я говорю не о клиенте, а о BL, который так или иначе работает с entity. Клиент получит DTO, в котором ничего этого не будет. А BL будет вызывать короткий вариант, как было описано:
D>>где тут снижение сложности и уменьшение связности, если вместо a.setB(b) нужно каждый раз писать { a.setB(b); b.countAs++; } либо abController.aSetB(a, b), м?
Н>Коль скоро далее следует "реальный пример", я могу полагать, что этот пример -- нереальный. Так что о нем не будем.
Первое предупреждение за дурацкий флуд. Будет весьма обидно потерять если не интересного, то хотя бы конструктивного (до недавних пор) собеседника. А пример самый что ни на есть реальный, у меня этих счётчиков в последнем проекте почти столько же, сколько таблиц в базе. Очень жесткие требования по сохранности данных, плюс родимый MyISAM без контроля ссылочной целостности (да сдохнут страшной смертью его адепты). Так что компактность записи и гарантия отработки всех этих операций весьма существенна.
D>>С деревом (реальным примером) будет дерьмовее в разы — там больше операций и как следствие — больше букаф и больше шансов что-нибудь забыть.
Н>Сферические деревья в вакууме, да? Я правда не понимаю, как можно что-то забыть, когда у тебя в руках два объекта TreeNode и ссылка на ITreeManipulationService, который умеет делать с деревьями все, что душа пожелает.
Можно. Плёвое дело. Сколько там вещей человек способен одновременно держать в "короткой памяти"? Я к этим подсчётам скептически отношусь, но по моему опыту уже даже в трёх десятках запутаться элементарно, а если к ним ещё три десятка ManipulationServices, через которые надо гнать ВСЕ операции, включая установку свойств объектов (как, не все? а какие можно? a.setB() можно?), башка пойдёт кругом очень быстро.
Н>Все равно какой-то не очень жизненный пример.
Нормальный.
Н>Если взять что-то более реальное -- ту же модель файловой системы, то там куда прикажешь заталкивать методы копирования и переименования файлов?
Хороший пример. С толстым намёком, прямо скажем. Респект. Однако не надо чесать все случаи жизни под одну гребёнку. Если для fs принято static copy(a, b), это не значит, что в каком-то другом случае a.doSomething(b) не будет более удобным и наглядным (гыгы, controller.doSomething(entity), не против?). А в данной ветке рассматриваются enterprise-паттерны, специфическая область, не имеющая к fs никакого отношения.
Здравствуйте, dimgel, Вы писали:
D>Скажем так, я склонен вгонять в entities ту логику, которая (при наличии желания) также естественно могла бы лечь в триггеры базы.
Есть более простое правило — entity может содержать логику, которая не требует внешних связей.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Blazkowicz, Вы писали:
B>Сериализация и маппинг рулят! В Java готовые инструментарии есть практически под всё. B>А to/from это вообще предельно неудобный антипаттерн. Я его "изобрел" где-то на первом году профессионального программирования, но быстро обнаружил на сколько он не рулит.
Имеется в виду, что сами entity классы содержат минимум типа аннотации @transient (или как она там), а весь код сериализатора является внешним и работает через рефлексию, я правильно понял? C POJO без логики это гораздо удобнее, ещё один хороший аргумент против меня.
Здравствуйте, IT, Вы писали:
D>>Скажем так, я склонен вгонять в entities ту логику, которая (при наличии желания) также естественно могла бы лечь в триггеры базы.
IT>Есть более простое правило — entity может содержать логику, которая не требует внешних связей.
Здравствуйте, dimgel, Вы писали:
D>Имеется в виду, что сами entity классы содержат минимум типа аннотации @transient (или как она там), а весь код сериализатора является внешним и работает через рефлексию, я правильно понял? C POJO без логики это гораздо удобнее, ещё один хороший аргумент против меня.
Кроме аннотаций многие инструменты позволяют маппить через XML, или использовать шаблоны. Это позволяет убрать зависимость сущностей от инструментов сериализации вообще. Кроме рефлексии сериализацию можно реализовать и кодогенерацией. Что не совсем удобно, зато точно лучше по производительности.
Здравствуйте, server_mouse, Вы писали:
_>Доброго всем времени суток!
И вам того же.
После многих лет, проведенных в когда более, а когда менее успешных попытках постичь Принципы Правильного Проектирования, я пришел к следующей точке зрения.
Дизайн (обычный или архитектурный, не важно), можно представить, как дорогу из пункта А в пункт Б, которую вам необходимо проложить в многомерном пространстве, изобилующем препятствиями. Так вот, единственное, что имеет значение в дизайне (помимо собственно успешного попадания в пункт назначения), это длина пути. Остальное – глубоко вторично.
Из этого утверждения вытекает два следствия. Во-первых, если вы успешно проложили короткий маршрут, не имеет никакого значения, сколько правил вы нарушили.
Во вторых и в главных – многие люди склонны придавать слишком много значения одному-двум измерениям, стремясь максимально сократить маршрут именно в их рамках. Однако это занятие хотя и увлекательное, но совершенно бессмысленное, так как значение имеет только длина маршрута, а она складывается из ВСЕХ проекций.
У меня вот был когда-то период карьеры, когда я маниакально боролся с дублированием кода. Выжигал его каленым железом и любыми способами. И только серия неприятных жизненных уроков заставила меня осознать, что лекарство бывает куда хуже болезни и лучше уж допустить в проект немного дублированного кода, чем испоганить дизайн.
Я бы сказал, что у разработчика отсутствует понимание принципа дизайна или конкретного паттерна до тех пор, пока он не научиться видеть ситуации, когда этот конкретный принцип (каким бы нерушимым он не казался) применять НЕ НАДО. Т.е. если вы считаете, что что-то нужно делать ВСЕГДА, значит вы вообще не понимаете, зачем это нужно делать.
Подытожу – не позволяйте Принципам Правильного Проектирования испортить дизайн вашего решения. Конечно, все это можно трактовать и немного иначе. Если Принципы Правильного Проектирования приводят вас к неудобному дизайну, значит, вы их просто неправильно понимаете. Но на практике это то же самое.
Что касается данного конкретного случая. Domain Model имеет смысл применять тогда, когда внутренняя логика происходящего заметно сложнее внешней. По моему опыту, в приложениях с развитым UI и сохранением в базе данных сущностей бизнес-уровня, такое встречается редко, а потому первая рекомендация – попытаться танцевать не от Domain Model, а от контроллеров прецедентов.
Допустим, это не так – хорошо. Тогда следующий вопрос – допустим, вы структурируете бизнес-логику на основе тех же сущностей, которые храните в базе. Допустим, ваш DAL эти сущности видит и использует для persistence-а. И что тут страшного? Нарушение изоляции слоев? Это – пустые слова, за ними не стоит никакого реального содержания. Что конкретно плохого случится с вами и вашим приложением?
Изменение в BLL потребует пересборки DAL. И что, это проблема?
DAL сможет увидеть методы BLL. Ну да, это неприятно. Однако, во-первых, в некоторых языках/платформах существуют методы логического ограничения видимости. А во-вторых – ну вы уж как-нибудь держите себя в руках, не вызывайте методы BLL из DAL, тем более, что это лишено смысла. Реального проникновения BL в DAL не будет, если вы этого не сделаете своими же руками. А зачем вам это делать?
Удобство тестирования пострадает? А каким образом? Вот жесткая привязка BLL к DAL – да, мешает. А в данном случае это скорее вопрос пригодности к тестированию самого BLL.
Короче – у любого приема проектирования есть своя цена, а хороший проектировщик должен быть немного бухгалтером.
Здравствуйте, Blazkowicz, Вы писали:
D>>Имеется в виду, что сами entity классы содержат минимум типа аннотации @transient (или как она там), а весь код сериализатора является внешним и работает через рефлексию, я правильно понял? C POJO без логики это гораздо удобнее, ещё один хороший аргумент против меня.
B>Кроме аннотаций многие инструменты позволяют маппить через XML
JAXB?
B>или использовать шаблоны.
Можно ссылку, откуда плясать при возникновении необходимости?
Здравствуйте, dimgel, Вы писали:
D>А я говорю не о клиенте, а о BL, который так или иначе работает с entity. Клиент получит DTO, в котором ничего этого не будет. А BL будет вызывать короткий вариант, как было описано:
"Клиент" здесь -- обобщенный термин кода, внешнего по отношению к какому-то модулю. Если и ввел в заблуждение, то не нарочно.
D>Очень жесткие требования по сохранности данных, плюс родимый MyISAM без контроля ссылочной целостности
Туточки вам пожалуйста. Выбрали там себе движок, который не обеспечивает того, без чего современные СУБД и представить себе невозможно, тут же выкатили требование о "сохранности данных", которое в таких условия только руками и остается контролировать, и теперь, значится, все эти манипуляции называются "бизнес-логикой"? Да ничего подобного. К бизнесу это отношения не имеет. Бизнесу начихать, ссылки там считаются, флаги выставляются, или каждый раз все таблицы просматриваются. Требование "сохранность данных" можно было обеспечить взяв другой движок СУБД.
D>через которые надо гнать ВСЕ операции, включая установку свойств объектов (как, не все? а какие можно? a.setB() можно?), башка пойдёт кругом очень быстро.
Не стоит перегибать палку. У меня есть четкий критерий того, какие операции должны быть реализованы в самом классе, а какие -- во вне: все операции, которые не требуют доступа к приватным членам объекта, должны выноситься наружу. Установка свойств объекта, очевидно, требует доступа к закрытым членам.
D>А в данной ветке рассматриваются enterprise-паттерны, специфическая область, не имеющая к fs никакого отношения.
Ну раз так, то расскажи, как ты будешь в типичной "enterprise"-системе реализовывать, скажем, какой-нибудь иерархический реестр документов, с отслеживанием версий, папками и этими самыми документами. По сути -- та же файловая система. Логика загрузки-сохранения, переименования-редактирования где будет?
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, dimgel, Вы писали:
B>>Кроме аннотаций многие инструменты позволяют маппить через XML D>JAXB?
JiBX, Castor, кажется. Или вот Dozer, если говорить про DTO.
B>>или использовать шаблоны. D>Можно ссылку, откуда плясать при возникновении необходимости?
Взять тот же Velocity и перегнать сущности в желаемый формат. Паристь, чем-то другим придется, конечно же.
Здравствуйте, dimgel, Вы писали:
IT>>Есть более простое правило — entity может содержать логику, которая не требует внешних связей.
D>А связи с другими entities — внешние?
Зависит от твоей модели. Order и OrderItem скорее всего нет, а OrderItem и BusSchedule скорее всего да.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Нахлобуч, Вы писали:
D>>Очень жесткие требования по сохранности данных, плюс родимый MyISAM без контроля ссылочной целостности
Н>Требование "сохранность данных" можно было обеспечить взяв другой движок СУБД.
Можно. Можно было также послать заказчика, отказывающегося это сделать, несмотря даже на то, что платил он помесячную. Причём очень хорошую помесячную. Объяснить ещё раз разницу между программистом и "архитектором"-пустозвоном, который у меня только что в игнор ушёл?
D>>через которые надо гнать ВСЕ операции, включая установку свойств объектов (как, не все? а какие можно? a.setB() можно?), башка пойдёт кругом очень быстро.
Н>Не стоит перегибать палку. У меня есть четкий критерий того, какие операции должны быть реализованы в самом классе, а какие -- во вне: все операции, которые не требуют доступа к приватным членам объекта, должны выноситься наружу.
Это очень плохой критерий. Если некая операция раскладывается в две элементарные, которые уже являются членами объекта, то вынося эту новую операцию в отдельный класс, ты только вводишь лишний уровень косвенности. У Фаулера этот случай даже есть в списке неприятных запахов; не помню названия и формулировки, но я намекнул на него, когда обозвал аргумент в SomeController::doOn(SomeEntity _this). Вот эти _this есть нехорошо. Они должны быть this.
И кстати: а у тех, кто сядет читать или править такой код, будет понимание, какие из методов изменяют приватное состояние, а какие — нет? И самое главное: а оно у них должно быть, это понимание? Твой критерий фактически вываливает потроха объекта наружу, т.е. в зависимости от деталей реализации потрохов ты раскидываешь так или иначе интерфейс.
Н>Ну раз так, то расскажи, как ты будешь в типичной "enterprise"-системе реализовывать, скажем, какой-нибудь иерархический реестр документов, с отслеживанием версий, папками и этими самыми документами. По сути -- та же файловая система. Логика загрузки-сохранения, переименования-редактирования где будет?
Гони детальное ТЗ, потом обсудим по деньгам и этапам, потом 50% аванса, потом я сяду, спроектирую и сделаю.
В общем, в дальнейшем повторении и пережёвывании уже приведённых аргументов смысла не вижу. А учитывая твой чудесный "критерий", по архитектуре я предпочту поучиться у других, звиняйте.
Здравствуйте, IT, Вы писали:
D>>А связи с другими entities — внешние?
IT>Зависит от твоей модели. Order и OrderItem скорее всего нет, а OrderItem и BusSchedule скорее всего да.
М-да. Всё объяснил.
Вот почему все местные асы успели всё перетереть между собой ещё даже до того, как я Фаулера начал читать?
Завязываю с этой веткой.
Здравствуйте, dimgel, Вы писали:
D>Вот почему все местные асы успели всё перетереть между собой ещё даже до того, как я Фаулера начал читать? D>Завязываю с этой веткой.
Рекомендую отсортировать топики в этом форуме по оценкам и начинать просматривать схожие темы. Их тут с десяток.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, dimgel, Вы писали:
D>>Вот почему все местные асы успели всё перетереть между собой ещё даже до того, как я Фаулера начал читать? D>>Завязываю с этой веткой. B>Рекомендую отсортировать топики в этом форуме по оценкам и начинать просматривать схожие темы. Их тут с десяток.
Да я в курсе. Только заново всё перечитывать "на каждом этапе жизненного пути" никаких сил не хватит. Вот забросил щас пару-тройку пробных шаров, посмотрел, как волны расходятся, и пока хватит. Будет когда-нибудь совсем нечего делать (гы, на пенсии) — сяду, перечитаю сплошняком.
Здравствуйте, dimgel, Вы писали:
IT>>Зависит от твоей модели. Order и OrderItem скорее всего нет, а OrderItem и BusSchedule скорее всего да.
D>М-да. Всё объяснил.
Что именно не понятно
D>Вот почему все местные асы успели всё перетереть между собой ещё даже до того, как я Фаулера начал читать? D>Завязываю с этой веткой.
Ты бы лучше попробовал понять почему несколько человек в этой теме пели тебе про одно и тоже — про сложность. Ты всё как-то отмахиваешься от этого момента, а тем не менее он как раз является в этом споре ключевым для определения наилучшего решения.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Ты бы лучше попробовал понять почему несколько человек в этой теме пели тебе про одно и тоже — про сложность. Ты всё как-то отмахиваешься от этого момента,
Я отмахиваюсь от конкретных рецептов борьбы с этой сложностью, которыми меня кормят без конкретной аргументации. "За маму, бл#$%, за папу." Нахлобуч, чей абстрактно-высокоумный пост ты плюсанул, чуть ниже выдал совершенно дикую ересь по конкретике. Спрашивается: чего стоят песни о сложности в его исполнении?
IT>а тем не менее он как раз является в этом споре ключевым для определения наилучшего решения.
Вот тут ниже mrozov красиво спел про наилучшие решения. А я у тебя попросил всего лишь навсего уточнение термина "внешние связи" применительно к entity.
Здравствуйте, dimgel, Вы писали:
D>А я у тебя попросил всего лишь навсего уточнение термина "внешние связи" применительно к entity.
Впрочем, если ты соблаговолишь пройтись развёрнуто по моим примерам (в духе "пойдёшь налево — коня съедят, пойдёшь направо — тебя съедят, про прямо и говорить стыдно"), я был бы признателен.
Здравствуйте, dimgel, Вы писали:
D>Можно. Можно было также послать заказчика, отказывающегося это сделать, несмотря даже на то, что платил он помесячную. Причём очень хорошую помесячную. Объяснить ещё раз разницу между программистом и "архитектором"-пустозвоном, который у меня только что в игнор ушёл?
Меня в контексте данной беседы мало интересует вопрос оплаты, заказчиков и твоего игнорирования кого бы то ни было. Не стоит код, которым затыкались баги используемого стека технологий, выдавать за передовые достижения шахматной мысли, только и всего.
D>Это очень плохой критерий.
Это хороший критерий. К тому же, он четкий и недвусмысленный, в отличие от
...если изменение состояния объекта базы (entity) ведёт к необходимости каскадных изменений состояний других объектов (как в примере со счётчиком ссылок), код, выполняющий эти изменения, я вгоняю внутрь entity.
Не будет у тебя в следующем проекте счетчика ссылок -- как таким критерием пользоваться?
D>Если некая операция раскладывается в две элементарные, которые уже являются членами объекта, то вынося эту новую операцию в отдельный класс, ты только вводишь лишний уровень косвенности. У Фаулера этот случай даже есть в списке неприятных запахов;
Очевидно, что код вида
foo.Bar = bar.Foo;
никуда выносить смысла нет и проще всего его оставить там, где это присваивание приключилось. В общем же случае я инкапсулирую логику в специально придуманном для этого сервисном классе (Single Responsibility Principle).
D>не помню названия и формулировки, но я намекнул на него, когда обозвал аргумент в SomeController::doOn(SomeEntity _this). Вот эти _this есть нехорошо. Они должны быть this.
Не надо со мной кокетничать, я не барышня. Если что-то хочешь сказать -- говори, не намекай. А что касается "_this должен быть this" -- это, что называется, back to square one: у тебя, как будто бы, начал проклёвываться критерий того, какие операции должны быть частью контракта класса, а какие нет -- и на тебе, опять всё запихать вовнутрь.
D>И кстати: а у тех, кто сядет читать или править такой код, будет понимание, какие из методов изменяют приватное состояние, а какие — нет?
Про изменение я нигде даже не обмолвился. Что касается вопроса -- методы, которым необходим доступ к приватным членам класса (в том числе изменяющие внутреннее состояние объекта) всегда входят в публичный контракт класса. Все остальные, которым хватает этого публичного контракта, отправляются вовне. Какие тут могут быть разногласия и проблемы с пониманием?
D>И самое главное: а оно у них должно быть, это понимание? Твой критерий фактически вываливает потроха объекта наружу, т.е. в зависимости от деталей реализации потрохов ты раскидываешь так или иначе интерфейс.
Каким образом, скажи пожалуйста? Объект выставляет наружу минимально необходимый контракт (приницип минимизации публичного контракта), все остальное -- внешнее по отношению к нему.
D>Гони детальное ТЗ, потом обсудим по деньгам и этапам, потом 50% аванса, потом я сяду, спроектирую и сделаю.
Лихо. Я не просил ни проектировать, ни делать. Просто написать русским по белому текст в стиле "такие-то три класса, логика сохранения там-то, отслеживание версий -- тут" было бы вполне достаточно.
HgLab: Mercurial Server and Repository Management for Windows
Н>...если изменение состояния объекта базы (entity) ведёт к необходимости каскадных изменений состояний других объектов (как в примере со счётчиком ссылок), код, выполняющий эти изменения, я вгоняю внутрь entity.
Н>Не будет у тебя в следующем проекте счетчика ссылок -- как таким критерием пользоваться?
М-да, хоть и не собирался отвечать, но мимо этого бреда пройти невозможно. Не будет счётчика ссылок, не будет соответствующего кода в entity. А чем тебе мой критерий показался двусмысленным, интересно знать? Из одних entities я позволяю себе работать с другими entities. Я уж не знаю, как ещё это описать, чтобы Вам стало понятно.
Н>Не надо со мной кокетничать, я не барышня.
Данная обидчивая реплика доказывает обратное.
Н>Если что-то хочешь сказать -- говори, не намекай. А что касается "_this должен быть this" -- это, что называется, back to square one: у тебя, как будто бы, начал проклёвываться критерий того, какие операции должны быть частью контракта класса, а какие нет -- и на тебе, опять всё запихать вовнутрь.
Мне как-то всегда казалось, что лишнее делегирование элементарно просматривается в том числе по наличию косвенных ссылок на объект.
Н>Объект выставляет наружу минимально необходимый контракт (приницип минимизации публичного контракта), все остальное -- внешнее по отношению к нему.
Даже если это остальное не делает ничего, кроме как делегирует к методам обсновного объекта? При отсутствии дополнительных выгод, упоминания которых я жду с открытым ртом, этот принцип называется "заставь дурака богу молиться". Про слепое следование принципам ниже уже отписали, и ты там даже оценочку поставил. Принципов, знаете ли, масса разных, многие даже друг дружке противоречат.
Респект. Однако не надо чесать все случаи жизни под одну гребёнку. Если для fs принято static copy(a, b), это не значит, что в каком-то другом случае a.doSomething(b) не будет более удобным и наглядным (гыгы, controller.doSomething(entity), не против?). А в данной ветке рассматриваются enterprise-паттерны, специфическая область, не имеющая к fs никакого отношения.
Если нам не помогут, то мы тоже никого не пощадим.
