Здравствуйте, Blazkowicz, Вы писали:
B>Правильно ли я понимаю что в "стройной" модели таки планируется хранить значения PK в полях и коллекциях?
В целом да, за исключением вырожденых случаев.
Здравствуйте, Кэр, Вы писали:
Кэр>Я так понимаю — IB пытается (ну ладно не особо пытается ) получить от вас какие-то детали возражений. Он очевидно не хочет рассыпаться в объяснениях, почему он считает выделенное правильным. Но если вы пытаетесь от него чего-то добиться — почему бы вам не привести больше деталей в своих рассуждениях, почему вы не согласны с выделенным.
Какие детали? Я в этой теме уже неоднократно говорил, что никто не мешает нам вынести дата-логику и бизнес-логику, а внутри класса осуществлять просто делегацию. Можно даже параметризировать класс нужными нам моделями:
Order<Database> order = new Oder<Database>();
или даже
Order<Database,NewYearDiscount> order = new Order<Database,NewYearDiscount>();
это лишь один из многочисленных вариантов. Можно выносить модель в "интерфейс", можно не выносить. Можно связывать сущности через композицию, можно по-другому — используя любые другие паттерны ООП, к-е больше подходят в данном случае.
И все это — по крайней мере с т.з. зрения — будет выглядеть как жирная модель.
А откуда берется правило, что в жирной модели если есть метод Save(), то туда надо непременно напихать все "что у нас есть" — и код доступа к данным и какую-нибудь сериализацию и бизнес-логику? Что, Фаулер об этом писал?
Здравствуйте, IB, Вы писали:
ВВ>>Правильный дизайн — не прерогатива стройной модели. IB>Да, наверное стоит переформулировать — "один из признаков правильного дизайна — стройная модель", вот так будет правильно.
Ну-ну. ООП в топку?
ВВ>>В жирной модели нет ChildItems. IB>Формально нет, а по факту — есть.
Хреновые у вас факты.
ВВ>> Жирная модель — это объектно-ориентированная модель, не больше и не меньше. IB>Да, это кривая объектно-ориентированная модель.
Не делайте ее кривой.
IB>Я, кстати, так и не услышал от тебя, что же такое — объектно-ориентированная модель.
Строящаяся на полиморфизме классов, имеющих родовые отношения, обладающих состоянием и поведением.
А вообще почитайте Фаулера, всуе упомянутого. У него много чего интересного есть кроме "практика показывает".
ВВ>>Со смыслом. IB>Твои проблемы...
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну-ну. ООП в топку?
Счегобыс ?
ВВ>Не делайте ее кривой.
То есть, используйте стройную модель — собственно о чем я и пишу.
ВВ>Строящаяся на полиморфизме классов, имеющих родовые отношения, обладающих состоянием и поведением.
Все веселее.
Что такое "полиморфизм классов" и "родовые отношения"?
Мешать состояние и поведение — это обязательное требование?
ВВ>А вообще почитайте Фаулера, всуе упомянутого.
У него, конечно, много чего упомянуто, но подобного там точно нет.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я в этой теме уже неоднократно говорил, что никто не мешает нам вынести дата-логику и бизнес-логику,
Что такое "дата-логика"?
ВВ> а внутри класса осуществлять просто делегацию.
Можно, только вопрос — зачем? Какие преимущества это даст и от каких проблем избавит?
ВВ>это лишь один из многочисленных вариантов.
Другие такие же забавные?
ВВ>И все это — по крайней мере с т.з. зрения — будет выглядеть как жирная модель.
Формально уже нет, а по факту это будет не пойми что.
ВВ>А откуда берется правило, что в жирной модели если есть метод Save(), то туда надо непременно напихать все "что у нас есть" — и код доступа к данным и какую-нибудь сериализацию
Простой вопрос: Вот есть у нас в жирной модели у класса метод Save() который сериализует состояние класса в БД. Куда ты поместишь Save(), который должен сериализовать то же состояние в XML?
Здравствуйте, IB, Вы писали:
ВВ>>И все это — по крайней мере с т.з. зрения — будет выглядеть как жирная модель. IB>Формально уже нет, а по факту это будет не пойми что.
Формально — это как? Клиент ничего не должен знать о том, как именно реализован этот самый Save()
ВВ>>А откуда берется правило, что в жирной модели если есть метод Save(), то туда надо непременно напихать все "что у нас есть" — и код доступа к данным и какую-нибудь сериализацию IB>Простой вопрос: Вот есть у нас в жирной модели у класса метод Save() который сериализует состояние класса в БД. Куда ты поместишь Save(), который должен сериализовать то же состояние в XML?
class Order<T> where T : IPersistanceModel
class DatabasePersistanceModel : IPersistanceModel
class XmlPersistanceModel : IPersistanceModel
Не нравится генерики — можно и без них. А мне вот нравится, что я определяю тип персистенции класса уже по имени типа и например сущность, полученную из ХМЛ-я, в принципе не смогу засунуть в базу.
И это преимущества ОО подхода, где сама сущность наделена поведением специфичным конкретно для нее, а не какой ДатабейзСервис, которому на все...
The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Низачет. ВВ>http://martinfowler.com/bliki/AnemicDomainModel.html
Вот я и говорю — Фаулеру — низачет. =)
ВВ>По поводу "хилой" модели:
Так где там "полиморфизм классов" и "родовые отношения"?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Формально — это как?
Формально — это по определению жирной модели.
ВВ>class Order<T> where T : IPersistanceModel
Нет, я спрашивал не об этом. Ты можешь читать что тебе пишут? Могу еще раз, мне не сложно: в жирной модели у класса метод Save() который сериализует состояние класса в БД. Куда ты поместишь Save(), который должен сериализовать то же состояние в XML?
И ты так и не ответил на вопрос, а ради чего собственно весь этот зоопарк?
ВВ> А мне вот нравится, что я определяю тип персистенции класса уже по имени типа и например сущность, полученную из ХМЛ-я, в принципе не смогу засунуть в базу.
Дааа... "Как убить себя гранатой" (с) Понимаешь, в реальной жизни нужно ровно наоборот, не иметь десяток моделей, отдельно на каждое хранилище, а одно и то же состояние уметь хранить в разных местах и вообще переиспользовать во всех возможных сценариях.
ВВ>И это преимущества ОО подхода, где сама сущность наделена поведением специфичным конкретно для нее, а не какой ДатабейзСервис, которому на все...
Преимущество перед чем? И я продолжаю неулавливать, что ты понимаешь под ОО подходом...
Здравствуйте, IB, Вы писали:
ВВ>>class Order<T> where T : IPersistanceModel IB>Нет, я спрашивал не об этом. Ты можешь читать что тебе пишут? Могу еще раз, мне не сложно: в жирной модели у класса метод Save() который сериализует состояние класса в БД. Куда ты поместишь Save(), который должен сериализовать то же состояние в XML? IB>И ты так и не ответил на вопрос, а ради чего собственно весь этот зоопарк?
Ты будешь мозг включать, читая ответы? Или для критики Фаулера мозг не требуется?
Метод Save помещу в отдельную реализацию PersistanceModel. Если потребуется совмесщение сериализации в ХМЛ и базы — то будет гибридная PersistanceModel.
ВВ>> А мне вот нравится, что я определяю тип персистенции класса уже по имени типа и например сущность, полученную из ХМЛ-я, в принципе не смогу засунуть в базу. IB>Дааа... "Как убить себя гранатой" (с) Понимаешь, в реальной жизни нужно ровно наоборот, не иметь десяток моделей, отдельно на каждое хранилище, а одно и то же состояние уметь хранить в разных местах и вообще переиспользовать во всех возможных сценариях.
Делай гибридные модели. А что там дает модель сервисов в этом плане? Да то же самое.
ВВ>>И это преимущества ОО подхода, где сама сущность наделена поведением специфичным конкретно для нее, а не какой ДатабейзСервис, которому на все... IB>Преимущество перед чем? И я продолжаю неулавливать, что ты понимаешь под ОО подходом...
Преимущество перед хилой моделью. А под ООП я понимаю ровно то же что и Фаулер, которого не мешает все-таки почитать.
Ну да, скомпилировали парочку флеймов с РСДНа, сделали статью — и все Фаулеру низачет, мы теперь сами себе авторитеты. Может, сначала стоить его почитать? Например, Patterns of enterprise application architecture. А после этого свою статью.
И заодно подумать над тем, что у Domain Model вообще есть проблемы, которые абсолютно не снимаются, когда мы делаем ее анемичной.
А заниматься придумыванием хитрых сценариев, которые якобы легко и просто решаются в анемичной модели, а в жирной якобы приводят к большим проблемам — дело неблагодарное.
Ты, наверное, думаешь, что Фаулер не допер, что плохо бизнес-логику и код доступа к данным в одном классе смешивать? Ну-ну
ВВ>>По поводу "хилой" модели: IB>Так где там "полиморфизм классов" и "родовые отношения"?
Там объясняется, почему анемичная модель не является объектно-ориентированной.
А по поводу — "полиморфизм классов" и "родовые отношения". Что конкретно непонятно? Что такое полиморфизм и наследование? Ну тогда, пожалуй, и правда рановато Фаулера читать.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну да, скомпилировали парочку флеймов с РСДНа, сделали статью — и все Фаулеру низачет, мы теперь сами себе авторитеты. Может, сначала стоить его почитать? Например, Patterns of enterprise application architecture. А после этого свою статью.
Читали. ВВ>И заодно подумать над тем, что у Domain Model вообще есть проблемы, которые абсолютно не снимаются, когда мы делаем ее анемичной.
И что? Мы ведь не говорим о панацее. Некоторые проблемы решаются, некоторые — нет.
ВВ>А заниматься придумыванием хитрых сценариев, которые якобы легко и просто решаются в анемичной модели, а в жирной якобы приводят к большим проблемам — дело неблагодарное. ВВ>Ты, наверное, думаешь, что Фаулер не допер, что плохо бизнес-логику и код доступа к данным в одном классе смешивать? Ну-ну
Причем здесь код доступа данных? Если есть что сказать в защиту не Anemic Domain Model, то хотелось бы увидеть комментарии в этом топике http://rsdn.ru//forum/message/2705199.aspx
Там конкретный вопрос именно про фаулеровский подход избавления от Anemic Domain Model, без мешанины со связанностью самих данных.
ВВ>Там объясняется, почему анемичная модель не является объектно-ориентированной.
Верно и других аргументов не приводится. Но ООП, ведь, тоже не панацея. Поэтому на аргумент тянет слабо.
ВВ>А по поводу — "полиморфизм классов" и "родовые отношения". Что конкретно непонятно? Что такое полиморфизм и наследование? Ну тогда, пожалуй, и правда рановато Фаулера читать.
Ну, вот. Опять до флейма скатываемся.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Blazkowicz, Вы писали:
B>> Но при этом никто не запрещает разрывать модель и отказатся от ленивой загрузки используя все тот же ORM. IB>Да не мешает, конечно.. Но обычно этого не делают, так как во всех примерах работы с ORM приводится именно жирная модель в самом ее плохом проявлении.
Насчёт всех примеров это Вы переборщили. В стандартном примере petclinic поставки spring, где демонстрируется в том числе и работа с ORM — тонкая модель.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну да, скомпилировали парочку флеймов с РСДНа, сделали статью — и все Фаулеру низачет, мы теперь сами себе авторитеты.
Подвох в том, что я скомпилировал исключительно из своихсообщений в этих флеймах, так что мимо.
ВВ> Может, сначала стоить его почитать?
ВВ>А заниматься придумыванием хитрых сценариев, которые якобы легко и просто решаются в анемичной модели, а в жирной якобы приводят к большим проблемам — дело неблагодарное.
Конечно неблагодарное, вот и не занимайся.
ВВ>Ты, наверное, думаешь, что Фаулер не допер, что плохо бизнес-логику и код доступа к данным в одном классе смешивать? Ну-ну
Фаулер не допер, что плохо персистентное состояние и логику смешивать.
ВВ>Там объясняется, почему анемичная модель не является объектно-ориентированной.
Неубедительно это как-то объясняется, и я бы даже сказал не объясняется, а постулируется. А вот, к примеру, Меерс как раз наоборот, довольно убедительно показывает, что стройные классы вполне-себе объектно ориентированы.
ВВ>А по поводу — "полиморфизм классов" и "родовые отношения". Что конкретно непонятно?
Конкретно непонятно, что эти термины означают и что ты вообще имеешь ввиду, когда говоришь "объектно-ориентировано".
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ты будешь мозг включать, читая ответы? Или для критики Фаулера мозг не требуется?
Это для дискуссии с тобой мозг не требуется, мне его приходится отключать..
ВВ>Метод Save помещу в отдельную реализацию PersistanceModel.
Какой из методов? Я тебе задал вполне конкретный вопрос, на него сложно ответить?
Давай код, для простоты — вот у нас жирная модель:
public class Order
{
public int OrderId {get;set;}
....
public void Save()
{
// Сохранение в БД
}
}
Теперь надо добавить сохранение в XML, куда добавляем — твоя версия?
ВВ> Если потребуется совмесщение сериализации в ХМЛ и базы — то будет гибридная PersistanceModel.
Что такое "гибридная PersistanceModel"?
ВВ>Делай гибридные модели.
Это что такое?
ВВ>Преимущество перед хилой моделью.
Ага, чем армяне. В чем преимущество-то? Или ты опять просто потрындеть прищшел?
ВВ> А под ООП я понимаю ровно то же что и Фаулер,
Вот в этом я конкретно сомневаюсь.
Здравствуйте, IB, Вы писали:
ВВ>>Метод Save помещу в отдельную реализацию PersistanceModel. IB>Какой из методов? Я тебе задал вполне конкретный вопрос, на него сложно ответить? IB>Давай код, для простоты — вот у нас жирная модель: IB>
IB>public class Order
IB>{
IB> public int OrderId {get;set;}
IB> ....
IB> public void Save()
IB> {
IB> // Сохранение в БД
IB> }
IB>}
IB>
IB>Теперь надо добавить сохранение в XML, куда добавляем — твоя версия?
Видимо, мозг действительно отключен. Сложно представить, что код для сохранения в БД не должен содержаться напрямую в методе Save? У меня есть "модель", в которой описана реализации сохранения в БД для данной сущности. Если мне потребуется создания ХМЛ-сериализации я напишу новую модель. Если потребует сохранять в БД и ХМЛ — модель, использующую две предыдущие модели.
При этом ни разу ничего не поменяю в методе Сейв.
Здравствуйте, Blazkowicz, Вы писали:
ВВ>>И заодно подумать над тем, что у Domain Model вообще есть проблемы, которые абсолютно не снимаются, когда мы делаем ее анемичной. B>И что? Мы ведь не говорим о панацее. Некоторые проблемы решаются, некоторые — нет.
А кто-то утверждает, что это панацея?
Но какой смысл переносить все проблемы именно Domain Model — причем любой Domain Model — конкретно на жирную модель?
ВВ>>А заниматься придумыванием хитрых сценариев, которые якобы легко и просто решаются в анемичной модели, а в жирной якобы приводят к большим проблемам — дело неблагодарное. ВВ>>Ты, наверное, думаешь, что Фаулер не допер, что плохо бизнес-логику и код доступа к данным в одном классе смешивать? Ну-ну B>Причем здесь код доступа данных? Если есть что сказать в защиту не Anemic Domain Model, то хотелось бы увидеть комментарии в этом топике B>http://rsdn.ru//forum/message/2705199.aspx
B>Там конкретный вопрос именно про фаулеровский подход избавления от Anemic Domain Model, без мешанины со связанностью самих данных.
Аргумент на самом деле простой — анемичная модель не объектно-ориентирована. Так считает Фаулер. Я с ним согласен.
Анемичная модель лишает классы поведения. И это самое поведение, которое должно характеризовывать конкретную сущность выносится в отдельный слой, который представляет собой мешанину из "поведений" различных сущностей.
Почему это плохо?
Так как поведение перестает быть частью самого объекта, то этот объект при желании можно наделить поведением, которое изначально не задумывалось для него, которое будет являться неправильным для этого объекта.
Класс перестает быть полиморфным. Изменение поведения для этого класса предполагает изменение совершенно внешнего по отношению к нему сервиса. Наследование перестает быть средством изменения поведения. Код, работающий с нашим классом, также перестает быть обощенным. Для изменения поведения мне надо или править существующий сервис (в котором содержится код для других классов, а соответственно потенциально влиять и на него) или же создавать новый сервис. Для того, чтобы решить эту проблему мне придется поднимать совершенно отдельную модель сервисов — с наследованиями, разными реализациями и пр. — которая в итоге придет ровно к тем же проблемам, которые тут так остроумно находят у жирной модели.
"Контракт" для класса теряет свой смысл. В нем описываются только данные — не поведение. Контракт для работы с классом подменяется неким общим контрактом сервиса. Изменение, расширение поведения для одно класса приводит к изменению контракта для всего сервиса. Таким образом, изменение одной сущности косвенным образом затрагивает все сущности.
Контракт сервиса всегда изыбыточен. Он представляет собой километровую простыню методов, в которой ООП не больше, чем в коде на plain C образца 76 года. Мало того, что он будет постоянно изменяться, так и работать с ним просто-напросто неудобно. Разнородные методы, которые вообще никак не связаны друг с другом, доступ к которым должен, возможно, даже разграничиваться, будут тут соседствовать. Альтернатива — дробление одного сервиса на многие сервисы. Причем чем "легче" будет сервис, тем лучше это все будет выглядеть. В идеале мы придем к тому, что на каждый класс у нас будет по сервису. Занавес.
Это так, если касаться вопроса вкратце.
Значит ли это, что анемичная модель плохо, а жирная — хорошо?
Нет, не значит. Да, жирная модель — это просто-напросто ОО-модель, анемичная — не ОО-модель, а ООП далеко не лучший инструмент не только в отношении работы с данными.
Но он не настолько плох, как ту пытаются представить.
ВВ>>Там объясняется, почему анемичная модель не является объектно-ориентированной. B>Верно и других аргументов не приводится. Но ООП, ведь, тоже не панацея. Поэтому на аргумент тянет слабо.
Это тянет на аргумент. Вспомни, чем ОО лучше структурного подхода. И здесь будет все тоже самое. Избавляясь от ООП, мы лишаемся всех его преимуществ.
И вот, кстати, IB пытается убедить, что анемичная модель самая что ни на есть ООП. На это я и отвечал.
Да, в ОО-модели класс должен быть наделен поведением, а не представлять собой пустой набор геттеров и сеттеров. Это не значит, что ООП это хорошо или плохо. У ООП немало проблем и безотносительно к текущей теме. Но у ООП другие проблемы.
Какой смысл описывать откровенное убогое построение жирной модели — фактически доведенное до абсурда — и показывать, что это видите ли именно то, что жирная модель предполагает?
ВВ>>А по поводу — "полиморфизм классов" и "родовые отношения". Что конкретно непонятно? Что такое полиморфизм и наследование? Ну тогда, пожалуй, и правда рановато Фаулера читать. B>Ну, вот. Опять до флейма скатываемся.
До флейма уже скатились. Изначально я всего-то высказал свое мнение, что критика жирной модели приведенная в блоге несколько "смешивает напитки".
Здравствуйте, KRA, Вы писали:
KRA>Насчёт всех примеров это Вы переборщили. В стандартном примере petclinic поставки spring, где демонстрируется в том числе и работа с ORM — тонкая модель.
Скачал. Посмотрел. http://rsdn.ru/forum/message/3187831.1.aspx
petclinic как раз пример Anemic Domain Model с точки зрения Фаулера, но "жирная" с точки зрения IB. Под тонкой моделью подразумевается отстствие таких связей как, например, Pet->Visits. Почему? Попробуем PetClinic натянуть на пример из жизни.
Появились новые требования в ТЗ — интеграция с глобальной системой учета животных в городе. Так вот интеграционному модулю ничего ни про какие визиты знать не надо. Поэтому сущность Pet там излишне "жирная".
И теперь, допутим у нас нет нашего крутого Hibernate ORM. Не будем уточнять почему. А возьмем и заглянем в
AbstractJdbcClinic.java:
public Pet loadPet(int id) throws DataAccessException {
JdbcPet pet = (JdbcPet) this.petQuery.findObject(id);
if (pet == null) {
throw new ObjectRetrievalFailureException(Pet.class, new Integer(id));
}
Owner owner = loadOwner(pet.getOwnerId());
owner.addPet(pet);
loadVisits(pet);
return pet;
}
Загрузка животного всегда приводит к вычитке списка визитов. Соответственно метод уже не реюзабелен, и для интеграции нужен будет новый.
А вот JdbcPet.java
public class JdbcPet extends Pet {
private int typeId;
private int ownerId;
public void setTypeId(int typeId) {
this.typeId = typeId;
}
public int getTypeId() {
return this.typeId;
}
public void setOwnerId(int ownerId) {
this.ownerId = ownerId;
}
public int getOwnerId() {
return ownerId;
}
}
Пример "стройной" модели. Но тут сразу встает резонный вопрос, зачем системе 2 класса Pet.
Не хочу сказать что я во всем согласен со статьей и безупречностью "стройной" модели, но это как минимум интересный повод задуматься и обсудить. Вообще статье очень не хватает своего PetStore чтобы показать достоинства "стройной" модели.
Здравствуйте, Воронков Василий, Вы писали:
ВВ> Сложно представить, что код для сохранения в БД не должен содержаться напрямую в методе Save?
Это условие задачи, обусловленное жирностью модели, которую ты защищаешь.
Ты с темы-то не соскакивай...
ВВ>У меня есть "модель", в которой описана реализации сохранения в БД для данной сущности.
Речь не о твоей модели, о твоей — отдельный разговор.
ВВ>Если мне потребуется создания ХМЛ-сериализации я напишу новую модель.
Модель должна быть одна.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Аргумент на самом деле простой — анемичная модель не объектно-ориентирована.
Это не аргумент, это тезис, который требует доказательств. А их что-то пока не видать.
ВВ>Анемичная модель лишает классы поведения.
Не классы, а данные, что правильно.
ВВ> Так как поведение перестает быть частью самого объекта, то этот объект при желании можно наделить поведением, которое изначально не задумывалось для него, которое будет являться неправильным для этого объекта.
А если у класса уже есть какое-то поведение, то при желании его нельзя наделить другим неправильным поведением? Смело.
ВВ> Класс перестает быть полиморфным.
Не класс а данные.
ВВ> Изменение поведения для этого класса предполагает изменение совершенно внешнего по отношению к нему сервиса.
Не для классов, а для данных, что правильно.
ВВ>Наследование перестает быть средством изменения поведения.
Лучше бы его вообще не было (я про наследование реализации).
ВВ>Код, работающий с нашим классом, также перестает быть обощенным.
Вот это ты не угадал. Такой код гораздо более обобщен, чем в жирной модели.
ВВ> Для изменения поведения мне надо или править существующий сервис (в котором содержится код для других классов, а соответственно потенциально влиять и на него) или же создавать новый сервис.
Правильны ответ — создавать новый сервис, в полном следовании OCP.
ВВ>Для того, чтобы решить эту проблему мне придется поднимать совершенно отдельную модель сервисов — с наследованиями, разными реализациями и пр. — которая в итоге придет ровно к тем же проблемам, которые тут так остроумно находят у жирной модели.
Естественно не приведет, так как здесь нет фатального недостатка жирной модели — разделяемого персистентного состояния.
ВВ> "Контракт" для класса теряет свой смысл. В нем описываются только данные — не поведение.
Не для класса, а для данных.
ВВ> Контракт сервиса всегда изыбыточен.
Контракт сервиса оптимален.
ВВ> В идеале мы придем к тому, что на каждый класс у нас будет по сервису.
Нет, в идеале будет код скомпонованый в полном соответствии с принципом функциональной кохессии. Что есть хорошо и правильно.
ВВ>Это так, если касаться вопроса вкратце.
В кратце, ты совершаешь характерную ошибку начинающего ООП-шника, мешая в одну кашу данные и поведение, не отделяя одно от другого.
ВВ> Да, жирная модель — это просто-напросто ОО-модель, анемичная — не ОО-модель, а ООП далеко не лучший инструмент не только в отношении работы с данными.
Открою тебе секрет — стройная модель, более ОО, чем жирная. Стройная модель больше соответствует основным принципам ОО дизайна.
ВВ>Да, в ОО-модели класс должен быть наделен поведением, а не представлять собой пустой набор геттеров и сеттеров.
Это заблуждение..
ВВ>Какой смысл описывать откровенное убогое построение жирной модели — фактически доведенное до абсурда — и показывать, что это видите ли именно то, что жирная модель предполагает?
Это самое что ни на есть типичное и классическое представление жирной модели.
Мы уже победили, просто это еще не так заметно...
) получить от вас какие-то детали возражений. Он очевидно не хочет рассыпаться в объяснениях, почему он считает выделенное правильным. Но если вы пытаетесь от него чего-то добиться — почему бы вам не привести больше деталей в своих рассуждениях, почему вы не согласны с выделенным.
