Вот отсюда — en.wikipedia.org/wiki/Cohesion_(computer_science)#High_cohesion — можно заключить, что cohesion — это мера того, насколько связаны функциональности, заключённые в одном модуле, и она в общем не связана с тем, по скольким классам или модулям эта функциональность размазана.
«Из переписки Энегельса с Каутским»;-) В том посе Фаулер предложил этот термин в ответ на вопзрос именно по тематике связанной с .NET в противовес термину POCO — .NET-овской кальке с POJO.
Cohesion и Coupling — это термины, в которых описыватся картинки, видимые с разных сторон — responsibilities и архитектуры. Low cohesion — это всегда tight coupling.
Persistence ignorance (видимо, это .NET-специфичный термин, в Java я его не встречал) — это хорошая и правильная вещь.
Вообще-то, это термин из архитектуры.
Погуглил. В википедии его нет, в интеренте встречается только в текстах про .NET и связанных с ним платформах. Похоже, что это — специально изобретённый Микрософтом велосипед. Брендинг и нейминг — тоже важные вещи.
В пользу FBAccount и VKAccount гоорит в основном то, что в экземпляре можно хранить сырой REST-ответ и не запрашивать сервер лишний раз.
Фукнциональность, если она общая и есть у всех, можно вынести в сервисы, а в аккаунте оставить только ссылку на соцсеть, по которой и подключать эту фукнциональность.
Persistence ignorance (видимо, это .NET-специфичный термин, в Java я его не встречал) — это хорошая и правильная вещь.
1) борьба с tight coupling-ом, в этом случае борьба в виде «принципа единственной ответственности» — не грузить класс доменной сущности доп.функцией «дешифровки» REST-ответов.
2) если у API выйдет новая версия, то ещё один класс «дешифратора» будет смотреться лучше, чем ещё один класс доменной сущности для той же социальной сети. А если ещё ввели явное или неявное или архитектурное ограничение, что у одной социальной сети может быть только один класс социального аккаунта, то такое внешнее нововведение вообще поломает архитектуру пирложения.
Ну а сервис разве не еще одна вариация на тему менеджеров?
Да, ещё одна. В современном стандартном дизайне web-приложений с ORM менеджеров аж три слоя: DAO, сервис и контроллер. С какой-то долей обобщения можно сказать, что вся ответственность — в контроллере, хотя он в основном только дёргает сервисы.
Перевод денег и обращение к DAO для сохранения будет в сервисе (как и управление транзакциями), сохранение — в самом DAO, а коммит транзакции — вообще в контейнере. Правда, иногда ещё и все методы из DAO дублируют в сервисе… тогда получается, что при проектировании web-приложений с ORM SR-принцип нарушается почти всегда, и это такой стандарт.
ООП — это, как к сегодняшнему моменту выяснилось, прежде всего полезная технология оптимальной организации кода, позволяющий в одно лицо менеджить в десять-сто (за счёт сторонних open-source библиотек) раз бОльшую функциональность и быстрее «въезжать» в чужой код. А описание каких-то там объектов реального мира и их взаимоотношений — это, как мне тут объяснили, лирика и процентов 5 от общего объёма.
Если нужно х86, можно сделать VNC с не-х86 через WiFi на промышленный комп (матплата размером с 2,5" HDD) без клавы и монитора.
А Maemo — классная платформа, до сих пор считаю N770 (у которого сдохла область на тачскрине) лучшим карманным компьютером, который у меня был…
Фукнциональность, если она общая и есть у всех, можно вынести в сервисы, а в аккаунте оставить только ссылку на соцсеть, по которой и подключать эту фукнциональность.
Persistence ignorance (видимо, это .NET-специфичный термин, в Java я его не встречал) — это хорошая и правильная вещь.
2) если у API выйдет новая версия, то ещё один класс «дешифратора» будет смотреться лучше, чем ещё один класс доменной сущности для той же социальной сети. А если ещё ввели явное или неявное или архитектурное ограничение, что у одной социальной сети может быть только один класс социального аккаунта, то такое внешнее нововведение вообще поломает архитектуру пирложения.