Связность BL и DAL слоёв - Архитектура программного обеспечения

Доброго всем времени суток!

Мучает меня последнее время вопрос... прям спать не могу

. Решил поделиться с общественностью — что б тоже сон потеряла.

Итак, что такое многоуровневая архитектура? В моём понимании это такое построение приложения, при котором оно состоит из нескольких слоёв, причём слои верхнего уровня используют слои нижнего, но не наоборот. Классический пример:
Presentation(UI)->Business Logic(BL)->Data Access Layer(DAL)->Storage(DB)

Постулат такой: любые вызовы из нижлежащего слоя к вышестоящему недопустимы. За редким исключением (например callback-и) которых следует таки избегать.
Почему? Достоинство я вижу на самом деле только одно: уменьшается связность. А следствий может быть очень много, как то упрощение юнит-тестирования, повышение потенциальной масштабируемости вширь, и т.п.

В описаном примере думаю очевидным будет тот факт, что вызовы к UI из BL и тем более из DAL — признок дурно пахнущей архитектуры.
(Конечно из всех правил есть исключения, но речь не о них.)

Собственно это была приcказка. Сама же сказка такая:
Реализуем BL на основе Domain Model. Т.е. бизнес логика приложения содержится в классах, которые являются отражением предметной области. Классы содержат данные и логику работы с ними (инкапсуляция блин, кудаж без неё!).
Реализуем DAL на основе Data Mapper. Собственно слой предоставляющий интерфейс для работы с хранилищем на основе обектно-ориентированой модели.

И вот что не даёт мне спать по ночам: DAL связан с BL, поскольку выполняет создание экземпляров классов из Domain Model и их инициализацию данными из DB. Налицо вопиющее нарушение "слойности" архитектуры. Анархия. Разруха. Полный капец.

Читал Фаулера. Этот "нехороший человек" обошёл проблемму стороной упомянув что "однозначно хорошего решения не существует".

Собственно какие способы вижу я:
1. Отделение BL от данных и выделение отдельной группы объектов-data-контейнеров. Где же тогда инкапсуляция? Правильно — в Ж.
2. Выделение интерфейсов для Data Mapper и их реализация в классах BL. Но здесь всё равно остаётся проблемма создания экземпляров. Можно разрулить каким-нибудь порождающим паттерном, фабрикой к примеру или даже заюзать IoC engine, reflection в конце концов. Но не все фреймворки реализующие Data Mapper такое позволяют.

Есть у уважаемого сообщества идеи ЕДИНСТВЕННО ПРАВИЛЬНОЙ БОЖЕСТВЕННОЙ АРХИТЕКТУРЫ?

PS Если заюзать на BL Transaction Script к примеру, проблемма исчезает сама собой. Но тот же Фаулер Transaction Script ругает...
PPS Всё вышесказанное есть моё глубокое ИМХО. Если вы считаете иначе — отлично, поделитесь мнением!

3) Оставить знание DAL о классах предметной области. Это нормально.

Здравствуйте, server_mouse, Вы писали:

_>Доброго всем времени суток!

_>Мучает меня последнее время вопрос... прям спать не могу

. Решил поделиться с общественностью — что б тоже сон потеряла.

_>Итак, что такое многоуровневая архитектура? В моём понимании это такое построение приложения, при котором оно состоит из нескольких слоёв, причём слои верхнего уровня используют слои нижнего, но не наоборот. Классический пример:
_>Presentation(UI)->Business Logic(BL)->Data Access Layer(DAL)->Storage(DB)
На самом деле такая кратина неполная.
Есть еще Cross-Cunnting Concerns, а еще есть данные, которыми обмениваются слои, которые тоже ортогональны слоям.

_>Собственно это была приcказка. Сама же сказка такая:
_>Реализуем BL на основе Domain Model. Т.е. бизнес логика приложения содержится в классах, которые являются отражением предметной области. Классы содержат данные и логику работы с ними (инкапсуляция блин, кудаж без неё!).
_>Реализуем DAL на основе Data Mapper. Собственно слой предоставляющий интерфейс для работы с хранилищем на основе обектно-ориентированой модели.

_>И вот что не даёт мне спать по ночам: DAL связан с BL, поскольку выполняет создание экземпляров классов из Domain Model и их инициализацию данными из DB. Налицо вопиющее нарушение "слойности" архитектуры. Анархия. Разруха. Полный капец.

Именно так и получается. Потому что Domain Model прибивает BL к данным. Единственный способ убрать такую проблему в Domail Model — ввести DTO для обмена данными между слоями.
Короче костыли.

_>Читал Фаулера. Этот "нехороший человек" обошёл проблемму стороной упомянув что "однозначно хорошего решения не существует".
Этот нехороший человек много скользких момнетов обходит стороной. Не стоит на веру принимать все что они пишет.

_>Собственно какие способы вижу я:
_>1. Отделение BL от данных и выделение отдельной группы объектов-data-контейнеров. Где же тогда инкапсуляция? Правильно — в Ж.
Это правильное решение. Инкапсуляция ради инкапсуляции не нужна. То что объекты данных занимаются только переносом данных — это правильно.

_>2. Выделение интерфейсов для Data Mapper и их реализация в классах BL. Но здесь всё равно остаётся проблемма создания экземпляров. Можно разрулить каким-нибудь порождающим паттерном, фабрикой к примеру или даже заюзать IoC engine, reflection в конце концов. Но не все фреймворки реализующие Data Mapper такое позволяют.
Вот поэтому domain model сосет.

_>Есть у уважаемого сообщества идеи ЕДИНСТВЕННО ПРАВИЛЬНОЙ БОЖЕСТВЕННОЙ АРХИТЕКТУРЫ?
Ага. Написал в блоге пост-введение к этому вопросу http://gandjustas.blogspot.com/2009/03/blog-post.html.
Как будет время сделаю что-то типа "набросков правильной архитектуры".

_>PS Если заюзать на BL Transaction Script к примеру, проблемма исчезает сама собой. Но тот же Фаулер Transaction Script ругает...
Фаулер нигде сам Transaction Script не ругает, ругает абсолютно идиотскую реализацию в виде паттерна Command, и говорит что это "не ООП".
Хотя он много на что так говорит.

Я имел в виду что исключить логику (действия) из классов предметной области. BLL будет выглядеть в виде сервисов, работающих над классами предметной области и организующих необходимую логику. и DAL и BLL и UI будут знать о классах предметной области, т.е. классы предметной области составляют отдельную группу, доступную на всех уровнях.

Здравствуйте, MozgC, Вы писали:

MC>Я имел в виду что исключить логику (действия) из классов предметной области. BLL будет выглядеть в виде сервисов, работающих над классами предметной области и организующих необходимую логику. и DAL и BLL и UI будут знать о классах предметной области, т.е. классы предметной области составляют отдельную группу, доступную на всех уровнях.

Собственно получается тот же самый Transaction Script просто в виде набора сервисов, верно? А классы предметной области — data-контейнеры?
По поводу видимости классов предметной области на UI — иногда не удобно. Зачастую UI-ю нужны комбинированые объекты или какае-то, обычно простая, логика преобразования. Типа такого:

class Person
{
private string firstName;
private string lastName;

public string FullName
{
 get{ return firstName+" ,"+lastName;}
}
}

Пихать её в UI не удобно, получишь копи-паст. Оставлять в Domain (в виду того, что логики там уже нет) — не логично.

Логичнее было бы оставить такие Domain-объекты на уровне DAL, а на BLL сделать свои, удовлетворяющие потребностям UI (и бизнес-логику формирования FullName оставить таким образом бизнес-логике). Есть только одно но

— как удобно это реализовать не знаю. Удобно, это когда программисту не нужно делать вручную врапперы над domain-объектами.

Здравствуйте, server_mouse, Вы писали:

_>Здравствуйте, MozgC, Вы писали:

MC>>Я имел в виду что исключить логику (действия) из классов предметной области. BLL будет выглядеть в виде сервисов, работающих над классами предметной области и организующих необходимую логику. и DAL и BLL и UI будут знать о классах предметной области, т.е. классы предметной области составляют отдельную группу, доступную на всех уровнях.

_>Собственно получается тот же самый Transaction Script просто в виде набора сервисов, верно?
Да.

_>А классы предметной области — data-контейнеры?
Это уже как вам угодно. Некоторые наследуют бизнес-объекты от общего предка, которые реализует интерфейсы для транзакционного редактировния (undo), оповещения об изменениях, отслеживания статуса объекта (сохранен или нет) (в .NET это интерфейсы IEditableObject, INotifyPropertyChanged, IChangeTracking). Хорошо это или нет — отдельная тема для больших споров.

_>По поводу видимости классов предметной области на UI — иногда не удобно. Зачастую UI-ю нужны комбинированые объекты или какае-то, обычно простая, логика преобразования. Типа такого:
_>

_>class Person
_>{
_>private string firstName;
_>private string lastName;

_>public string FullName
_>{
_> get{ return firstName+" ,"+lastName;}
_>}
_>}
_>

_>Пихать её в UI не удобно, получишь копи-паст. Оставлять в Domain (в виду того, что логики там уже нет) — не логично.

Лично я бы не заморачивался, и оставил FullName в классе Person.

_>Логичнее было бы оставить такие Domain-объекты на уровне DAL, а на BLL сделать свои, удовлетворяющие потребностям UI (и бизнес-логику формирования FullName оставить таким образом бизнес-логике). Есть только одно но

— как удобно это реализовать не знаю. Удобно, это когда программисту не нужно делать вручную врапперы над domain-объектами.

Тут надо найти для себя грань между хорошим/правильным дизайном и слишком большими заморочками.

Здравствуйте, server_mouse, Вы писали:

_>Есть у уважаемого сообщества идеи ЕДИНСТВЕННО ПРАВИЛЬНОЙ БОЖЕСТВЕННОЙ АРХИТЕКТУРЫ?

Здесь это называется Business Entities. Используется всеми слоями приложения.

Здравствуйте, IT, Вы писали:

IT>Здесь это называется Business Entities. Используется всеми слоями приложения.

Надо бы пояснить. Либо статьей в RSDN (в идеале), либо ссылками.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Gadsky, Вы писали:

IT>>Здесь это называется Business Entities. Используется всеми слоями приложения.

G>Надо бы пояснить. Либо статьей в RSDN (в идеале), либо ссылками.

http://www.rsdn.ru/Forum/message/2097068.1.aspx

Здравствуйте, server_mouse, Вы писали:

_>И вот что не даёт мне спать по ночам: DAL связан с BL, поскольку выполняет создание экземпляров классов из Domain Model и их инициализацию данными из DB. Налицо вопиющее нарушение "слойности" архитектуры. Анархия. Разруха. Полный капец.

Фишка вот в чем. Твои бизнес объекты включают в себя сразу 2 слоя. Это слой BL и слой который я называю контрактным. Это даже не слой, а формат обмена данными между слоями, на него неизбежно завязаны все или почти всем слои приложения. Если DAL использует только контрактную часть бизнес объектов (а ему по сути больше и не требуется) и не вызывает методов бизнес логики которые торчат из них же — проблемы нет: BL отдельно, DAL отдельно.

Смешение контракта и логики довольно серьезный недостаток жирной модели, но не настолько фатальный чтобы отказываться от нее только поэтому. Спи спокойно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>

Здравствуйте, server_mouse, Вы писали:

_>Доброго всем времени суток!

_>И вот что не даёт мне спать по ночам: DAL связан с BL, поскольку выполняет создание экземпляров классов из Domain Model и их инициализацию данными из DB. Налицо вопиющее нарушение "слойности" архитектуры. Анархия. Разруха. Полный капец.

1) Сейчас все чаще уходят от традиционных слоев. Например посмотите The Onion Architecture, если коротко то DAL там не рассматриваеться как отдельный слой, он расматриваеться как инфраструктура, типа логирования или конфигурирования. Ну а если принять что это инраструктура, то все становиться на свои места, вас же не удевляет что CLR знает про ваши обьекты?
2) Репозитарии или ДАЛ это абстракции над базой данных, фактически вы их можно расматривать как саму базуданных(точнее как хранилище), соотвевенно логично что ДАЛ знает про сущьности, ведь именно сущности находяться в хранилище.

_>Читал Фаулера. Этот "нехороший человек" обошёл проблемму стороной упомянув что "однозначно хорошего решения не существует".

?? Ссылочку если можно. Обычно у Фаулера идет "однозначно хорошого решения не существует для всех ситуаций". Это правда, если был силвербулет все бы им пользовались.

_>Собственно какие способы вижу я:
_>1. Отделение BL от данных и выделение отдельной группы объектов-data-контейнеров. Где же тогда инкапсуляция? Правильно — в Ж.

Есть принцип YAGNI, принципы ради принципов? Щас ОРМ тулзы сводят ДАЛ до декларации типа "хочу репозитарий для типа Юзер"...

_>2. Выделение интерфейсов для Data Mapper и их реализация в классах BL. Но здесь всё равно остаётся проблемма создания экземпляров. Можно разрулить каким-нибудь порождающим паттерном, фабрикой к примеру или даже заюзать IoC engine, reflection в конце концов. Но не все фреймворки реализующие Data Mapper такое позволяют.

Опять же принцип YAGNI, зачем? Вам будет проще от этого отказаться если вы попытаетесь сформулировать зачаем это вам надо. Если получиться попытаться сформулировать а надо ли вам оно щас...

_>Есть у уважаемого сообщества идеи ЕДИНСТВЕННО ПРАВИЛЬНОЙ БОЖЕСТВЕННОЙ АРХИТЕКТУРЫ?

Угу, заюзать ОРМ и забыть про ДАЛ как слой (http://jimmynilsson.com/blog/posts/SomeObservations.htm).

... << RSDN@Home 1.2.0 alpha 4 rev. 1213>>

Здравствуйте, server_mouse, Вы писали:

_>Т.е. бизнес логика приложения содержится в классах, которые являются отражением предметной области. Классы содержат данные и логику работы с ними (инкапсуляция блин, кудаж без неё!).
Это не инкапсуляция, а скорее наоборот.

_>1. Отделение BL от данных и выделение отдельной группы объектов-data-контейнеров. Где же тогда инкапсуляция? Правильно — в Ж.
А в данном случае, с инкапсуляцией все в порядке.

... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>

Здравствуйте, MozgC, Вы писали:

MC>Я имел в виду что исключить логику (действия) из классов предметной области. BLL будет выглядеть в виде сервисов, работающих над классами предметной области и организующих необходимую логику. и DAL и BLL и UI будут знать о классах предметной области, т.е. классы предметной области составляют отдельную группу, доступную на всех уровнях.

В чистом виде такой подход ИМХО несостоятелен. Существует масса мелких "алгоритмиков" (типа счётчика ссылок в A->setB(B)), которые ты либо пихаешь внутрь объектов модели, либо вынужден дублировать этот код во всех сервисах BLL.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, server_mouse, Вы писали:

_>>Т.е. бизнес логика приложения содержится в классах, которые являются отражением предметной области. Классы содержат данные и логику работы с ними (инкапсуляция блин, кудаж без неё!).
IB>Это не инкапсуляция, а скорее наоборот.

По-моему, вы двое говорите о разной инкапсуляции.

Я повторю свой пример: есть метод A->setB(B) и поле B::countAs. Корректировка второго из первого — это ИМХО оправданная инкапсуляция логики (в данном случае тривиальной), поскольку в противном случае об этом счётчике придётся помнить всюду, где используется первый метод.

Скажем так, я склонен вгонять в entities ту логику, которая (при наличии желания) также естественно могла бы лечь в триггеры базы.

_>>1. Отделение BL от данных и выделение отдельной группы объектов-data-контейнеров. Где же тогда инкапсуляция? Правильно — в Ж.
IB>А в данном случае, с инкапсуляцией все в порядке.

Бояре сумлеваются. Редуцировать entities до структур... я лучше уж DTO добавлю (в качестве базовых классов entities).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Я повторю свой пример: есть метод A->setB(B) и поле B::countAs. Корректировка второго из первого — это ИМХО оправданная инкапсуляция логики (в данном случае тривиальной), поскольку в противном случае об этом счётчике придётся помнить всюду, где используется первый метод.

Неправильные у вас пчелы. Вот этот B::countAs, как и упомянутые счетчики, никакого, я подозреваю, отношения к предметной логике не имеют, а являются неким инфраструктурным моментом, болтающимся под ногами и отвлекающим от основного занятия. Так что пример несколько некорректный.

D>Скажем так, я склонен вгонять в entities ту логику, которая (при наличии желания) также естественно могла бы лечь в триггеры базы.

Какие-то триггеры появились уже. С таким критерием, кстати, все еще хуже: эти самые entities начинают вмешиваться в дела, соверщенно к ним не относящиеся, как то сохранение в БД, ведение аудита (это я гадаю на кофейной гуще; триггеры же для этого собрались использовать?), обновление каких-то полей. Это, по-вашему, правильная "инкапсуляция"? По-моему, это повышение связности на ровном месте и усложнение себе жизни.

D>Бояре сумлеваются. Редуцировать entities до структур... я лучше уж DTO добавлю (в качестве базовых классов entities).

А альтернатива какая? Монстроподобные объекты с кучей логики, не умеющие разве что кофе варить? Тоже плохо. Объекты с неким вменяемым объемом логики? А где проходит эта граница "вменяемости" и какими критериями (по возможности наименее противоречивыми и субъективными) стоит руководствоваться для решение, куда какую логику помещать?

Здравствуйте, Нахлобуч,

Сдаётся мне, что меня также неправильно поняли.

D>>Я повторю свой пример: есть метод A->setB(B) и поле B::countAs.

Н>Неправильные у вас пчелы. Вот этот B::countAs, как и упомянутые счетчики, никакого, я подозреваю, отношения к предметной логике не имеют, а являются неким инфраструктурным моментом, болтающимся под ногами и отвлекающим от основного занятия. Так что пример несколько некорректный.

Тем не менее, это исполняемый код. Помню я давнишний спор IT с adontz-ом, в котором IT отстаивал entities как просто структуры без поведения, благодаря чему он получал возможность пользоваться этими entities на всех слоях, в т.ч. передавать их по сети в качестве DTO. (Одним из основных его аргументов было нежелание возиться с параллельной структурой DTO.) Adontz, напротив, отстаивал "умные объекты", из которых автоматически следовала необходимость DTO.

Так вот, инфраструктурный момент это или бизнес-логика, неважно. Это код. Наличие которого в entities означает автоматическую невозможность (или сильную усложнённость, как минимум) использования этих entities в качестве DTO. Если ты согласен с тем, что инкремент счётчика ссылок B::countAs можно размещать в A::setB(B), то считай, что ты уже в лагере adontz-а, сознательно или нет. Сам я в его лагере совершенно сознательно.

Я тут приведу дальнюю аналогию: мнение Стива Круга относительного максимального числа кликов (переходов по ссылкам) при поиске страницы на сайте. Он говорит, что неважно сколько кликов, до тех пор, пока каждый клик очевиден, т.е. очевидным образом приближает нас к цели. Аналогия тут с избыточным кодом DTO. Вот между (1) необходимостью создавать параллельную иерархию DTO и методы toDTO и fromDTO в каждом классе entity, (2) необходимости выносить "инфраструктурные моменты" в BLL, я выберу первое. Оно и удобнее, и гибче, хоть и объёмнее и тормознее. Пример насчёт гибкости: был у одного сайтика swing-клиент, из-под которого могли логиниться и админы, и обычные юзеры. Юзверям отдавались урезанные DTO, не содержащие чувствительной информации. Админам — полные. Вторые наследовались из первых; методы выглядели как toDTO(Class).

D>>Бояре сумлеваются. Редуцировать entities до структур... я лучше уж DTO добавлю (в качестве базовых классов entities).

Н>А альтернатива какая? Монстроподобные объекты с кучей логики, не умеющие разве что кофе варить? Тоже плохо.

Согласен, безусловно.

Н>Объекты с неким вменяемым объемом логики? А где проходит эта граница "вменяемости" и какими критериями (по возможности наименее противоречивыми и субъективными) стоит руководствоваться для решение, куда какую логику помещать?

В общем случае это вопрос открытый, но некий пример был, кажется, в "Архитектуре" Фаулера: отправка уведомлений на мыло при изменении базы выполнялся внешним слоем (Service Layer это был, кажется). Идея в том, что это внешняя вещь к логике взаимодействия объектов системы.

Сам я привык руководствоваться следующим правилом: если изменение состояния объекта базы (entity) ведёт к необходимости каскадных изменений состояний других объектов (как в примере со счётчиком ссылок), код, выполняющий эти изменения, я вгоняю внутрь entity. В результате entities у меня, так сказать, сами следят за логической целостностью базы. Любые другие эффекты, не относящиеся к модификации состояния базы, я выношу в контроллеры.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

В сабже вообще фокус с использованием entities в качестве DTO не прокатит. Я ещё не разобрался толком, как оно работает, но POJO там и не пахнет:

class ToDo extends LongKeyedMapper[ToDo] with IdPK {
    def getSingleton = ToDo
    
    object done extends MappedBoolean(this)

    object owner extends MappedLongForeignKey(this, User)

    object priority extends MappedInt(this) {
        override def defaultValue = 5
  
        // TODO Throws an exception on non-numeric value!!!
        override def validations = validPriority _ :: super.validations
  
        def validPriority(in: Int): List[FieldError] =
            if (in > 0 && in <= 10) Nil
            else List(FieldError(this, <b>Priority must be 1-10</b>))
        
        override def _toForm = 
            Full(select(ToDo.priorityList, Full(is.toString), f => set(f.toInt)))
    }

    object desc extends MappedPoliteString(this, 128) {
        override def validations =
            valMinLen(3, "Description must be at least 3 characters") _ :: 
            super.validations
    }
}

object ToDo extends ToDo with LongKeyedMetaMapper[ToDo] {
    lazy val priorityList = 
        ("AAA", "AAA") :: 
        (1 to 10).map(v => (v.toString, v.toString)).toList
}

Это пример из "Getting started with Lift" pdf. Как бы дико он не выглядел, эта фигня не привязана к существующим non-scala frameworks и позволяет на полную использовать возможности языка, в частности mixins (в примере это IdPK). Что меня безумно радует: у меня тут отдельные миксины для поведения TreeNode, Deletable (флаг deleted/scheduled for deletion, связанный со счётчиками ссылок на данный объект), Filtered (для отношений master/slave) и прочего; каждый mixin содержит объявления своих полей базы. И я их все могу впендюрить в один и тот же entity class.

И тут, как видите, изрядная прорва логики валидации и представления вшита в entity. Дико? Ну и идите в пень.

Зато удобно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Так вот, инфраструктурный момент это или бизнес-логика, неважно. Это код. Наличие которого в entities означает автоматическую невозможность (или сильную усложнённость, как минимум) использования этих entities в качестве DTO. Если ты согласен с тем, что инкремент счётчика ссылок B::countAs можно размещать в A::setB(B), то считай, что ты уже в лагере adontz-а, сознательно или нет. Сам я в его лагере совершенно сознательно.
Ты на С++ пишешь чтоли? Там уже давно shared_ptr для посчета ссылок придумалию

D>Я тут приведу дальнюю аналогию: мнение Стива Круга относительного максимального числа кликов (переходов по ссылкам) при поиске страницы на сайте. Он говорит, что неважно сколько кликов, до тех пор, пока каждый клик очевиден, т.е. очевидным образом приближает нас к цели. Аналогия тут с избыточным кодом DTO. Вот между (1) необходимостью создавать параллельную иерархию DTO и методы toDTO и fromDTO в каждом классе entity, (2) необходимости выносить "инфраструктурные моменты" в BLL, я выберу первое. Оно и удобнее, и гибче, хоть и объёмнее и тормознее.
Это полнейший бред.
Все что ты описал сильно снижает mantainability, один и теже изменения делать в разных местах одинаково хреново независимо от того очевидно это или нет.
Есдиственная случай когда дублирование оправдано — автогенерный код, и то не всегда.

Н>>Объекты с неким вменяемым объемом логики? А где проходит эта граница "вменяемости" и какими критериями (по возможности наименее противоречивыми и субъективными) стоит руководствоваться для решение, куда какую логику помещать?
D>В общем случае это вопрос открытый, но некий пример был, кажется, в "Архитектуре" Фаулера: отправка уведомлений на мыло при изменении базы выполнялся внешним слоем (Service Layer это был, кажется). Идея в том, что это внешняя вещь к логике взаимодействия объектов системы.
В общем случае надо отделять всю логику от данных. Тогда будет меньше дублирования и больше повторного использования.

D>Сам я привык руководствоваться следующим правилом: если изменение состояния объекта базы (entity) ведёт к необходимости каскадных изменений состояний других объектов (как в примере со счётчиком ссылок), код, выполняющий эти изменения, я вгоняю внутрь entity. В результате entities у меня, так сказать, сами следят за логической целостностью базы. Любые другие эффекты, не относящиеся к модификации состояния базы, я выношу в контроллеры.
Это чисто инфраструктурная вещь, которая порождена отсуствием GC. В принципе есть shared_ptr для этих целей, но в данных циклические зависимости случаются часто.

Здравствуйте, gandjustas, Вы писали:

G>Ты на С++ пишешь чтоли? Там уже давно shared_ptr для посчета ссылок придумалию

Нет, не на C++. Но есть у меня сомнение, что C++ный shared_ptr можно прикрутить к ORM entities, чтобы он записывал обновлённое значение счётчика ссылок в базу.

G>Это полнейший бред.

Сам дурак.

G>Все что ты описал сильно снижает mantainability, один и теже изменения делать в разных местах одинаково хреново независимо от того очевидно это или нет.

Это очевидно. А теперь изволь изложить, как бы ты реализовал мой пример — когда админам и обычным юзерам (и те и другие коннектятся к сайту из swing-клиента) нужно отдавать одни и те же структуры данных, за исключением чувствительной информации, которую юзерам видеть не полагается.

G>В общем случае надо отделять всю логику от данных. Тогда будет меньше дублирования и больше повторного использования.

То есть, в каждом месте, где выполняется a->setB(b), не забывать добавлять b->countAs++? Да, действительно меньше дублирования.

И очень повышает maintainability.

G>Это чисто инфраструктурная вещь, которая порождена отсуствием GC. В принципе есть shared_ptr для этих целей, но в данных циклические зависимости случаются часто.

Тут, вообще-то, про Фому говорят.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>Ты на С++ пишешь чтоли? Там уже давно shared_ptr для посчета ссылок придумалию
D>Нет, не на C++. Но есть у меня сомнение, что C++ный shared_ptr можно прикрутить к ORM entities, чтобы он записывал обновлённое значение счётчика ссылок в базу.
Зачем счетчик ссылок в базе?

G>>Это полнейший бред.
D>Сам дурак.
Риторика — супер.

G>>Все что ты описал сильно снижает mantainability, один и теже изменения делать в разных местах одинаково хреново независимо от того очевидно это или нет.
D>Это очевидно. А теперь изволь изложить, как бы ты реализовал мой пример — когда админам и обычным юзерам (и те и другие коннектятся к сайту из swing-клиента) нужно отдавать одни и те же структуры данных, за исключением чувствительной информации, которую юзерам видеть не полагается.
Для целей presentation обычно вводятся структуры, отличающиеся от модели данных. В них и будет различие.
Тольео с БЛ это никак не связно.

G>>В общем случае надо отделять всю логику от данных. Тогда будет меньше дублирования и больше повторного использования.
D>То есть, в каждом месте, где выполняется a->setB(b), не забывать добавлять b->countAs++? Да, действительно меньше дублирования.

И очень повышает maintainability.

Приведи адекватное обоснование необходимости таких действий.

Здравствуйте, Нахлобуч, Вы писали:

Н>Вообще говоря, DTO ты упомянул совершенно вскользь, так что непонятно, зачем к этому аппеллировать -- разговор совершеннл не про них.

Разговор вроде бы о допустимости запихивания какой-либо логики в entities?

Н>Уже плохо. Сегодня -- toDTO/fromDTO, завтра -- toJSON/fromJSON, послезавтра -- бардак. Ясных критериев-то нет.

Вот послезавтра и отрефакторим.

Но я тут отстаиваю активные объекты, а не конкретно вопрос, куда пихать метод toDTO.

D>>Сам я привык руководствоваться следующим правилом: если изменение состояния объекта базы (entity) ведёт к необходимости каскадных изменений состояний других объектов (как в примере со счётчиком ссылок),

Н>Ты отвлекись от счетчиков и ссылок -- это тебе твой же инструмент сложности создает.

Счётчики и ссылки — лишь простой пример. Меня удивляет, что вы все к нему привязались. Извольте, вот пример с миксином TreeNode:
1) он добавляет к классу поля parent, numChildren, numDescendants;
2) при добавлении в иерархию он корректирует numChildren своего родителя и numDescendants своих предков;
3) также он синхронизирует данные таблицы замыкания (PK(ancestorid, descendantid), distance).

Выносить всю логику из пунктов (2) и (3) в контроллеры — значит дублировать её во множестве контроллеров для всех entities, являющихся TreeNode. Или делать отдельные методы в helper-классах, что всё равно дико: всё-таки гораздо понятнее и более ожидаемо написать node1.addChild(node2), чем TreeController.addChild(node1, node2). Все вот эти SomethingController, плодящиеся как грибы после дождя, если отказаться от активных entities, дико раздражают.

D>>В результате entities у меня, так сказать, сами следят за логической целостностью базы.
Н>То есть все твои сущности знают о том, как сохранять себя в БД?

Эммм... Как сохранить себя в БД, знают сущности в любом ORM, в том же Hibernate — у всех есть метод save(). Я думаю, мой пример выше разъяснил мою позицию.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, gandjustas, Вы писали:

G>>>Это полнейший бред.
D>>Сам дурак.
G>Риторика — супер.

Сам же и начал.

D>>Это очевидно. А теперь изволь изложить, как бы ты реализовал мой пример — когда админам и обычным юзерам (и те и другие коннектятся к сайту из swing-клиента) нужно отдавать одни и те же структуры данных, за исключением чувствительной информации, которую юзерам видеть не полагается.
G>Для целей presentation обычно вводятся структуры, отличающиеся от модели данных. В них и будет различие.

Эти структуры и являются по сути DTO; неважно, как ты их при этом называешь. Когда я делал сайты, использующие XSLT, промежуточный XML также являлся по сути DTO. И изменения так или иначе приходится делать в разных местах (поменял entity — поменял XSLT).

G>Тольео с БЛ это никак не связно.

Я этого и не утверждал.

D>>То есть, в каждом месте, где выполняется a->setB(b), не забывать добавлять b->countAs++? Да, действительно меньше дублирования.

И очень повышает maintainability.

G>Приведи адекватное обоснование необходимости таких действий.

Не понял вопроса. В таблице b есть счётчик count_as. Нужно держать его в актуальном состоянии. Всё. Какое ещё тебе нужно обоснование? Можешь посмотреть пример посложнее, я только что запостил.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Извольте, вот пример с миксином TreeNode.

По той причине, что миксины того уровня, которого они есть в Scala, мне технически недоступны, я ничего путного сказать не могу. Повторюсь, однако, что я выступаю против помещения логики в бизнес-объекты.

D>Эммм... Как сохранить себя в БД, знают сущности в любом ORM, в том же Hibernate — у всех есть метод save(). Я думаю, мой пример выше разъяснил мою позицию.

А вот и нет. В том же Hibernate метод save() есть у объекта Session, который суть Identity Map и Unit of Work, все сущности знать не знают о том, что где-то вообще есть БД и что их туда сохраняют. Это не их дело.

Здравствуйте, dimgel, Вы писали:

D>Счётчики и ссылки — лишь простой пример. Меня удивляет, что вы все к нему привязались. Извольте, вот пример с миксином TreeNode:
D>1) он добавляет к классу поля parent, numChildren, numDescendants;
D>2) при добавлении в иерархию он корректирует numChildren своего родителя и numDescendants своих предков;
D>3) также он синхронизирует данные таблицы замыкания (PK(ancestorid, descendantid), distance).

D>Выносить всю логику из пунктов (2) и (3) в контроллеры — значит дублировать её во множестве контроллеров для всех entities, являющихся TreeNode. Или делать отдельные методы в helper-классах, что всё равно дико: всё-таки гораздо понятнее и более ожидаемо написать node1.addChild(node2), чем TreeController.addChild(node1, node2). Все вот эти SomethingController, плодящиеся как грибы после дождя, если отказаться от активных entities, дико раздражают.

Странно... Носить все время с собой деревья? Во-первых, схема хранения деревьев в БД может отличаться от схемы хранения в BL. Во-вторых, практически в 90 процентах случаях ноды как деревья не обрабатываются. Списки и объекты как сущности используются значительно чаще.
Вобщем, моё IMHO — пример плохой.

D>Эммм... Как сохранить себя в БД, знают сущности в любом ORM, в том же Hibernate — у всех есть метод save(). Я думаю, мой пример выше разъяснил мою позицию.
Значит ты говоришь об архитектуре, которая должна быть совместима с конкретной ORM. (я ничего не имею против, ибо главное результат

Здравствуйте, Нахлобуч, Вы писали:

Н>Здравствуйте, dimgel, Вы писали:

D>>Извольте, вот пример с миксином TreeNode.

Н>По той причине, что миксины того уровня, которого они есть в Scala, мне технически недоступны, я ничего путного сказать не могу.

Ну типа множественного наследования.

Н>Повторюсь, однако, что я выступаю против помещения логики в бизнес-объекты.

Аргументов пока не вижу.

Забавно, сам я постоянно привожу аргументы "против" (в данном случае — самого IT, посты которого я очччень внимательно прочитал в своё время от самого сотворения RSDN), чтобы привести им контрпримеры. В то же время мои оппоненты до такой мелочи практически никогда не опускаются. Тут не КСВ, товарищи.

Н>А вот и нет. В том же Hibernate метод save() есть у объекта Session, который суть Identity Map и Unit of Work, все сущности знать не знают о том, что где-то вообще есть БД и что их туда сохраняют. Это не их дело.

Да, это я попутал, сам уже вспомнил, что Hibernate работает с POJO. Но то, что я тут защищаю, — тоже не метод save(), внутренняя логика entities у меня может работать только с интерфейсами других entities. (Как в триггеры таблиц — только с данными других таблиц, в этом была моя ранее приведённая аналогия.)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, GlebZ, Вы писали:

GZ>Странно... Носить все время с собой деревья?

Нет, конечно. Они могут быть большие.

В кывте вон самая главная вещь — дерево.

D>>Эммм... Как сохранить себя в БД, знают сущности в любом ORM, в том же Hibernate — у всех есть метод save(). Я думаю, мой пример выше разъяснил мою позицию.
GZ>Значит ты говоришь об архитектуре, которая должна быть совместима с конкретной ORM. (я ничего не имею против, ибо главное результат

).

Эт я попутал, уже написал выше. По возможности я таких привязок стараюсь не делать. Хотя тот факт, что я из одних entities обращаюсь к другим, приводит к ньюансам в реализации. К примеру спрашивал я когда-то на форуме java, как заинжектить session в entity, чтобы обратиться к другому entity по id.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>>>Это очевидно. А теперь изволь изложить, как бы ты реализовал мой пример — когда админам и обычным юзерам (и те и другие коннектятся к сайту из swing-клиента) нужно отдавать одни и те же структуры данных, за исключением чувствительной информации, которую юзерам видеть не полагается.
G>>Для целей presentation обычно вводятся структуры, отличающиеся от модели данных. В них и будет различие.
D>Эти структуры и являются по сути DTO; неважно, как ты их при этом называешь. Когда я делал сайты, использующие XSLT, промежуточный XML также являлся по сути DTO. И изменения так или иначе приходится делать в разных местах (поменял entity — поменял XSLT).
Не являются, в MVVM viewmodel не является DTO хотя и содержит данные, при использовании MVP DTO чаще всего не нужны.
Не всегда presentation структуры является DTO по фаулеру.

D>>>То есть, в каждом месте, где выполняется a->setB(b), не забывать добавлять b->countAs++? Да, действительно меньше дублирования.

И очень повышает maintainability.

G>>Приведи адекватное обоснование необходимости таких действий.

D>Не понял вопроса. В таблице b есть счётчик count_as. Нужно держать его в актуальном состоянии. Всё. Какое ещё тебе нужно обоснование? Можешь посмотреть пример посложнее, я только что запостил.
Если count_as можно посчитать из имеющихся данных, то не нужно оно вообще.

Нарушение нормализации никогда бесплатным не бывает, это не повод делать хреновый дизайн приложения.

Я не понял, зачем нужен счетчик count_as?

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, GlebZ, Вы писали:

GZ>>Странно... Носить все время с собой деревья?

D>Нет, конечно. Они могут быть большие.

Главное чтобы было ООП... как наивно. Интересно сколько еще неокрепших умов повелось на такой развод?

Здравствуйте, gandjustas, Вы писали:

G>Если count_as можно посчитать из имеющихся данных, то не нужно оно вообще.
G>Нарушение нормализации никогда бесплатным не бывает, это не повод делать хреновый дизайн приложения.

Ню-ню. Мы, насяльника, про нормализацию и не слыхивали.

Собственно, я и не сомневался, что щас начнутся съезды с темы. Счётчик нужен, точка. Рассказывать тебе свои задачи я не намерен, но я хорошо посмеюсь, если ты предложишь der Igel-у убрать счётчик постов в форумах RSDN или суммарного количества ответов на сообщение, и расчитывать их динамически, суммируя при каждом запросе.

Ещё один в игноре.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Аргументов пока не вижу.

Да какие тут аргументы.

Одна из самых главных задач, возникающих при разработке ПО (кроме собственно его поставки) -- это борьба с Essential Complexity (EC) и сведение Accidental Complexity (AC) к минимуму. Поскольку EC присуща задаче как таковая и никуда от нее не деться, единственный способ "борьбы" с ней -- ее перемещение и растаскивание по уровням абстракции. Для того, чтобы с этими абстракциями было удобно работать и чтобы они не привносили ненужной AC, необходимо уменшьать связность и увеличивать сцепления (Coupling и Cohesion соответственно; возможно, перевод не самый очевидный). Чтобы этого достичь необходимо, как минимум, соблюдать 5 принципов, объединенных аббревиатурой SOLID:

Single responsibility principle
Open/closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle

Твой подход с помещением логики в бизнес-объекты нарушает как минимум пункты S и I.

Резюмирую: плюсы пропагандируемого мною подхода в том, что снижается сложность и уменьшается связность.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>Если count_as можно посчитать из имеющихся данных, то не нужно оно вообще.
G>>Нарушение нормализации никогда бесплатным не бывает, это не повод делать хреновый дизайн приложения.

D>Ню-ню. Мы, насяльника, про нормализацию и не слыхивали.

D>Собственно, я и не сомневался, что щас начнутся съезды с темы. Счётчик нужен, точка.
Молодец сам себе придумал проблемы, а потом придумываешь супер-мега архитектурные решения чтобы проблемы побороть.

D>Рассказывать тебе свои задачи я не намерен, но я хорошо посмеюсь, если ты предложишь der Igel-у убрать счётчик постов в форумах RSDN или суммарного количества ответов на сообщение, и расчитывать их динамически, суммируя при каждом запросе.
Пусть расчет будет в триггерах БД, совершенно не нужно это делать в программе.

Здравствуйте, Нахлобуч, Вы писали:

Н>

Н>

Single responsibility principle
Н>

Interface segregation principle
Н>

Н>Твой подход с помещением логики в бизнес-объекты нарушает как минимум пункты S и I.

Насчёт S — возможно, хотя зависит от трактовки. То, что сеть объектов сама следит за собственной логической целостностью... Ну, во-первых, так и foreign keys в базе данных можно притянуть как нарушение этого принципа. Мол база должна хранить объекты и точка. А в базе, кроме этого, дохрена ещё всякого, включая триггеры, которые я не жалую, но без которых частенько никуда, если доходит до оптимизаций. Не навернутся ли случаем все эти principles разом при первом же шаге в сторону, если так отчаянно им следовать?

Насчёт I — не понял, где я тут его нарушаю. Скорее наоборот, я упрощаю интерфейсы и минимизирую код контроллеров-прокладок. Вместо SomeController::doOn(SomeEntity _this), я тупо делаю SomeEntity::do(). Уменьшаю лишние сущности, про которые ещё и забыть можно (если не использовать package visibility, чтобы отдельные методы entity можно было вызвать только из контроллера; но это как-то не очень попахивает).

Н>Резюмирую: плюсы пропагандируемого мною подхода в том, что снижается сложность и уменьшается связность.

Пока что это одни слова. Громкие слова, хорошо известные, но без примеров. Я повторю в третий (или четвёртый?) раз свой пример со счётчиком ссылок: где тут снижение сложности и уменьшение связности, если вместо a.setB(b) нужно каждый раз писать { a.setB(b); b.countAs++; } либо abController.aSetB(a, b), м? С деревом (реальным примером) будет дерьмовее в разы — там больше операций и как следствие — больше букаф и больше шансов что-нибудь забыть.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Нахлобуч, Вы писали:

Небольшой съезд в сторону:
Н>Сегодня -- toDTO/fromDTO,
Mass Transit

Н>завтра -- toJSON/fromJSON
http://james.newtonking.com/projects/json-net.aspx

Н>послезавтра -- бардак. Ясных критериев-то нет.
Еще чё придумаем

P.S. Это все для .net

Здравствуйте, dimgel, Вы писали:

D>Нет, конечно. Они могут быть большие.

Но если вообще отвязаться от факта наличия ORM, логика TreeNode.addChild(x) должна делать именно это — пройтись по своим предкам и увеличить numDescendants, а у себя увеличить numChildren и numDescendants. Так что некий минимум в памяти всё равно будет.
Но к примеру, перенос веток удобнее делать SQL запросом в БД, а не в оперативной памяти за которым следует лавинообразный update. Вынесенная логика вполне может это обеспечить.

GZ>>Во-первых, схема хранения деревьев в БД может отличаться от схемы хранения в BL.
D>С этим не сталкивался.
Например, документы могут быть провязаны несколькими независимыми деревьями рубрик. И уже непонятно, документы — часть рубрики, или рубрики — часть документа.

D>Но если речь идёт о чём-то в духе паттернов Domain Model + Data Mapper, то как раз в этом случае сам бог велел не замыкаться на разделении данных и логики, а сделать нормальную ООП-систему с инкапсуляцией.
Для чего это все надо... Все эти разделения...
Немного теории. Что такое программа. Это трансформация входных данных, в выходные. Только слишком сложно записать сложную программу со многими состояниями в одну трансформацию. Поэтому ее разделяют на компоненты. Компоненты — это те же подпрограммы которые трансформируют входные данные в выходные. Для правильного распределения функций в компоненте, существует понятия Low coupling и HighCohesion. В свою очередь, дабы упорядочить, мы разделяем компоненты на слои. Слой — это набор однотипных программ(компонентов), подчиненных одной концепции, и изолирующие одни компоненты от других. Все ради борьбы со сложностью.
Если мы посмотрим на общение между слоями то он описывается контрактом, который состоит из данных (параметризуемых или entity в том или ином виде), и собственно рычага который мы должны дернуть, чтобы это все зафурычило. Теоретически, каждый слой заказывает данные в формате прошлого слоя, трансформирует, и отдает в формате нужных для следующего слоя. На практике, такая классика — избыточна. Во первых, борьба со сложностью вызывает избыточное кодирование. Во вторых, существуют продукты, которые почти декларативно решают проблему хранения состояния (то бишь ORM). То есть выполняют роль слоя DAL. В случае, если состояние почти освобождено от логики(почти, потому что даже типизация также реализация логики), мы состояние чаще можем проносить в неизменном виде практически через все слои. Прозрачно сериализовать и т.д. В случае если у нас навешана логика на состояние — то у нас меньше шансов перенести объект между слоями. И тут есть вопрос, которые почему-то обходят. Вопрос инструментария. В случае если используется ORM типа Hibernate — провоцируется создание полновесных объектов в стиле OOP. Технологически, в данной ORM все для этого присутсвует. Мы вполне можем реализовать сколь угодно сложную логику в BLL, и все недостатки хранения(а это процесс наиболее сложный и дорогой) решить инструментарием ORM. Он не завязан на BLL компоненты, благо реализуется другими средствами. А наверх из BLL уже выдавливать специализированные DTO. В случае если подобная ORM не используется, то значительно проще использовать entity без логики. Так как в DAL(который строится другими средствами), мы вполне можем их обработать не связываясь с уровнем BLL, и варьировать эффективность получения/сохранения из/в БД.

GZ>>Во-вторых, практически в 90 процентах случаях ноды как деревья не обрабатываются. Списки и объекты как сущности используются значительно чаще.
D>Вот этого не понял. Небольшие деревья (например, категории чего-либо) частенько выводятся целиком. Если речь идёт о списке детей конкретного узла, дык никто не заставляет загружать всё остальное.
Выводятся и обрабатываются как список. Типо дай мне детей независимо от уровня вложенности с фильтром таким-то.

GZ>>Вобщем, моё IMHO — пример плохой.
D>Жизненный пример плохим быть не может.

В кывте вон самая главная вещь — дерево.
Не думаю что оно реализовано именно так.

Здравствуйте, dimgel, Вы писали:

D>То, что сеть объектов сама следит за собственной логической целостностью... Ну, во-первых, так и foreign keys в базе данных можно притянуть как нарушение этого принципа. Мол база должна хранить объекты и точка.

Чтобы сеть могла следить за логической целостностью в общем случае она может вырасти до размеров БД. Мы до сих пор говорим об оптимизации?

... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>

Здравствуйте, dimgel, Вы писали:

D>Ну, во-первых, так и foreign keys в базе данных [...] если доходит до оптимизаций.

Куда это тебя понесло?

D>Не навернутся ли случаем все эти principles разом при первом же шаге в сторону, если так отчаянно им следовать?

Смотря что ты подразумеваешь под "навернуться". Если ими руководствоваться, то ничего плохого не случится, а если какой-то случай объективно требует специального неуставного решения -- так тому и быть.

D>Насчёт I — не понял, где я тут его нарушаю. Скорее наоборот, я упрощаю интерфейсы и минимизирую код контроллеров-прокладок. Вместо SomeController::doOn(SomeEntity _this), я тупо делаю SomeEntity::do(). Уменьшаю лишние сущности, про которые ещё и забыть можно (если не использовать package visibility, чтобы отдельные методы entity можно было вызвать только из контроллера; но это как-то не очень попахивает).

Interface Segregation -- это "клиенты не должны зависеть от контрактов, которые они не используют". Контракты должны обладать максимальной степенью сцепления. В твоем случае получив SomeEntity пред глазами возникает ажно целый ворох методов, от do() до save().

D>где тут снижение сложности и уменьшение связности, если вместо a.setB(b) нужно каждый раз писать { a.setB(b); b.countAs++; } либо abController.aSetB(a, b), м?

Коль скоро далее следует "реальный пример", я могу полагать, что этот пример -- нереальный. Так что о нем не будем.

D>С деревом (реальным примером) будет дерьмовее в разы — там больше операций и как следствие — больше букаф и больше шансов что-нибудь забыть.

Сферические деревья в вакууме, да? Я правда не понимаю, как можно что-то забыть, когда у тебя в руках два объекта TreeNode и ссылка на ITreeManipulationService, который умеет делать с деревьями все, что душа пожелает.

Все равно какой-то не очень жизненный пример. Если взять что-то более реальное -- ту же модель файловой системы, то там куда прикажешь заталкивать методы копирования и переименования файлов?

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, dimgel, Вы писали:

D>>Нет, конечно. Они могут быть большие.

Из моего болота (сидя в котором, я приводил пример, когда в swing-клиент нужно отдавать разные данные админу и обычному юзеру) напрашивается вопрос: а нужно ли проносить состояние (полное, причём) через все слои в неизменном виде? Мне вот оказалось нужно прямо противоположное. Данная постановка вопроса означает, что BLL frontend сформулирован в терминах DTO. А что там внутри — объекты, прибитые гвоздями к Hibernate, или заумный Data Mapper, это отдельный вопрос, совершенно неважный с точки зрения пользователей BLL. То есть, данный сценарий использования DTO повышает инкапсуляцию.

Что же касается потрохов BLL и ниже, то твой пример выше я (надеюсь) понял. Возможно, в действительно больших системах (если считать в "десятках/сотнях одновременных программистов"

) этот подход безальтернативен, просто я с таковыми не сталкивался.

Ну и если задача такова, что полное состояние можно и нужно отдавать клиентам BLL, тогда да, POJO без логики приведут к очевидному выигрышу, т.к. в них можно будет формулировать и фронтенд, и потроха BLL. Скажем, если речь идёт об обычных сайтах, в которых отсечение лишних (чувствительных) данных выполняется фактически в процессе генерации html-кода, т.е. слоем представления, выполняющемся в том же процессе, что и BL. Гы, но этот случай вырожденный (язвлю, устал от сайтостроительства). Многие десктопные приложения похожи на сайт в том плане, что всё в одном процессе: и данные, и логика представления. А вот в распределённых системах мне такое щастье не встречалось, там DTO рулит.

D>>Жизненный пример плохим быть не может.

В кывте вон самая главная вещь — дерево.
GZ>Не думаю что оно реализовано именно так.

Дык я этого и не утверждаю.

Просто взяли хороший пример задачи — и поехали по вариантам.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Aikin, Вы писали:

A>Небольшой съезд в сторону:
Н>>Сегодня -- toDTO/fromDTO,
A>Mass Transit

Н>>завтра -- toJSON/fromJSON
A>http://james.newtonking.com/projects/json-net.aspx

Сериализация и маппинг рулят! В Java готовые инструментарии есть практически под всё.
А to/from это вообще предельно неудобный антипаттерн. Я его "изобрел" где-то на первом году профессионального программирования, но быстро обнаружил на сколько он не рулит.

Здравствуйте, Нахлобуч, Вы писали:

Н>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 никакого отношения.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Скажем так, я склонен вгонять в entities ту логику, которая (при наличии желания) также естественно могла бы лечь в триггеры базы.

Есть более простое правило — entity может содержать логику, которая не требует внешних связей.

Здравствуйте, Blazkowicz, Вы писали:

B>Сериализация и маппинг рулят! В Java готовые инструментарии есть практически под всё.
B>А to/from это вообще предельно неудобный антипаттерн. Я его "изобрел" где-то на первом году профессионального программирования, но быстро обнаружил на сколько он не рулит.

Имеется в виду, что сами entity классы содержат минимум типа аннотации @transient (или как она там), а весь код сериализатора является внешним и работает через рефлексию, я правильно понял? C POJO без логики это гораздо удобнее, ещё один хороший аргумент против меня.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, IT, Вы писали:

D>>Скажем так, я склонен вгонять в entities ту логику, которая (при наличии желания) также естественно могла бы лечь в триггеры базы.

IT>Есть более простое правило — entity может содержать логику, которая не требует внешних связей.

А связи с другими entities — внешние?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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>или использовать шаблоны.

Можно ссылку, откуда плясать при возникновении необходимости?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Эммм... Как сохранить себя в БД, знают сущности в любом ORM...

Небольшое уточнение — в любом heavy ORM.

Здравствуйте, dimgel, Вы писали:

D>А я говорю не о клиенте, а о BL, который так или иначе работает с entity. Клиент получит DTO, в котором ничего этого не будет. А BL будет вызывать короткий вариант, как было описано:

"Клиент" здесь -- обобщенный термин кода, внешнего по отношению к какому-то модулю. Если и ввел в заблуждение, то не нарочно.

D>Очень жесткие требования по сохранности данных, плюс родимый MyISAM без контроля ссылочной целостности

Туточки вам пожалуйста. Выбрали там себе движок, который не обеспечивает того, без чего современные СУБД и представить себе невозможно, тут же выкатили требование о "сохранности данных", которое в таких условия только руками и остается контролировать, и теперь, значится, все эти манипуляции называются "бизнес-логикой"? Да ничего подобного. К бизнесу это отношения не имеет. Бизнесу начихать, ссылки там считаются, флаги выставляются, или каждый раз все таблицы просматриваются. Требование "сохранность данных" можно было обеспечить взяв другой движок СУБД.

D>через которые надо гнать ВСЕ операции, включая установку свойств объектов (как, не все? а какие можно? a.setB() можно?), башка пойдёт кругом очень быстро.

Не стоит перегибать палку. У меня есть четкий критерий того, какие операции должны быть реализованы в самом классе, а какие -- во вне: все операции, которые не требуют доступа к приватным членам объекта, должны выноситься наружу. Установка свойств объекта, очевидно, требует доступа к закрытым членам.

D>А в данной ветке рассматриваются enterprise-паттерны, специфическая область, не имеющая к fs никакого отношения.

Ну раз так, то расскажи, как ты будешь в типичной "enterprise"-системе реализовывать, скажем, какой-нибудь иерархический реестр документов, с отслеживанием версий, папками и этими самыми документами. По сути -- та же файловая система. Логика загрузки-сохранения, переименования-редактирования где будет?

Здравствуйте, 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% аванса, потом я сяду, спроектирую и сделаю.

В общем, в дальнейшем повторении и пережёвывании уже приведённых аргументов смысла не вижу. А учитывая твой чудесный "критерий", по архитектуре я предпочту поучиться у других, звиняйте.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, IT, Вы писали:

D>>А связи с другими entities — внешние?

IT>Зависит от твоей модели. Order и OrderItem скорее всего нет, а OrderItem и BusSchedule скорее всего да.

М-да. Всё объяснил.

Вот почему все местные асы успели всё перетереть между собой ещё даже до того, как я Фаулера начал читать?

Завязываю с этой веткой.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Вот почему все местные асы успели всё перетереть между собой ещё даже до того, как я Фаулера начал читать?

D>Завязываю с этой веткой.

Рекомендую отсортировать топики в этом форуме по оценкам и начинать просматривать схожие темы. Их тут с десяток.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, dimgel, Вы писали:

D>>Вот почему все местные асы успели всё перетереть между собой ещё даже до того, как я Фаулера начал читать?

D>>Завязываю с этой веткой.

B>Рекомендую отсортировать топики в этом форуме по оценкам и начинать просматривать схожие темы. Их тут с десяток.

Да я в курсе. Только заново всё перечитывать "на каждом этапе жизненного пути" никаких сил не хватит.

Вот забросил щас пару-тройку пробных шаров, посмотрел, как волны расходятся, и пока хватит. Будет когда-нибудь совсем нечего делать (гы, на пенсии) — сяду, перечитаю сплошняком.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

IT>>Зависит от твоей модели. Order и OrderItem скорее всего нет, а OrderItem и BusSchedule скорее всего да.

D>М-да. Всё объяснил.

Что именно не понятно

D>Вот почему все местные асы успели всё перетереть между собой ещё даже до того, как я Фаулера начал читать?

D>Завязываю с этой веткой.

Ты бы лучше попробовал понять почему несколько человек в этой теме пели тебе про одно и тоже — про сложность. Ты всё как-то отмахиваешься от этого момента, а тем не менее он как раз является в этом споре ключевым для определения наилучшего решения.

Здравствуйте, IT, Вы писали:

IT>Ты бы лучше попробовал понять почему несколько человек в этой теме пели тебе про одно и тоже — про сложность. Ты всё как-то отмахиваешься от этого момента,

Я отмахиваюсь от конкретных рецептов борьбы с этой сложностью, которыми меня кормят без конкретной аргументации. "За маму, бл#$%, за папу." Нахлобуч, чей абстрактно-высокоумный пост ты плюсанул, чуть ниже выдал совершенно дикую ересь по конкретике. Спрашивается: чего стоят песни о сложности в его исполнении?

IT>а тем не менее он как раз является в этом споре ключевым для определения наилучшего решения.

Вот тут ниже mrozov красиво спел про наилучшие решения. А я у тебя попросил всего лишь навсего уточнение термина "внешние связи" применительно к entity.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>А я у тебя попросил всего лишь навсего уточнение термина "внешние связи" применительно к entity.

Впрочем, если ты соблаговолишь пройтись развёрнуто по моим примерам (в духе "пойдёшь налево — коня съедят, пойдёшь направо — тебя съедят, про прямо и говорить стыдно"), я был бы признателен.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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% аванса, потом я сяду, спроектирую и сделаю.

Лихо. Я не просил ни проектировать, ни делать. Просто написать русским по белому текст в стиле "такие-то три класса, логика сохранения там-то, отслеживание версий -- тут" было бы вполне достаточно.

Здравствуйте, Нахлобуч, Вы писали:

Н>Это хороший критерий. К тому же, он четкий и недвусмысленный, в отличие от

Н>

Н>...если изменение состояния объекта базы (entity) ведёт к необходимости каскадных изменений состояний других объектов (как в примере со счётчиком ссылок), код, выполняющий эти изменения, я вгоняю внутрь entity.

Н>Не будет у тебя в следующем проекте счетчика ссылок -- как таким критерием пользоваться?

М-да, хоть и не собирался отвечать, но мимо этого бреда пройти невозможно. Не будет счётчика ссылок, не будет соответствующего кода в entity.

А чем тебе мой критерий показался двусмысленным, интересно знать? Из одних entities я позволяю себе работать с другими entities. Я уж не знаю, как ещё это описать, чтобы Вам стало понятно.

Н>Не надо со мной кокетничать, я не барышня.

Данная обидчивая реплика доказывает обратное.

Н>Если что-то хочешь сказать -- говори, не намекай. А что касается "_this должен быть this" -- это, что называется, back to square one: у тебя, как будто бы, начал проклёвываться критерий того, какие операции должны быть частью контракта класса, а какие нет -- и на тебе, опять всё запихать вовнутрь.

Мне как-то всегда казалось, что лишнее делегирование элементарно просматривается в том числе по наличию косвенных ссылок на объект.

Н>Объект выставляет наружу минимально необходимый контракт (приницип минимизации публичного контракта), все остальное -- внешнее по отношению к нему.

Даже если это остальное не делает ничего, кроме как делегирует к методам обсновного объекта? При отсутствии дополнительных выгод, упоминания которых я жду с открытым ртом, этот принцип называется "заставь дурака богу молиться". Про слепое следование принципам ниже уже отписали, и ты там даже оценочку поставил. Принципов, знаете ли, масса разных, многие даже друг дружке противоречат.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>М-да, хоть и не собирался отвечать, но мимо этого бреда пройти невозможно. Не будет счётчика ссылок, не будет соответствующего кода в entity.

А какой будет? Напоминаю:

server_mouse: Отделение BL от данных и выделение отдельной группы объектов-data-контейнеров. Где же тогда инкапсуляция? Правильно — в Ж.
IB: А в данном случае, с инкапсуляцией все в порядке.
dimgel: Бояре сумлеваются. Редуцировать entities до структур... я лучше уж DTO добавлю (в качестве базовых классов entities).

Внимание, вопрос: какими критериями лично ты руководствуешься при определении, какой метод стоит поместить в бизнес-объект, а какой туда помещать не стоит?

D>Даже если это остальное не делает ничего, кроме как делегирует к методам обсновного объекта?

Зависит от. Я уже говорил, что откровенный примитив лучше оставить по месту до лучших времен. В остальных случаях -- выношу.

D>При отсутствии дополнительных выгод, упоминания которых я жду с открытым ртом, этот принцип называется "заставь дурака богу молиться".

Примитивные случаи не рассматриваем. Во всех остальных: каждый объект обладает строго ограниченной зоной ответственности (его изменение не порождает каскад изменений в остальных частях системы; упрощается разработка и поддержка, поскольку в каждый момент времени программиск концентриуется на строго определенном куске функциональности, не захламленном поддерживающим кодом), повторное использование (обратно из-за того, что модуль обеспечивает строго определенную функциональность), упрощается модульное тестирование.

Достаточно?

Здравствуйте, Нахлобуч, Вы писали:

Н>Внимание, вопрос: какими критериями лично ты руководствуешься при определении, какой метод стоит поместить в бизнес-объект, а какой туда помещать не стоит?

Вот же ж чёрт...

В десятый раз повторяю: я позволяю себе из entity работать с другими entities. И больше ни с чем — ни с email-оповещалками, ни с UI, ни со слоем BL, который за всё это отвечает. То есть, если взять все entities и обозвать их отдельным слоем, то содержащийся в нём код не обращается ни к чему за его слоя. Но внутри этого слоя я действую по принципу минимизации количества вспомогательных объектов и делегирования, поскольку BL в любом случае имеет доступ к entities, так что ему всё равно, а выше BL я entities не пускаю, интерфейс BL сформулирован в терминах DTO.

D>>Даже если это остальное не делает ничего, кроме как делегирует к методам обсновного объекта?

Н>Зависит от. Я уже говорил, что откровенный примитив лучше оставить по месту до лучших времен. В остальных случаях -- выношу.

Ок.

D>>При отсутствии дополнительных выгод, упоминания которых я жду с открытым ртом, этот принцип называется "заставь дурака богу молиться".

Н>Примитивные случаи не рассматриваем. Во всех остальных: каждый объект обладает строго ограниченной зоной ответственности (его изменение не порождает каскад изменений в остальных частях системы; упрощается разработка и поддержка, поскольку в каждый момент времени программиск концентриуется на строго определенном куске функциональности, не захламленном поддерживающим кодом), повторное использование (обратно из-за того, что модуль обеспечивает строго определенную функциональность), упрощается модульное тестирование.

Н>Достаточно?

Да, наверное... Похоже, мы спорим ни о чём. Щас можно было бы увязнуть в пустозвонстве на тему "что такое зона ответственности", но думаю, все эти вопросы не имеют смысла вне конкретики. Насчёт системы документооборота ты конечно погорячился — даже элементарное ТЗ в виде списка допустимых операций составлять — не одну минуту, а прикидывать, как этот список операций раскидать — и того дольше. Но я уже приводил совершенно конкретный пример достаточно сложной и реалистичной операции:

parentNode.addChild(TreeNode childNode) — у меня модификация счётчиков детей и потомков для всех предков childNode выполняется внутри TreeNode. Чем это плохо?

Ну я только одно могу придумать: при политике lazy load, будет много атомарных обращений к базе — столько, сколько предков у parentNode. Но если уж на то пошло, я запрос на предзагрузку вынесу в контроллер/хелпер, а логику модификации счётчиков всё равно оставлю в классе TreeNode — ну блин нечего ей делать вовне, вообще нечего.

Повторюсь ещё раз на всякий случай: всё это предполагает использование DTO. Ну и что? Я распух на DTO, зато похудел на всяких хелперах. По суммарному объёму кода ещё неизвестно, в проигрыше я или нет, а по удобству использования мне мой вариант больше нравится: DTO — они для внешнего использования, и код, их обслуживающий, в целом изолирован; а "ядровая логика BLL" в итоге стала существенно компактнее и проще.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

IT>>Ты бы лучше попробовал понять почему несколько человек в этой теме пели тебе про одно и тоже — про сложность. Ты всё как-то отмахиваешься от этого момента,

D>Я отмахиваюсь от конкретных рецептов борьбы с этой сложностью, которыми меня кормят без конкретной аргументации. "За маму, бл#$%, за папу." Нахлобуч, чей абстрактно-высокоумный пост ты плюсанул, чуть ниже выдал совершенно дикую ересь по конкретике. Спрашивается: чего стоят песни о сложности в его исполнении?

Дай ссылочку на ересь, а то я что-то выдимо пропустил.

IT>>а тем не менее он как раз является в этом споре ключевым для определения наилучшего решения.

D>Вот тут ниже mrozov красиво спел про наилучшие решения.

mrozov спел не тебе, а топик стартеру.

D>А я у тебя попросил всего лишь навсего уточнение термина "внешние связи" применительно к entity.

А я тебе и ответил. Всё зависит. Точно так же как и правильность твоего решения зависит от конктретной ситуации. В одной ситуации оно может быть вполне оправдано, а в другой повлечёт кучу проблем. Приводить тебе конкретные примеры никто не будет, просто по той причине, что чтобы продемонстрировать несостоятельность твоего подхода нужны не 10 и не 20, а тысячи строк кода. Хочешь я тебе приведу пример? Давай.

using System;

interface IOutputer
{
    void Write(string str);
}

class ConsoleOutputer : IOutputer
{
    public void Write(string str)
    {
        Console.Write(str);
    }
}

interface IFormatter
{
    void Write(string format, params object[] args);
}

class Formatter : IFormatter
{
    public Formatter(IOutputer outputer)
    {
        _outputer = outputer;
    }

    readonly IOutputer _outputer;

    public void Write(string format, params object[] args)
    {
        _outputer.Write(string.Format(format, args));
    }
}

class Programm
{
    static void Main()
    {
        var outputer  = new ConsoleOutputer();
        var formatter = new Formatter(outputer);

        formatter.Write("Hello, {0}!\n", "World");
    }
}

Знаешь что делает этот бред и почему это бред? Делает он вот что:

using System;

class Programm
{
    static void Main()
    {
        Console.WriteLine("Hello, World!");
    }
}

А бред это потому, что используемые средства не адекватны решаемой задаче. Но, чтобы продемонстрировать тебе, когда это перестанет быть бредом и станет весьма полезным паттерном мне нужно набить несколько сот может быть тысяч строк кода, которые ты всё равно читать не будешь. Как ты там сказал? ТЗ, сроки, 50%? (кстати, ты забыл об оставшихся 50%)

И если Нахлобуч написал ересь, то, я подозреваю, это только потому, что он попытался впихнуть невпихуемое в две строчки, которые ты здесь от всех требуешь. Так не бывает. Придётся обходиться без примеров.

В принципе, задачу можно облегчить методом от противного

Представь, что твоя задача находится на шкале сложности в определённой точке. Предположим, что твоё решение вполне адекватно твоей задаче. Теперь давай двинемся в сторону соответствующей более простым задачам, двинемся как можно дальше, туда, где твоё решение перестанет быть адекватным и станет похожим на то, что я привёл выше. Представил? Представь ещё, что ты доказываешь правильность своего подхода людям, решающим более простые задачи и которые в той точке сложности в которой был ты никогда не были и о ней не подозревают. Как ты им будешь что-то доказывать, какие приводить примеры? А они станут тебя слушать или обзовут твои неудавшиеся попытки ересью?

Если ты понял о чём речь, то можно возвращаться в исходную точку и начинать разбираться с тем, что и почему здесь говорят о сложности и почему плюсуются абстрактно-высокоуровневые посты.

Здравствуйте, IT, Вы писали:

IT>Если ты понял о чём речь, то можно возвращаться в исходную точку и начинать разбираться с тем, что и почему здесь говорят о сложности и почему плюсуются абстрактно-высокоуровневые посты.

Тем не менее, GlebZ ухитрился написать нечто не только абстрактно-высокоуровневое, но и содержащее достаточно конкретики, чтобы я смог извлечь из этого что-то полезное (несмотря на то, что это полезное неприменимо к моим нынешним масштабам). А пустое бла-бла-бла вокруг прописных истин с элементами самовосхваления не прибавляет ни пользы для слушателя, ни доверия к квалификации бла-бла-блатора. За сим откланиваюсь.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Впрочем, если ты соблаговолишь пройтись развёрнуто по моим примерам (в духе "пойдёшь налево — коня съедят, пойдёшь направо — тебя съедят, про прямо и говорить стыдно"), я был бы признателен.

Я бы соблаговолил, только перечитывать всю ветку лень. Давай ты сформулируешь свои вопросы ещё раз, а я попробую на них ответить в терминах коней.

Здравствуйте, IT, Вы писали:

D>>Впрочем, если ты соблаговолишь пройтись развёрнуто по моим примерам (в духе "пойдёшь налево — коня съедят, пойдёшь направо — тебя съедят, про прямо и говорить стыдно"), я был бы признателен.

IT>Я бы соблаговолил, только перечитывать всю ветку лень. Давай ты сформулируешь свои вопросы ещё раз, а я попробую на них ответить в терминах коней.

1) Есть сайт/веб-сервис и GUI-клиент к нему, не сохраняющий состояния. Клиент поддерживает режимы обычного юзера и администратора. Обобщённый use case: человек запускает клиент, логинится юзером или админом, выполняет несколько запросов к серверу, завершает клиента (тем самым выполняя logout). Админы и юзеры могут работать с одними и теми же объектами, но юзеры не должны видеть некоторых полей. Я решил через DTO. DTO-объекты для админов наследуются из DTO-объектов для юзверей, добавляя к ним "админские" данные. Решение без DTO? Я вижу собственно только одну альтернативу копированию структуры — редактирование на месте, с предварительным detach от ORM. Но вот не лежит душа: к примеру, вдруг захочется закешировать что-нибудь, а оно уже "подчищенное"...

2) Есть класс TreeNode, являющийся mixin-ом (вспомогательным базовым классом) для некоторых entities. Он добавляет к entity поля parent, numChildren, numDescendants и методы манипуляции деревом, например TreeNode::addChild(TreeNode). Данный метод выполняет инкремент счётчика numChildren у себя, а также счётчика numDescendants у себя и у всех своих предков, плюс помечает нового дитятю как подлежащего сохранению в базе. Хотелось бы услышать пример use case ("налево пойдёшь"), когда такое решение несостоятельно и необходимо выносить эту логику во внешний контроллер. При дополнительном условии, что мы не планируем отказ от использования DTO (поскольку такой отказ — ещё более жёсткое условие, чем "прибивание архитектуры гвоздями к Hibernate" (c) твой же).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

D>плюс помечает нового дитятю как подлежащего сохранению в базе

Вот это лишнее, Hibernate сам сбросит дерево, насколько я помню. Так что метод addChild() содержит только инкременты счётчиков, т.е. выглядит так, словно никакого ORM вообще не существует.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Тем не менее, GlebZ ухитрился написать нечто не только абстрактно-высокоуровневое, но и содержащее достаточно конкретики

GlebZ — маладец! Почёт ему и уважуха.

D>За сим откланиваюсь.

В который раз?

Здравствуйте, IT, Вы писали:

D>>За сим откланиваюсь.

IT>В который раз?

Перед тобой-то?

Посмотрим, как на сформулированные специально для тебя вопросы ответишь, может и в последний.

Если я уже начал чувствовать замедление собственных мозгов, то к тем, кто на 10 лет меня старше, надо относиться ещё более критически.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>1) Есть сайт/веб-сервис и GUI-клиент к нему, не сохраняющий состояния. Клиент поддерживает режимы обычного юзера и администратора. Обобщённый use case: человек запускает клиент, логинится юзером или админом, выполняет несколько запросов к серверу, завершает клиента (тем самым выполняя logout). Админы и юзеры могут работать с одними и теми же объектами, но юзеры не должны видеть некоторых полей. Я решил через DTO. DTO-объекты для админов наследуются из DTO-объектов для юзверей, добавляя к ним "админские" данные. Решение без DTO? Я вижу собственно только одну альтернативу копированию структуры — редактирование на месте, с предварительным detach от ORM. Но вот не лежит душа: к примеру, вдруг захочется закешировать что-нибудь, а оно уже "подчищенное"...

Собственно говоря, твоё решение определяется как раз тем, к чему у тебя не лежит душа. Я принципиально не кеширую объекты, в том числе по причинам, о которых ты говоришь. Я кеширую результаты вызовов методов. Поэтому у меня нет проблем с detach (как и нет самого detach) и нет проблем с использованием одного и того же типа объекта, экземпляр которого может иметь некоторые поля незаполненными, если они не нужны.

На самом деле, ты продемонстрировал хороший пример того, как выбираемые инструменты, диктующие архитектуру приложения, влияют на решения программиста. Ты используешь ORM, который кроме всего прочего занимается кешированием объектов. Ты хорошо понимаешь, какую западлянку можно получить, если использовать один и тот же объект и пытаешься решить проблему с помощью добавления новой сущности. Это решает проблему, но её могло бы и не быть вовсе, если бы архитектуру приложения тебе диктовал не твой ORM, а ты сам. А так это похоже на выпрямление кривизны с помощью другого компенсирующего выкривления.

Мой подход. Используем один тип объекта из модели данных для двух разных запросов, объекты никогда повторно не используются, если нужно кеширование, то кешируются результаты вызовов методов. Просто, эффективно, надёжно.

D>2) Есть класс TreeNode, являющийся mixin-ом (вспомогательным базовым классом) для некоторых entities. Он добавляет к entity поля parent, numChildren, numDescendants и методы манипуляции деревом, например TreeNode::addChild(TreeNode). Данный метод выполняет инкремент счётчика numChildren у себя, а также счётчика numDescendants у себя и у всех своих предков, плюс помечает нового дитятю как подлежащего сохранению в базе. Хотелось бы услышать пример use case ("налево пойдёшь"), когда такое решение несостоятельно и необходимо выносить эту логику во внешний контроллер. При дополнительном условии, что мы не планируем отказ от использования DTO (поскольку такой отказ — ещё более жёсткое условие, чем "прибивание архитектуры гвоздями к Hibernate" (c) твой же).

В данном случае речь идёт о логике работы с конкретной структурой данных и у меня нет никаких притензий, т.к. это всё ортогонально BLL, DAL и прочей лэйерщине. В большинстве случаев я бы поступил так же. Единственное, скорее всего я бы постарался выделить подобную работу с деревьями в common и сделать её generic

Здравствуйте, IT, Вы писали:

IT>Мой подход. Используем один тип объекта из модели данных для двух разных запросов, объекты никогда повторно не используются, если нужно кеширование, то кешируются результаты вызовов методов. Просто, эффективно, надёжно.

Во! Теперь припоминаю, что про кеширование результатов вызовов методов ты уже неоднократно когда-то высказывался. Спасиб.

IT>Единственное, скорее всего я бы постарался выделить подобную работу с деревьями в common и сделать её generic

Это я тоже уже догадался, там иначе привинчивать к основному классу неудобно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>>>За сим откланиваюсь.

IT>>В который раз?

D>Перед тобой-то?

Я понял, я понял, ты откланиваешься перед каждым отдельно

D>Посмотрим, как на сформулированные специально для тебя вопросы ответишь, может и в последний.

Если я уже начал чувствовать замедление собственных мозгов, то к тем, кто на 10 лет меня старше, надо относиться ещё более критически.

Я свои мозги берегу с юности и не распыляю их ресурсы понапрасну. Один раз нашёл приемлемое в 95% случаях решение и теперь решаю подобные задачи в режиме idle.

Здравствуйте, IT, Вы писали:

IT>Представь, что твоя задача находится на шкале сложности в определённой точке. Предположим, что твоё решение вполне адекватно твоей задаче. Теперь давай двинемся в сторону соответствующей более простым задачам, двинемся как можно дальше, туда, где твоё решение перестанет быть адекватным и станет похожим на то, что я привёл выше. Представил? Представь ещё, что ты доказываешь правильность своего подхода людям, решающим более простые задачи и которые в той точке сложности в которой был ты никогда не были и о ней не подозревают. Как ты им будешь что-то доказывать, какие приводить примеры? А они станут тебя слушать или обзовут твои неудавшиеся попытки ересью?

IT>Если ты понял о чём речь, то можно возвращаться в исходную точку и начинать разбираться с тем, что и почему здесь говорят о сложности и почему плюсуются абстрактно-высокоуровневые посты.

Хорошо расписал всё. А можешь высказать свое мнение по обсуждению в соседней ветке:
http://rsdn.ru/forum/message/3385318.1.aspx (начиная отсюда и до конца)
?
Я допускаю, что я тоже в силу меньшего опыта могу чего-то не понимать, но, повторюсь, я к примеру часто использую в BLL & DAL статические классы и за несколько лет это мне никаких проблем не принесло. Мне же говорят что нужно использовать интерфейсы с DI, и для меня это выглядит как твой пример с IOutputer и IFormatter — я не вижу необходимости в этом, абсолютно.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, Нахлобуч, Вы писали:

Н>>Внимание, вопрос: какими критериями лично ты руководствуешься при определении, какой метод стоит поместить в бизнес-объект, а какой туда помещать не стоит?

D>Вот же ж чёрт...

... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>

Здравствуйте, dimgel, Вы писали:

D>По-моему, вы двое говорите о разной инкапсуляции.
Она одна.

D>Я повторю свой пример: есть метод A->setB(B) и поле B::countAs. Корректировка второго из первого — это ИМХО оправданная инкапсуляция логики (в данном случае тривиальной), поскольку в противном случае об этом счётчике придётся помнить всюду, где используется первый метод.
Этот пример не имеет отношения к исходному вопросу.

D>Бояре сумлеваются.
Проблемы бояр...

D>Редуцировать entities до структур... я лучше уж DTO добавлю (в качестве базовых классов entities).
Да хоть горшком назови.

Здравствуйте, Ziaw, Вы писали:

Z>А где они берут эти ентити с которыми работают? tracking + lazy-load? Или они умеют лазить в базу, доставать то, что нужно, сохранять то, что нужно?

Умеют. Добавления/модификации объектов hiberate сбрасывает в базу сам, а вот для запроса объекта по (class, id), а также для удаления объекта требуется доступ из вызывающего entitу к hibernate session (уже не помню, инжектил я её в каждый объект или обращался к current thread session).

Скажем так: я рассматривал DAL = все entities + hibernate + соответствующие helpers (preloads и т.п.). Мне хотелось, чтобы интерфейс этого DAL, используемый BLL, был компактным и объектным, с минимумом вспомогательных классов и без торчащих наружу потрохов ORM. То есть, чтобы BLL мог вызывать человеческое parentNode.addChild(childNode) вместо treeController.addChild(parentNode, childNode). Сам DAL благодаря хиберу выходил простым, так что вводить дополнительные расслоения/ограничения внутри него было нецелесообразно; работа с session из entities в итоге давала более компактный результат (я не погнушался и сделал базовый класс для всех entities с методом getSession()).

Lazy load вообще говоря ортогонален логике. Когда мне требовалось делать preload вручную, я вызывал соответствующий DAL хелпер из BLL перед вызовом основного метода, что дико (где ж изоляция BLL от потрохов ORM?). Сейчас я сделал бы этот метод (TreeNodeHelper::preloadAncestors(node)) доступным только внутри DAL и воткнул бы его вызов прямо в TreeNode.addChild(). Как-то так.

В общем, на Дао программирования этот подход конечно не тянет, но в качестве варианта решения для системы средней сложности, прибитой гвоздями к Hibernate, ИМХО вполне жизнеспособен.

Единственный неоднозначный вопрос — где кончается логика отслеживания логической целостности базы и начинается бизнес-логика. Я не позволял себе вызывать из DAL что-либо за пределами DAL, но с другой стороны, многие вещи, находящиеся в BLL и работающие только с базой, можно перетащить из BLL в DAL один в один. В таких случаях я обычно консультировался со своей левой пяткой.

Z>Я сильно сомневаюсь, что возможны клиент-серверы с более менее сложной логикой без DTO вообще, так что вопрос не в DTO а их количестве. Хотя я много слышал от сторонников тонкой модели, что они легко обходятся без DTO.

IT ниже написал свой вариант решения одной конкретной задачи. Напоминание про "кеширование результатов вызовов методов" для меня было недостающим куском мозаики для понимания его минималистского stateless + DTOless подхода. Весьма красивого, надо сказать, хотя и требующего некоторых дополнительных усилий при первом использовании, т.к. "типовыми средствами" подобная парадигма не поддерживается.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Умеют. Добавления/модификации объектов hiberate сбрасывает в базу сам, а вот для запроса объекта по (class, id), а также для удаления объекта требуется доступ из вызывающего entitу к hibernate session (уже не помню, инжектил я её в каждый объект или обращался к current thread session).

ага, new Entity() и гибернейт сам почуял, что ее хотят заперсистить. Почти вся логика происходит по сценарию —
1. вытаскиваем объекты
2. изменяем их и/или создаем новые и/или удаляем
3. сохраняем результаты

Логика как не крути завазяна на БД, пусть неявно, излишне абстрагироваться от тоже БД вредно.

D>Lazy load вообще говоря ортогонален логике. Когда мне требовалось делать preload вручную, я вызывал соответствующий DAL хелпер из BLL перед вызовом основного метода, что дико (где ж изоляция BLL от потрохов ORM?). Сейчас я сделал бы этот метод (TreeNodeHelper::preloadAncestors(node)) доступным только внутри DAL и воткнул бы его вызов прямо в TreeNode.addChild(). Как-то так.

Ортогонален BL, но мы тут не о BL, а об архитектуре. Если твой BL завязан на LL — это может привести к серьезным проблемам производительности в будущем. Ты можешь возразить, что BL ничего не знает про LL и он происходит абсолютно прозрачно. Но это ничего не меняет, избавиться от LL без серьезного переписывания BL у тебя не выйдет.

D>IT ниже написал свой вариант решения одной конкретной задачи. Напоминание про "кеширование результатов вызовов методов" для меня было недостающим куском мозаики для понимания его минималистского stateless + DTOless подхода. Весьма красивого, надо сказать, хотя и требующего некоторых дополнительных усилий при первом использовании, т.к. "типовыми средствами" подобная парадигма не поддерживается.

Это ты свою узкую проблему решил. Кеширование результатов вызовов stateless server'а вполне стандартный паттерн, поддерживается даже фреймворками.

DTO решает другую серьезную задачу — отдай мне то, и только то, что нужно одним вызовом. При использовании тонкой модели встречаются случаи когда "то, и только то, что нужно" является Entity или IList<Entity>, тогда спец. DTO не требуется. Но это лишь частный случай.

... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>

Здравствуйте, IB, Вы писали:

D>>По-моему, вы двое говорите о разной инкапсуляции.
IB>Она одна.

"Данные отдельно, логика отдельно" — это инкапсуляция? Может быть, напомнить определение из ООП, про чёрные ящики там и т.п.? Помнится, IT честно говорил, что в его архитектуре ООП с инкапсуляцией идут лесом. Но не придумывал новых трактовок общеизвестным терминам.

Если же речь идёт об инкапсуляции бизнес-логики (как я догадываюсь), то это далеко не "одна", а совсем даже "другая".

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Ziaw, Вы писали:

Z>ага, new Entity() и гибернейт сам почуял, что ее хотят заперсистить.

В большинстве случаев — да, т.к. новый объект добавляется в дерево уже persistent-объектов. Но не всегда, разумеется, это я несколько неряшливо написал.

Z>Ортогонален BL, но мы тут не о BL, а об архитектуре.

В таком случае, что такое архитектура, если не декомпозиция на слои и их взаимодействие?

Z>Если твой BL завязан на LL — это может привести к серьезным проблемам производительности в будущем.

Не сталкивался. Разумеется, поскольку BL оперитрует бизнес объектами, он в любом случае завязан на их структуру, т.е. на структуру базы. При изменении структуры базы BL придётся рефакторить, это очевидно. Что касается проблем производительности в рамках заданной структуры базы, то в хибере полно винтиков, и я описал, где и как я склонен эти винтики дёргать: внутри DAL, прозрачным для BL образом.

Z>Это ты свою узкую проблему решил. Кеширование результатов вызовов stateless server'а вполне стандартный паттерн, поддерживается даже фреймворками.

Ок, буду иметь в виду. В любом случае я собирался этот вопрос исследовать поподробнее после освоения lift.

Z>DTO решает другую серьезную задачу — отдай мне то, и только то, что нужно одним вызовом. При использовании тонкой модели встречаются случаи когда "то, и только то, что нужно" является Entity или IList<Entity>, тогда спец. DTO не требуется. Но это лишь частный случай.

Именно с этим аргументом я защищал DTO. Мой конкретный пример, однако, IT решил без DTO. Вполне вероятно, что можно сочинить пример, который он без DTO не решит. Однако я склонен доверять его оценке, что для 95% случаев его подход работает (хотя бы потому, что не могу с ходу вспомнить вообще ни одной задачи, где бы он не сработал).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>"Данные отдельно, логика отдельно" — это инкапсуляция?
Именно.

D> Может быть, напомнить определение из ООП, про чёрные ящики там и т.п.?
Я другое напомню — не надо телегу впереди лошади ставить. Не инкапсуляция, потому что ООП, а ООП потому что инкапсуляция.
Инкапсуляция — это средство уменьшения связности кода, путем сокрытия конкретной реализации за публичным контрактом. Так какую реализацию ты скрываешь, навешивая на данные, к которым один фиг есть публичный доступ, левую логику?

D> Помнится, IT честно говорил, что в его архитектуре ООП с инкапсуляцией идут лесом.
IT умница, и к ООП относится с нежностью и трепетом, так что пальцами ООП не трожь.. =)
IT, если что, сам за себя скажет.

D>Но не придумывал новых трактовок общеизвестным терминам.
Это не новая трактовка, это оригинальная. Почитай классиков, Меерса, например, или Саттера.

D>Если же речь идёт об инкапсуляции бизнес-логики (как я догадываюсь), то это далеко не "одна", а совсем даже "другая".
Чем она другая? Не мог бы ты привести определение обеих?

Здравствуйте, IB, Вы писали:

IB>Инкапсуляция — это средство уменьшения связности кода, путем сокрытия конкретной реализации за публичным контрактом.

Да, согласен. Теперь вижу, где я прокосячил: забыл, что инкапсулировать можно не только состояние.

IB>Так какую реализацию ты скрываешь, навешивая на данные, к которым один фиг есть публичный доступ, левую логику?

А кто тебе сказал, что у меня ко всем данным, на которые я навешиваю логику, есть публичный доступ? Разумеется, я прячу многие вспомогательные вещи, переопределяю геттеры/сеттеры и т.п.

D>>Если же речь идёт об инкапсуляции бизнес-логики (как я догадываюсь), то это далеко не "одна", а совсем даже "другая".
IB>Чем она другая? Не мог бы ты привести определение обеих?

Само по себе коллекционирование взаимосвязанных методов бизнес логики в одном месте — это, строго говоря, не инкапсуляция вообще. Если же брать конкретную точку входа (метод интерфейса BLL), тогда да, посыпаю голову пеплом.

Упираться рогом в классификацию "инкапсуляция состояния" vs "инкапсуляция поведения" смысла не вижу, сути оно не меняет, так что ты прав.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, IB, Вы писали:

D>> Помнится, IT честно говорил, что в его архитектуре ООП с инкапсуляцией идут лесом.
IB>IT умница, и к ООП относится с нежностью и трепетом, так что пальцами ООП не трожь.. =)
IB>IT, если что, сам за себя скажет.

http://rsdn.ru/forum/message/476309.1.aspx

У меня вообще складывается ощущение, что большинство здешних "гуру от архитектуры" нарочно запутывают простые вещи, чтобы утвердиться в собственной крутизне. Все с готовностью соглашаются с тем, что универсальных решений нет, и при этом редко кто опускается до разбора конкретики. Игорь хоть и выступил адвокатом абстрактных разговоров, но в итоге соблаговолил разобрать конкретный пример, и разбор его оказался гораздо короче, чем тысячи строк кода, которыми он меня стращал. Многие ли тут способны повторить этот подвиг? Джаверы неизменно доброжелательны и конструктивны, практически все (платформа видимо влияет). От остальных чёрта с два добьёшься, одни общие размытые слова. Я прошу прощения за агрессивную манеру общения в этой (и не только) ветке, но конкретику приходится из вас из всех выдразнивать, побуждая ваш эгоизм грубыми намёками на вашу глупость.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>У меня вообще складывается ощущение, что большинство здешних "гуру от архитектуры" нарочно запутывают простые вещи, чтобы утвердиться в собственной крутизне.
У меня обратное ощущение. Гуру архитектуры как раз предлагают самые простые решения.

D>Все с готовностью соглашаются с тем, что универсальных решений нет, и при этом редко кто опускается до разбора конкретики.
Универсальных — дейсвтительно нет. Всегда найдется очень редкий частный случай, который ломает универсальное решение.
Зато есть квазиуниверсальное решение, которое в очень многих случаях подходит, но такое решение натыкается на волну протестов "это не ООП", "а где же инкапсуляция", "доменная модель всегда долна быть валидна" и прочее.
Причем вера некоторых людей в ООП гораздо сильнее любой религиозной веры. Это несмотря на то что программист просто обязан быть прагматичным.

Здравствуйте, gandjustas, Вы писали:

G>Зато есть квазиуниверсальное решение, которое в очень многих случаях подходит, но такое решение натыкается на волну протестов "это не ООП", "а где же инкапсуляция", "доменная модель всегда долна быть валидна" и прочее.
G>Причем вера некоторых людей в ООП гораздо сильнее любой религиозной веры. Это несмотря на то что программист просто обязан быть прагматичным.

Я с удовольствием проглотил и переварил Игорево решение, в котором ООП и не пахнет. Он выдал совершенно конкретные и исчерпывающие (на данном уровне детализации) рекомендации. От тебя же я слышал одно только многоумное бла-бла-бла из названий принципов и общих рассуждений, без намёка на конкретику применительно к моим примерам, которыми я тут всю ветку зафлудил. Впрочем, в соседней ветке ты удосужился привести даже пример кода для генерации отчётов; так что чеши туда, где от тебя польза.

А про мою приверженность или отверженность от ООП не тебе судить — когда я 2-3 года назад с пеной у рта защищал тут построение небольших сайтов в архитектуре Transaction Scripts (не называя этот паттерн по имени), без намёка на слои и классы (кроме служебных типа провайдера базы), мне тоже всей толпой на голову срали, с умным видом говорили про DAO и контроллеры. Дураков посамовыражаться за чужой счёт всегда хватает.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

D>От тебя же я слышал одно только многоумное бла-бла-бла из названий принципов и общих рассуждений

Вру, это было от Нахлобуча. От тебя было высокомерное ха-ха-ха и какой-то бред про shared_ptr из C++, не имеющий к рассматриваемой теме никакого отношения. Короче, неадекват.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

dimgel wrote:

> А про мою приверженность или отверженность от ООП не тебе судить -
> когда я 2-3 года назад с пеной у рта защищал тут построение небольших
> сайтов в архитектуре Transaction Scripts (не называя этот паттерн по
> имени), без намёка на слои и классы (кроме служебных типа провайдера
> базы), мне тоже всей толпой на голову срали, с умным видом говорили
> про DAO и контроллеры. Дураков посамовыражаться за чужой счёт всегда
> хватает.

Паттерн Transaction Script никоим образом не приводит к отказу от слоев
AKA Controllers/Services/DAO и, упаси меня инкапсуляция, от классов. Это
всего лишь страшилка в которую тыкают пальцем при обсуждении Anemic
Domain Model.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>Зато есть квазиуниверсальное решение, которое в очень многих случаях подходит, но такое решение натыкается на волну протестов "это не ООП", "а где же инкапсуляция", "доменная модель всегда долна быть валидна" и прочее.
G>>Причем вера некоторых людей в ООП гораздо сильнее любой религиозной веры. Это несмотря на то что программист просто обязан быть прагматичным.

D>Я с удовольствием проглотил и переварил Игорево решение, в котором ООП и не пахнет. Он выдал совершенно конкретные и исчерпывающие (на данном уровне детализации) рекомендации. От тебя же я слышал одно только многоумное бла-бла-бла из названий принципов и общих рассуждений, без намёка на конкретику применительно к моим примерам, которыми я тут всю ветку зафлудил.
С чего ты взял что тебе кто-то что-то должен объяснять, а уж тем более примеры кода показывть. Можно радоваться если тебе хотя бы показали направление.

D>Впрочем, в соседней ветке ты удосужился привести даже пример кода для генерации отчётов; так что чеши туда, где от тебя польза.
Чья бы корова мычала

Здравствуйте, mazurkin, Вы писали:

M>Паттерн Transaction Script никоим образом не приводит к отказу от слоев AKA Controllers/Services/DAO и, упаси меня инкапсуляция, от классов.

Я кажется написал про небольшие сайты. Усложнение нужно там, где оно оправдано, т.е. где в итоге даёт упрощение. Наворачивать слои просто "чтобы были"? Следующий.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Выносить всю логику из пунктов (2) и (3) в контроллеры — значит дублировать её во множестве контроллеров для всех entities, являющихся TreeNode.
Это неправда.
D>Или делать отдельные методы в helper-классах, что всё равно дико: всё-таки гораздо понятнее и более ожидаемо написать node1.addChild(node2), чем TreeController.addChild(node1, node2).
Никаких отдельных методов тут нет.
D>Все вот эти SomethingController, плодящиеся как грибы после дождя, если отказаться от активных entities, дико раздражают.
Никто не плодится.
Почему тебя не устраивает единственный TreeController.addChild(node1, node2), который подходит ко всем классам с примесью TreeNode?
В случае, когда отношения parent-child это деталь реализации, то совершенно нормально из одного контроллера вызвать другой:

EmployeeController.enrollEmployee(Employee e, Department d, WorkContract wc)
{
  TreeController.addChild(d, e); // мы не предполагаем в бизнес-коде прямых вызовов типа d.addChild(e)
}

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Почему тебя не устраивает единственный TreeController.addChild(node1, node2), который подходит ко всем классам с примесью TreeNode?
S>В случае, когда отношения parent-child это деталь реализации, то совершенно нормально из одного контроллера вызвать другой:
S>

S>EmployeeController.enrollEmployee(Employee e, Department d, WorkContract wc)
S>{
S>  TreeController.addChild(d, e); // мы не предполагаем в бизнес-коде прямых вызовов типа d.addChild(e)
S>}
S>

Да просто, как мне видится, это лишняя косвенность. Ничего летального, конечно, но зачем она, если можно всё делать "на месте"? (Я уже посыпАл голову пеплом, отвечая GlebZ-у, так что не надо мне повторять, что в сложных случаях я со своим подходом сяду в лужу — в моих конкретных случаях всё было ок.)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Sinclair, Вы писали:

Вот я, кстати, надеялся, что ты, как веб-разработчик, наверняка с богатым опытом возни с DOM из javascript, меня поймёшь. Представь, что все эти операции addChild, createElement, createTextNode, сами по себе многословные до тошноты, в дополнение ко всему ещё пришлось бы вызывать через какой-то DOMController? Пальцы отсохнут.

S> мы не предполагаем в бизнес-коде прямых вызовов типа d.addChild(e)

А почему, собственно?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, Sinclair, Вы писали:

S>>Почему тебя не устраивает единственный TreeController.addChild(node1, node2), который подходит ко всем классам с примесью TreeNode?
S>>В случае, когда отношения parent-child это деталь реализации, то совершенно нормально из одного контроллера вызвать другой:
S>>

S>>EmployeeController.enrollEmployee(Employee e, Department d, WorkContract wc)
S>>{
S>>  TreeController.addChild(d, e); // мы не предполагаем в бизнес-коде прямых вызовов типа d.addChild(e)
S>>}
S>>

D>Да просто, как мне видится, это лишняя косвенность.
Не очень понятно, что означает "лишняя косвенность".
Косвенности никакой нет — всё идет напрямую.

D>Ничего летального, конечно, но зачем она, если можно всё делать "на месте"?
А что означает "на месте"? Как будет выглядеть метод "принять на работу" и где он будет расположен? В Employee? В Department? В WorkContract?
Очевидно, метод будет расположен где-то в EmploymentSubsystem, чтобы легче было повторно использовать Employee, Department, и WorkContract.
В таком случае остается понять, как будет устроен этот метод в обоих подходах.

D>(Я уже посыпАл голову пеплом, отвечая GlebZ-у, так что не надо мне повторять, что в сложных случаях я со своим подходом сяду в лужу — в моих конкретных случаях всё было ок.)
Совершенно непонятно, откуда взялся Ok, при том что тебе даже в простых случаях нужно порождать отдельные DTO на каждый чих и оборудовать каждого toDTO/fromDTO.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Косвенности никакой нет — всё идет напрямую.

Ниже уже ответил.

S>А что означает "на месте"? Как будет выглядеть метод "принять на работу" и где он будет расположен? В Employee? В Department? В WorkContract?

Там же, где и ты его написал. Но букаф в нём будет меньше.

S>Совершенно непонятно, откуда взялся Ok, при том что тебе даже в простых случаях нужно порождать отдельные DTO на каждый чих и оборудовать каждого toDTO/fromDTO.

Про то, что я был неправ с toDTO/fromDTO, мне уже объяснили. Но это ортогонально примеру с addChild() даже если от DTO не отказываться, а сделать внешний сериализатор, как объяснил Blazkowicz.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, Sinclair, Вы писали:

D>Вот я, кстати, надеялся, что ты, как веб-разработчик, наверняка с богатым опытом возни с DOM из javascript, меня поймёшь. Представь, что все эти операции addChild, createElement, createTextNode, сами по себе многословные до тошноты, в дополнение ко всему ещё пришлось бы вызывать через какой-то DOMController? Пальцы отсохнут.
А тебя не удивляет, что createXxx есть только у document? Который выступает, собственно, как DOM-factory?
Далее, здесь "DOM-контроллер" не нужен, потому как объекты DOM существуют ровно в одном месте, их жизненный цикл ограничен, а поведение определено.
S>> мы не предполагаем в бизнес-коде прямых вызовов типа d.addChild(e)
D>А почему, собственно?

Потому, что непонятно зачем. Какова семантика этого вызова? Если это перевод из отдела в отдел, то нужно убедиться, что у какого-то d2 был вызван removeChild(e). Кто за это будет отвечать? d.addChild()? или e.setParent()? А если setParent вызывается в процессе десериализации, то как нам его трактовать?

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Потому, что непонятно зачем. Какова семантика этого вызова?

Скажем так: я эмпирически поделил операции на высокоуровневые (собственно BL) и низкоуровневые (вся эта кухня с поддержкой иерархических структур и прочих мелочей типа ordered, filtered и т.п.). Высокоуровневые размещаются в контроллерах, как ты и нарисовал. Благодаря тому, что низкоуровневые инкапсулированы внутрь entities, они имеют немногословный интерфейс, в итоге BLL выглядит существенно компактнее и приятнее.

S>Если это перевод из отдела в отдел, то нужно убедиться, что у какого-то d2 был вызван removeChild(e). Кто за это будет отвечать? d.addChild()? или e.setParent()?

Да без разницы. Они оба относятся к слою кода, реализующему эту низкоуровневую абстракцию TreeNode.

S>А если setParent вызывается в процессе десериализации, то как нам его трактовать?

А вот это хороший аргумент.

Сижу пытаюсь вспомнить, почему я с этой ситуацией не сталкивался.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Там же, где и ты его написал. Но букаф в нём будет меньше.
За счёт чего именно в нём будет меньше букаф? Ты взял пример с одной строчкой. Действительно, если у объекта нет других обязанностей, кроме как хранить ссылку на родителя, то внешний контроллер не нужен. Но в жизни-то у него есть и другая работа.

D>Про то, что я был неправ с toDTO/fromDTO, мне уже объяснили. Но это ортогонально примеру с addChild() даже если от DTO не отказываться, а сделать внешний сериализатор, как объяснил Blazkowicz.
Нет, не ортогонально. Просто это еще одна обязанность — типа, "увеличить счётчик ссылок родителя", которую ты возлагаешь на этот объект. Это не работа employee. Работа employee — хранить информацию об employee.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>За счёт чего именно в нём будет меньше букаф? Ты взял пример с одной строчкой. Действительно, если у объекта нет других обязанностей, кроме как хранить ссылку на родителя, то внешний контроллер не нужен. Но в жизни-то у него есть и другая работа.

Я разве спорю? Но как говорится, тут строчка, там строчка... Дело в том, что с точки логики BL, разницы никакой. Я всё пытаюсь как-то донести эту простую мысль. Логика BL не изменится. А букв в низкоуровневой кухне станет меньше, вызываться она станет естественней. Уберётся TreeController, и суть не изменится вообще, только выглядеть всё станет проще.

Есть подозрение, что у тебя просто не было этой кухни в таком диком количестве, как у меня.

Я сейчас прикидываю иерархию на mixin-ах в lift, чтобы написать, к примеру, class Category extends DataMapper[Category] with TreeNode with Sorted with Filtered, и чтобы все эти поведения подцепились сами, с хорошим поведением по умолчанию даже при полном отстутствии соответствующих вызовов из BLL. Пока что не уверен, честно говоря, насколько хорошо это получится, но если получится, тогда я буду тихо молча праздновать победу (только не на форуме, а с бутылкой водки(зачёркнуто) лимонада).

S>Нет, не ортогонально. Просто это еще одна обязанность — типа, "увеличить счётчик ссылок родителя", которую ты возлагаешь на этот объект. Это не работа employee.

Верно. Это работа его базового класса TreeNode. Не вижу противоречий. Нормальная декомпозиция. (Язвительно: да, я в курсе, ООП и наследование используют только дураки. Но здесь оно ложится вполне по уму.)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Я с удовольствием проглотил и переварил Игорево решение, в котором ООП и не пахнет.
Почему ты так решил?

D> без намёка на конкретику применительно к моим примерам, которыми я тут всю ветку зафлудил.
Только половина твоих примеров никакого отношения к исходному вопросу не имеют.

Здравствуйте, dimgel, Вы писали:

D>А кто тебе сказал, что у меня ко всем данным, на которые я навешиваю логику, есть публичный доступ?
Потому что, если речь идет о персистентном хранении этих данных, то без публичного доступа к ним ты не обойдешься. Так как в противном случае, в твой бизнес объект придется "заинкапсулировать" взаимодействие со всеми возможными хранилищами, и вообще всеми подсистемами с которыми объект имеет дело.

D>Само по себе коллекционирование взаимосвязанных методов бизнес логики в одном месте — это, строго говоря, не инкапсуляция вообще.
Строго говоря, только ты и говорил, что это инкапсуляция, а вообще это называется когезия (cohesion)

Здравствуйте, IB, Вы писали:

D>>Я с удовольствием проглотил и переварил Игорево решение, в котором ООП и не пахнет.
IB>Почему ты так решил?

Прочитай ссылку на его пост, которую я тебе дал.

IB>Только половина твоих примеров никакого отношения к исходному вопросу не имеют.

Прочитай заголовок темы. Приведи примеры, имеющие отношение к исходному вопросу. Скажи что-нибудь умное по второй половине моих примеров. Короче, продемонстрируй интеллект.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>http://rsdn.ru/forum/message/476309.1.aspx
Это не IT сказал, что в его подходе нет ООП. Это IT в споре с AVK вспомнил, что когда-то Дон Бокс говорил, что ООП сосет для ряда задач.
Чувствуешь разницу?

D>У меня вообще складывается ощущение, что большинство здешних "гуру от архитектуры" нарочно запутывают простые вещи, чтобы утвердиться в собственной крутизне.
У меня складывается ощущение, что кто-то слишком много хамит в последнее время.

D> Многие ли тут способны повторить этот подвиг?
Просто перед Игорем ты испытываешь определенный пиетет и поэтому он единственный, кого ты прочитал внимательно.

Здравствуйте, IB, Вы писали:

IB>Потому что, если речь идет о персистентном хранении этих данных, то без публичного доступа к ним ты не обойдешься. Так как в противном случае, в твой бизнес объект придется "заинкапсулировать" взаимодействие со всеми возможными хранилищами, и вообще всеми подсистемами с которыми объект имеет дело.
Можно использовать рефлекшин, можно дать доступ к полям через определенный интерфейс, можно сделать protected доступ и генерить наследников, можно использовать вложенные классы для доступа... да мало ли что еще можно сделать

СУВ, Aikin

Здравствуйте, dimgel, Вы писали:

D>Прочитай ссылку на его пост, которую я тебе дал.
Я не о том спрашивал, я спросил, почему ты так решил. Мне интересно чем ты руководствовался, когда, проанализировав подход IT решил, что это не ООП. Расскажи, продемонстрируй интеллект.

D>Прочитай заголовок темы. Приведи примеры, имеющие отношение к исходному вопросу. Скажи что-нибудь умное по второй половине моих примеров. Короче, продемонстрируй интеллект.
Пока не вижу смысла бисер метать.

Здравствуйте, IB, Вы писали:

D>> Многие ли тут способны повторить этот подвиг?
IB>Просто перед Игорем ты испытываешь определенный пиетет и поэтому он единственный, кого ты прочитал внимательно.

Почему же единственный? Тут ещё минимум четыре человека, включая только что подключившегося Синклера, которые опускаются до разбора конкретных ситуаций. Тебя среди них, к сожалению, нет.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Aikin, Вы писали:

A>Можно использовать рефлекшин, можно дать доступ к полям через определенный интерфейс, можно сделать protected доступ и генерить наследников, можно использовать вложенные классы для доступа...
Ты эти варианты в серьез рассматриваешь?

A>да мало ли что еще можно сделать
Реалистичные решения будут?

Здравствуйте, IB, Вы писали:

IB>Мне интересно чем ты руководствовался, когда, проанализировав подход IT решил, что это не ООП. Расскажи, продемонстрируй интеллект.

Пожалуйста. Тем, что разобранный им конкретный пример чётко ложится в тот самый его пост, где "данные отдельно, алгоритмы отдельно" и "ООП идёт лесом".

IB>Пока не вижу смысла бисер метать.

А мне не трудно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, IB, Вы писали:

IB>Ты эти варианты в серьез рассматриваешь?
Рефлексию -- да (все остальное было добавлено для массовости). Обращение в базу настолько дорогая операция, что затраты на рефлексию можно не рассматривать.

СУВ, Aikin

Здравствуйте, dimgel, Вы писали:

D> Тем, что разобранный им конкретный пример чётко ложится в тот самый его пост,
Этот пост совсем про другое и совершенно по другому поводу.

D> где "данные отдельно, алгоритмы отдельно" и "ООП идёт лесом".
Так вот я и хочу, чтобы ты ответил на вопрос — почему ты считаешь, что если данные отдельно, а алгоритмы отдельно, то ООП идет лесом. Конкретно ты, а не IT, AVK или Дон Бокс.

D>А мне не трудно.
Да я вижу.

Здравствуйте, dimgel, Вы писали:

D>Почему же единственный? Тут ещё минимум четыре человека, включая только что подключившегося Синклера, которые опускаются до разбора конкретных ситуаций. Тебя среди них, к сожалению, нет.
Ну, то есть ты признаешься, что остальных ты все равно не читаешь..

Здравствуйте, IB, Вы писали:

D>> Тем, что разобранный им конкретный пример чётко ложится в тот самый его пост,
IB>Этот пост совсем про другое и совершенно по другому поводу.

Да ну? А мне показалось, что букафки похожи!

Не важно, по какому он поводу. Важно, что вполне подходит к рассмотренному здесь примеру. "По другому поводу" — это просто отмазка. Книжки с описаниями паттернов пишут тоже — каждый автор по своему поводу.

IB>Так вот я и хочу, чтобы ты ответил на вопрос — почему ты считаешь, что если данные отдельно, а алгоритмы отдельно, то ООП идет лесом.

Потому что это нарушение инкапсуляции данных. Да и наследованием там не пахнет. (Я не говорю, что оно там нужно, а что им там не пахнет.) То, что остаётся (инкапсуляция алгоритмов в BL-слоях) — это строго говоря не ООП, а модульное программирование. Если не согласен, изволь обосновать.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, Sinclair, Вы писали:

S>>Потому, что непонятно зачем. Какова семантика этого вызова?

D>Скажем так: я эмпирически поделил операции на высокоуровневые (собственно BL) и низкоуровневые (вся эта кухня с поддержкой иерархических структур и прочих мелочей типа ordered, filtered и т.п.). Высокоуровневые размещаются в контроллерах, как ты и нарисовал. Благодаря тому, что низкоуровневые инкапсулированы внутрь entities, они имеют немногословный интерфейс, в итоге BLL выглядит существенно компактнее и приятнее.

Круто, теперь каждый кто читает твой код должен понимать где ты провел границу между воскоуровневой и низкоуровневой логикой.

Nеперь по поводу работы с абстракциями типа TreeNode. Есть 3 варианта:
1)Дерево в интфейсе. Для этого существуют стандартные структуры, которые предоставляет сам компонент, рендерящий дерево. Данные для дерева совершенно необязательно должны быть в древовидной форме. Дерево вполне может являться результатом группировки по атрибутам.
2)Дерево нужно для реализации какого-то алгоритма, например AST для парсера. Тогда него не нужно растаскивать по контроллерам или чему-то еще. Только вряд ли оно в таком е виде будет ложиться в базу.
3)Сам данные имеют древовидную природу (как сообщения в форуме). Тут уже думать надо.

Рассмотрим на примере древовидного форума, так как ближе всего к твоему случаю.
Варианты использования:
1)Добавление узла к заданному узлу (заданный узел может быть NULL — происходит создание темы)
2)Получение узлов с заданным предком (в том чиле NULL)
3)Получение всех потомков заданного узла
4)Перемещение поддерева к другому родителю (применяется при выносе одной темы из другой)

Для 1) 2) 4) идеально подходит наивная реализация дерева в базе — ссылкой на родителя.
Для 3) — решается с помощью CTE, а это долго работает, поэтому можно результаты кешировать (таблица потомков), но при этом придется их пересчитывать в сценариях 1) и 4).
Другой вариант — держать в кажом посте ссылку на "тему", тогда сценарий 3) будет элементарным, но придется пересчитывать в сценарии 4) (будет один update по выборке с CTE).
Так как в форуме сценарий 4) встречается в тыщу раз реже других, то лучше выбрать второй вариант.

Все дейсвтия по изменению данных можно выполнять как в клиентком коде, изменяя объекты и сохрняя их в БД с помощью какого-либо ORM, так и в SQL.

Далее если хотим добавить счетчики ответов на данное сообщение, и количество ответов в поддереве, то лучше эти счетчики кешировать в узлах. Тогда у нас подвергнутся влиянию сценарии 1) и 4).

При добавлении элемента надо непосредсвенному родителю добавить единицу в счетчик детей, а всем предкам добавить по единице в счетчики потомков. Это можно делать как в триггере не добавление, так и в коде, даже с загрузкой объектов.
При перемещении элементов надо у непосредственного родителя отнять единицу в счетчике детей. А у все предков счетчик потомков уменьшить на
количество потомков перемещаемого элемента. Это также можно сделать с помощью триггеров или кода.

Я бы сделал на триггерах все это безобразие, в том числе изменение ссылки на "тему". ИМХО это является вопросом целостности данных, вот пусть база вопросми целостности и занимается.

При этом всем указанные выше 4 сценрия не выполняются одновременно, для каждого из них выполняется вполне конкретная последовательность действий, приводящая к желаемому резльтату. Поэтому мне не нужны обобщенные инструменты для работы с деревьями в БД, с поддержанием целостности на клиенте.

Любые потребности применения деревьев в БД можно расписать по таким сценариям. Обобщенный код по работе с деревьями вряд ли понадобится.

ЗЫ. Главное не зацикливаться на деревьях. На одном из проектов (интернет магазин) фраза менеджера про "дерево каталога" так проела мозг программистам, что в течение нескольких месяцев не могли придумать адекватную структуру хранения. В итоге сделали каталог вообще без намека на древообразные структуры.

Здравствуйте, dimgel, Вы писали:

D> Важно, что вполне подходит к рассмотренному здесь примеру.
В том-то и дело, что не подходит. Ты просто фразу из контекста вырвал, где слова знакомые, в суть не вникая.

D>Потому что это нарушение инкапсуляции данных.
Почему это нарушение? Точнее так: как ты понимаешь инкапсуляцию и почему такой подход ее нарушает?

D> Да и наследованием там не пахнет.
По твоему, если паттерн не использует наследования, значит это не ООП паттерн?
Тебя не смущает, что половину GOF в этом случае можно от ООП отлучить?

D> То, что остаётся (инкапсуляция алгоритмов в BL-слоях) — это строго говоря не ООП, а модульное программирование.
Почему это не ООП, и что ты понимаешь под ООП?

D> Если не согласен, изволь обосновать.
Я это и пытаюсь сделать уже на протяжении нескольких постов. Просто бесполезно тебе что-то объяснять, пока ты базовых вещей не уяснишь... Собственно, твои требования конкретики из той же оперы — ты опять понадергаешь из контекста не разобравшись, так и не поняв, почему и зачем. Ну и какой смысл разоряться?

Здравствуйте, Aikin, Вы писали:

A>Рефлексию -- да (все остальное было добавлено для массовости). Обращение в базу настолько дорогая операция, что затраты на рефлексию можно не рассматривать.
Дело не в дороговизне (хотя и тут не все так просто), одного переноса контроля типов в рантайм достаточно, чтобы не рассматривать этот вариант в серьез.

Здравствуйте, MozgC, Вы писали:

MC>Хорошо расписал всё. А можешь высказать свое мнение по обсуждению в соседней ветке:
MC>http://rsdn.ru/forum/message/3385318.1.aspx (начиная отсюда и до конца)

Ответ на вопрос стоит ли тестировать код с БД или нет будет разным в каждой конкретной ситуации. Я тестирую и так и так, а иногда вообще никак, если это неадекватно по затратам. В BLToolkit я не просто тестирую с БД, я тестирую одновременно 11 серверов, т.к. должен быть уверен, что, например, функция CharIndex или её аналог работает везде. Но все тесты, включая сложные джоины делаются на одной таблице с двумя записями

Так что времени это много не занимает. Некоторые длинные процессы на работе я тестирую без БД, т.к. если я подключу реальные данные, то каждый запуск будет мне стоить 30 минут жизни.

MC>Я допускаю, что я тоже в силу меньшего опыта могу чего-то не понимать, но, повторюсь, я к примеру часто использую в BLL & DAL статические классы и за несколько лет это мне никаких проблем не принесло. Мне же говорят что нужно использовать интерфейсы с DI, и для меня это выглядит как твой пример с IOutputer и IFormatter — я не вижу необходимости в этом, абсолютно.

DI это не новый паттерн, но популярность он получил в последнее время как раз благодаря автоматическому тестированию и массово используется в основном для этого. Если ты решишь, что для тестов тебе нужны моки, то задумайся об использовании DI. Иначе нафига козе баян.

Здравствуйте, dimgel, Вы писали:

D>Помнится, IT честно говорил, что в его архитектуре ООП с инкапсуляцией идут лесом.

В моей архитектуре ООП и инкапсуляция это такие же инструменты и паттерны как и всё остальное, как DI, DAL, BL, прочая слоёность, MVC, MVP, FP, MP и прочая. А инструменты я выбираю наиболее подходящие под каждую конкретную задачу. И если ООП где-то пощёл лесом, то это значит только одно — он мне не подошёл в конкретном случае для решения конкретной задачи. Вобще же, некоторые меня критикуют за излишнюю приверженность к таким вещам как наследование. Может быть, но если мне это удобнее и проще, то в лес идут критиканты, а если не удобно или сложнее, то в лес идёт ООП и всё остальное.

Здравствуйте, IB, Вы писали:

D>> Важно, что вполне подходит к рассмотренному здесь примеру.
IB>В том-то и дело, что не подходит. Ты просто фразу из контекста вырвал, где слова знакомые, в суть не вникая.

Это бла-бла-бла.

D>>Потому что это нарушение инкапсуляции данных.
IB>Почему это нарушение? Точнее так: как ты понимаешь инкапсуляцию и почему такой подход ее нарушает?

Я думал, с инкапсуляцией мы выше разобрались. Тебе нужно объяснять, что торчащие наружу данные являются нарушением инкапсуляции данных? Следующий.

D>> Да и наследованием там не пахнет.
IB>По твоему, если паттерн не использует наследования, значит это не ООП паттерн?
IB>Тебя не смущает, что половину GOF в этом случае можно от ООП отлучить?

Не смущает. Там половина паттернов к ООП вообще не относится. На вскидку, тот же посетитель или стратегия — вещи из мира ФП, которые они прикрутили к ООП.

D>> То, что остаётся (инкапсуляция алгоритмов в BL-слоях) — это строго говоря не ООП, а модульное программирование.
IB>Почему это не ООП, и что ты понимаешь под ООП?

Только что написал.

D>> Если не согласен, изволь обосновать.
IB>Я это и пытаюсь сделать уже на протяжении нескольких постов. Просто бесполезно тебе что-то объяснять, пока ты базовых вещей не уяснишь... Собственно, твои требования конкретики из той же оперы — ты опять понадергаешь из контекста не разобравшись, так и не поняв, почему и зачем. Ну и какой смысл разоряться?

И это бла-бла-бла.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, IB, Вы писали:

IB>Ты просто фразу из контекста вырвал, где слова знакомые, в суть не вникая.
IB>Просто бесполезно тебе что-то объяснять, пока ты базовых вещей не уяснишь... Ну и какой смысл разоряться?

Вот к этому и сводятся все твои аргументы. "Ты дурак и потому объяснять тебе бесполезно."

IB>Я это и пытаюсь сделать уже на протяжении нескольких постов.

Единственный твой вклад в данное обсуждение — это строгое определение инкапсуляции. Остальные посты — бла-бла-бла и понты.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, IT, Вы писали:

IT>И если ООП где-то пощёл лесом, то это значит только одно — он мне не подошёл в конкретном случае для решения конкретной задачи.

Вот я и пытаюсь всё время говорить о конкретной задаче. О той, которую ты разобрал (других тут не проскакивало). С точки зрения IB это выглядит, по-видимому, так: "мы тут, панимаешь, сидим в своём болоте, квакаем о высоких материях, тут приходит какой-то лось, срёт всем на головы и портит малину своими идиотскими требованиями конкретики". С моей же точки зрения это выглядит как разговор со свидетелями Иеговы, которые мастера говорить о высоких материях, знают трактовку каждой буквы в обоих Заветах, но столкни их носом к носу с самым простеньким конкретным чудом, загремят либо в дурку, либо на кладбище.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, IB, Вы писали:

IB>Дело не в дороговизне (хотя и тут не все так просто), одного переноса контроля типов в рантайм достаточно, чтобы не рассматривать этот вариант в серьез.

Эх, столкнуть бы тебя сейчас с Мамутом, защищавшим не так давно динамически типизированные языки...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, gandjustas, Вы писали:

G>Круто, теперь каждый кто читает твой код должен понимать где ты провел границу между воскоуровневой и низкоуровневой логикой.

На самом деле там весьма просто. Я ж несколько раз уже приводил примеры того, что я называю низкоуровневыми конструкциями. Количество этих конструкций ограничено.

G>Рассмотрим на примере древовидного форума, так как ближе всего к твоему случаю.
G>Варианты использования:
G>.............
G>Любые потребности применения деревьев в БД можно расписать по таким сценариям.

Всё отлично расписал. ППКС.

G>Обобщенный код по работе с деревьями вряд ли понадобится.

Мне одному начинает казаться, что мы спорим, с какого конца чистить яйцо?

По сути-то — что в триггерах, что в TreeController, что у меня в базовом классе TreeNode — это отдельный слой. Разница в сущности только в сигнатуре вызова. Не находишь?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

IT>>И если ООП где-то пощёл лесом, то это значит только одно — он мне не подошёл в конкретном случае для решения конкретной задачи.

D>Вот я и пытаюсь всё время говорить о конкретной задаче. О той, которую ты разобрал (других тут не проскакивало). С точки зрения IB это выглядит, по-видимому, так: "мы тут, панимаешь, сидим в своём болоте, квакаем о высоких материях, тут приходит какой-то лось, срёт всем на головы и портит малину своими идиотскими требованиями конкретики". С моей же точки зрения это выглядит как разговор со свидетелями Иеговы, которые мастера говорить о высоких материях, знают трактовку каждой буквы в обоих Заветах, но столкни их носом к носу с самым простеньким конкретным чудом, загремят либо в дурку, либо на кладбище.

Во-первых, успокойся, твоя агрессия уже начинает надоедать.

Во-вторых, я тебе не просто так говорил о шкале сложности и о том, что в разных её точках решения могут быть принципиально разными. Это надо понимать не только тем, кто тебе что-то объясняет, но и тебе самому, чтобы лучше понять то, что тебе объясняют. Ситуации действительно бывают разные и поиск универсального решение для всех случаев — это очень нетривиальная задача. Когда тебе говорят о применении того или иного паттерна, то самый простой способ решить подходит он тебе или нет это задать вопрос себе и твоему собеседнику — а какую проблему решает то или иное средство. Может вполне оказаться, что в твоём конкретном случае такой проблемы нет вообще. Этот вопрос, кстати, вообще полезно почаще задавать. Ответ на него помогает более точно выявлять проблемы и, возможно, решать их другими более эффективными способами. Например, в твоём примере оказалось, что разные DTO решают совсем другую проблему, чем ты думал. Ты думал (и аргументировал), что так лучше для целей безопасности, а оказалось, что используя один и тот же тип объекта получается облом с кешированием.

В-третьих, не стоит относится пренебрежительно к высокоумным, как тебе кажется, постам. Есть одна очень правильная поговорка — неясность изложения свидетельствует о путанице в мыслях. Пока ты не сможешь ясно, чётко и главное кратко сформулировать проблему, это будет означать только одно — ты её сам не доконца понимаешь. Абстрактные определения помогают оторвать проблему от конкретики, чётко её сформулировать и применить к другим конкретным случаям и решить уже в них конкретную проблему. Другое дело, что абстакцию бывает сложно понять без конкретных примеров, но это нужно учиться делать по той причине, что абстракций значительно меньше, чем конкретики и, если оставаться только на уровне конкретных примеров, то в них можно легко утонуть и окончательно запутаться.

Когда я вижу хорошее абстрактное определение, то я его всегда плюсую (не всегда мышкой, иногда просто для себя), т.к. такие определения помогают мне самому более чётко сформулировать проблему, оторвать её от моей конкретной конкретики и, в результате, начать выявлять подобные вещи в более широком круге задач. Ты же пытаешься закопаться в своей песочнице и ни с кем не дружить, потому что твой кулич из твоего конкретного песка кажется тебе самым идеальным в мире решением.

Здравствуйте, dimgel, Вы писали:
...
Н>>Объект выставляет наружу минимально необходимый контракт (приницип минимизации публичного контракта), все остальное -- внешнее по отношению к нему.

D>Даже если это остальное не делает ничего, кроме как делегирует к методам обсновного объекта?

Да, но это не имеет отношения к минимизации. Зачем плясать от реализации, которая вторична по отношению к контрактам? Всякие приватные поля, "обсновные объекты" — это артефакты реализации контракта. Даже выражения вроде "эта сущность содержит приватное поле, которое хранит X" с этой точки зрения не имеют собого смысла до тех пор, пока не сказано(например) что, во-первых — существуют методы 'get_X'/'set_X' и во-вторых, — 'get_X' возвращает то что передали в 'set_X'. И уже из таких(не вышеперечисленных, а вообще) утверждений вытекает необходимость иметь приватное поле для обеспечения контракта.

Здравствуйте, dimgel, Вы писали:

G>>Обобщенный код по работе с деревьями вряд ли понадобится.

D>Мне одному начинает казаться, что мы спорим, с какого конца чистить яйцо?

Нет, разница в применяемых средствах. То что в SQL делается элементарно, в клиентском коде делается очень тяжело. А при поптыке поддерживать честную согласованную модель БД очень много усилий тратится на то что в БД есть по-умолчанию.

Здравствуйте, gandjustas, Вы писали:

G>Нет, разница в применяемых средствах. То что в SQL делается элементарно, в клиентском коде делается очень тяжело. А при поптыке поддерживать честную согласованную модель БД очень много усилий тратится на то что в БД есть по-умолчанию.

Снова не могу не согласиться. Но это только одна сторона проблемы. Здесь чаще бытует другая точка зрения: размывать логику между хранимками+триггерами и "основным приложением" не есть гуд.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Юрий Жмеренецкий, Вы писали:

Н>>>Объект выставляет наружу минимально необходимый контракт (приницип минимизации публичного контракта), все остальное -- внешнее по отношению к нему.

D>>Даже если это остальное не делает ничего, кроме как делегирует к методам обсновного объекта?

ЮЖ>Да, но это не имеет отношения к минимизации. Зачем плясать от реализации, которая вторична по отношению к контрактам?

Хм. Вообще-то этот вопрос правомерно задавать как раз адептам принципа минимизации публичного контракта, поскольку в нём уже прописана определённая зависимость от реализации. Я ничтоже сумняшеся нашпигую класс методами get_X, set_X и прочими, если они мне покажутся там уместными. И наплюю на минимизацию. Или я не так понял?

UPD:
Я пропустил: "даже если собственно X у меня отсутствует". Я тут зациклился на счётчиках, поэтому никак не могу вспомнить другие случаи скрытых данных, которые из интерфейса entity не видны. Но в целом я именно что пытаюсь плясать от интерфейса. Во, вспомнил пример: public isPublished() { return whenPublished != null; } Поскольку для whenPublished тоже есть геттер, на лицо избыточность интерфейса. Зато так удобнее.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>Нет, разница в применяемых средствах. То что в SQL делается элементарно, в клиентском коде делается очень тяжело. А при поптыке поддерживать честную согласованную модель БД очень много усилий тратится на то что в БД есть по-умолчанию.

D>Снова не могу не согласиться. Но это только одна сторона проблемы. Здесь чаще бытует другая точка зрения: размывать логику между хранимками+триггерами и "основным приложением" не есть гуд.

Ты не понял, я говорю не о месте расположения логики. SQL запросы можно и в коде программы формировать, только неудобно это. Linq в C#\VB\Nemerle решает.

Что касается триггеров, то это отдельный вопрос. БД поддерживает целостность данных. Если надо нарушать нормализацию для ускорения, то поддерживать целостность лучше внутри БД, а не в коде приложения.

Здравствуйте, gandjustas,

Ок, только я бы не стал ограничивать использование триггеров поддержкой целостности базы. Взять например, паттерн "документы-регистры", на котором построена 1С-торговля. Работу по пересчёту остатков регистров (текущих и промежуточных кешированных) после проведения документа — сам бог велел отдать на сторону сервера: там ворочаются огромные объёмы данных, а приложению возвращается void.

Но есть ещё одна чисто техническая проблема с кодом на стороне SQL-сервера, неведомая счастливым адептам чистого stateless: необходимость тонко сбрасывать entity cache. Т.е. мы знаем, что триггеры обновили счётчики у предков узла, значит закешированные предки уже не валидны.

Блин, вот скажите мне, почему при таком огромном количестве неудобств, stateful настолько распространён и имеет столь широкую инструментальную поддержку. Щас вот смотрю lift — дык он не просто stateful, он даже данные сессий и контексты ajax callbacks в памяти держит. (Это дефолтное поведение "для начинающих", не знаю, что из него можно будет выжать при дальнейшем изучении.) А у меня на VPS памяти 384 метра всего, половина под IPB-форумом товарища.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Работу по пересчёту остатков регистров (текущих и промежуточных кешированных) после проведения документа — сам бог велел отдать на сторону сервера

*SQL-сервера.
И таким образом, хороший такой кусок бизнес-логики у нас благополучно уплывает из контроллеров в базу.

А разработчику приложения остаётся лишь убогий выбор, куда поместить executeStoredProc(): в DocumentController.post(doc) или Document.post().

И пришли мы туда, откуда начали.

Похоже, я твоего последнего поста не понял.

И кстати, ещё один аргумент против кода на стороне SQL-сервера: у них у всех диалекты разные.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas,

D>Ок, только я бы не стал ограничивать использование триггеров поддержкой целостности базы. Взять например, паттерн "документы-регистры", на котором построена 1С-торговля. Работу по пересчёту остатков регистров (текущих и промежуточных кешированных) после проведения документа — сам бог велел отдать на сторону сервера: там ворочаются огромные объёмы данных, а приложению возвращается void.
Неверно. Логика проведения документов обычно нетривиальная, достаточно часто меняется. Держать её в базе — самоубийство.
А само проведение конечно лучше отдать серверу. На клиенте формировать батч sql-команд и заставлять все это выполняться на сервере.
К сожалению современные ORM так не умеют.

D>Но есть ещё одна чисто техническая проблема с кодом на стороне SQL-сервера, неведомая счастливым адептам чистого stateless: необходимость тонко сбрасывать entity cache. Т.е. мы знаем, что триггеры обновили счётчики у предков узла, значит закешированные предки уже не валидны.
А это ты сам себе придумал сложности с кешированием. Используй кеширование вызовов метода и инвалидацию по LastModified.
В случае того же форума реализуется элементарно.
Вообще полновесная ОО-модель плохо работает с кешированием, зачастую заставляя дублировать функции БД в памяти.

D>Блин, вот скажите мне, почему при таком огромном количестве неудобств, stateful настолько распространён и имеет столь широкую инструментальную поддержку.
Где? В real-world stateful не рулит вообще.

D>Щас вот смотрю lift — дык он не просто stateful, он даже данные сессий и контексты ajax callbacks в памяти держит. (Это дефолтное поведение "для начинающих", не знаю, что из него можно будет выжать при дальнейшем изучении.) А у меня на VPS памяти 384 метра всего, половина под IPB-форумом товарища.
Ну не используй левые либы.
Я буквально за полгода разобрался где чего надо использовать, чтобы жизнь была хороша.

Здравствуйте, gandjustas, Вы писали:

G>Неверно. Логика проведения документов обычно нетривиальная, достаточно часто меняется. Держать её в базе — самоубийство.

Не-не-не Дэвид Блэйн! Я ни в коем случае не говорю про логику проведения документов! Только пересчёт остатков после того, как при проведении документа задним числом (кодом BL) были записаны обороты.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>Неверно. Логика проведения документов обычно нетривиальная, достаточно часто меняется. Держать её в базе — самоубийство.

D>Не-не-не Дэвид Блэйн! Я ни в коем случае не говорю про логику проведения документов! Только пересчёт остатков после того, как при проведении документа задним числом (кодом BL) были записаны обороты.
Дык для этого вообще-то индексированные вьюхи есть. Или вообще Integration Services + Analisys Services или аналогичне инструменты в других СУБД.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, Юрий Жмеренецкий, Вы писали:

Н>>>>Объект выставляет наружу минимально необходимый контракт (приницип минимизации публичного контракта), все остальное -- внешнее по отношению к нему.

D>>>Даже если это остальное не делает ничего, кроме как делегирует к методам обсновного объекта?

ЮЖ>>Да, но это не имеет отношения к минимизации. Зачем плясать от реализации, которая вторична по отношению к контрактам?

D>Хм. Вообще-то этот вопрос правомерно задавать как раз адептам принципа минимизации публичного контракта, поскольку в нём уже прописана определённая зависимость от реализации. Я ничтоже сумняшеся нашпигую класс методами get_X, set_X и прочими, если они мне покажутся там уместными. И наплюю на минимизацию. Или я не так понял?

Под реализаций я имел ввиду приватные члены, в частности "основной объект". Его наличие — это часть реализации. Поэтому он не должен учитываться при обсуждении контракта, т.к. этот объект является производным от него(контракта).

D>UPD:
D>Я пропустил: "даже если собственно X у меня отсутствует". Я тут зациклился на счётчиках, поэтому никак не могу вспомнить другие случаи скрытых данных, которые из интерфейса entity не видны.
А откуда видны? Или на самом деле entity реализует два интерфейса?

D>Но в целом я именно что пытаюсь плясать от интерфейса. Во, вспомнил пример: public isPublished() { return whenPublished != null; } Поскольку для whenPublished тоже есть геттер, на лицо избыточность интерфейса. Зато так удобнее.

Членом какой сущности является isPublished? Судя по названию(гадая) это "внешнее" по отношению к объекту свойство (как и whenPublished). Впрочем, пока удобно можно и пользоваться =)

Можно с такой стороны посмотреть: берем какой-нибудь тип, смотрим на все его геттеры. Декартово произведение все значений, которые в совокупности можно получить от этих геттеров — это все возможные состояния нашего объекта. Теперь делим это состояние на несколько, в соответствии с возможностью вызова некоторых функций (это, кстати полезно для тестирования). Например, для контейнера это будут три "области" — пустой, непустой и полный. В пустом не определена операция удаления, в полном вставка, в непустом обе возможны. Что должны делать функции, которые не определены? Обычно они кидают исключения, иногда просто в документации пишут "нельзя и все, сами будете виноваты", либо это приводит к холостому вызову. + добавляют функции, с помощью которых можно узнать в какой "области" находится объект [Замечание: вызов функции вне ее области — это всегда хуже чем отсутствие вызова]. Например, 'Count' — количество элементов в контейнере, с помощью этого одного свойства в принципе можно определить нужную область, но еще необходимо знать максимальное количество. Заполнение контейнера под завязку — чрезвычайно редкая ситуация, поэтому каждый раз перед вставкой проверять на IsFull никто не будет. С Empty другая ситуация — пустым контейнер бывает часто (может быть каждый раз после создания). + Еще один довод: Empty может быть(иногда) реализована эффективнее нежели 'Count == 0'. Это по поводу избыточности.

Вызов whenPublished на самом деле определен только если isPublished == true, поэтому isPublished является образующей двух _разных_ областей состояний в отношении whenPublished, и в одной области вызов неопределен(значение не имеет смысла, тот факт что по нему можно судить о состоянии свойства isPublished — это побочный эффект реализации). Поэтому, как вариант — whenPublished должна кидать исключение если isPublished == false, т.е. null она никогда не должна возвращать. Из-за этого мы бесплатно получаем гарантию того, что кто-нибудь где-нибудь забудет выполнить проверку на null значения полученного от whenPublished (эта проверка становится ненужной). Вот в этом случае оба этих свойства имеют право существовать в интерфейсе одновременно. Иначе — действительно избыточность =)

Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Членом какой сущности является isPublished? Судя по названию(гадая) это "внешнее" по отношению к объекту свойство (как и whenPublished). Впрочем, пока удобно можно и пользоваться =)

Технически, whenPublished находится в таблице, которую мапит объект. Идеологически, это скажем статья в контент сайте, так что приемлемо.

ЮЖ>whenPublished должна кидать исключение если isPublished == false, т.е. null она никогда не должна возвращать.

Яя, майн группенфюрер!

Правда, делал я это больше по наитию, спасибо за хорошую формализацию с "областями состояния".

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Эх, столкнуть бы тебя сейчас с Мамутом, защищавшим не так давно динамически типизированные языки...
Опять ты все в одну кучу мешаешь. Динамическая типизация и рефлекшен — две большие разницы, хотя проблемы схожи.

Здравствуйте, dimgel, Вы писали:

D>Это бла-бла-бла.
Это просто ты читать не умеешь.. )

D>Я думал, с инкапсуляцией мы выше разобрались.
Ты, как я вижу, еще не разобрался..

D> Тебе нужно объяснять, что торчащие наружу данные являются нарушением инкапсуляции данных?
Для начала я хочу услышать от тебя, что такое инкапсуляция данных и где ты вообще взял этот термин.
А потом хочу услышать зачем ты вообще используешь инкапсуляцию и чего пытаешься этим добиться.

D>Не смущает. Там половина паттернов к ООП вообще не относится.

Я с возрастающим интересом хочу услышать от тебя, что ты понимаешь под ООП..

D>Только что написал.
Где?

D>И это бла-бла-бла.
Ты бы лучше на вопросы отвечал.

Здравствуйте, dimgel, Вы писали:

D>Вот к этому и сводятся все твои аргументы. "Ты дурак и потому объяснять тебе бесполезно."
Я пока еще пытаюсь выяснить с чего начинать объяснения, а ты сопротивляешься.

D>Единственный твой вклад в данное обсуждение — это строгое определение инкапсуляции. Остальные посты — бла-бла-бла и понты.
"Мальчик" (с), ты сначала подумай, каков твой вклад в это обсуждение, потом поговорим.

IB>>По твоему, если паттерн не использует наследования, значит это не ООП паттерн?
IB>>Тебя не смущает, что половину GOF в этом случае можно от ООП отлучить?

D>Не смущает. Там половина паттернов к ООП вообще не относится. На вскидку, тот же посетитель или стратегия — вещи из мира ФП, которые они прикрутили к ООП.

Тезис собственно такой: единственная существенная польза от ООП, благодаря которой его все используют, — это полиморфизм.

Аргументация будет в духедоказательства, что 60 делится на все числа.

Сначала про некоторые паттерны GoF, для разгона.

1. Посетитель. В функциональном языке это просто суперпозиция функций:

def walkTree(root: TreeNode, visitor: TreeNode => Unit)

Здесь второй параметр функции walkTree() — это функция, берущая параметром TreeNode и возвращающая Unit (это типа void в scala). Глядя на эту строчку, я думаю, а стоило ли придумывать отдельное название для такой элементарной вещи? Не скажу "классический", но какой-то смутно и до боли знакомый эффект усложнения простых вещей, возникающий при переносе их в чуждое окружение.

2. Фасад. К ООП не привязан: я могу взять и наплодить группу глобальных функций и обозвать её фасадом, спрятав за ними другую группу глобальных функций.

3. Стратегия. Вот тут начинается интересное. В вырожденном случае, когда контракт стратегии состоит из одного метода, получаем точную копию посетителя — обычную суперпозицию функций. А в невырожденном мы автоматически приходим к интерфейсу (или базовому классу), то есть к полиморфизму.

Почему я приравниваю использование ООП-интерфейсов к использованию полиморфизма? Я вижу только две задачи, которые решают ООП-интерфейсы: сокрытие реализации и полиморфизм. Но сокрытие реализации чудненько реализуется и в модульном программировании. В том же C, насколько я помню, был модификатор static, который переводится как "module-visible". Вот вам и контракт, и сокрытие реализации. И не надо ООП-огород городить.

Получится прорва глобальных функций? Нет проблемы, вводим пространства имён. Эта фича не является прерогативой ООП. В XML помнится тоже есть пространства имён. Правда, XML namespaces — это анархия вместо иерархии, в то время как в java и других языках пространства имён строго иерархические и на этом завязаны ограничения доступа (visibility). Но полноценные иерархические имена при желании можно сделать и для не-ООП языка. Сделали же модификатор static в C; да и в C++ namespaces живут сами по себе и вроде бы даже могут быть многокомпонентными (если не ошибаюсь).

Тогда почему даже в программах, где "ООП и не пахнет" (с) мой, народ всё равно усиленно плодит классы, интерфейсы и объекты? Я вижу две причины:

1) Полиморфизм, который может не использоваться в архитектуре программы, активно используется в процессе разработки, а именно при тестировании. Нужно подменить рабочий функционал моками? — опа! опять полиморфизм.

2) Используемые библиотеки. Разработчики современных библиотек стараются делать их максимально гибкими, pluggable, а это достигается использованием паттернов, интенсивно использующих полиморфизм; той же стратегии. (Сейчас я держу в голове стандратные либы java — образец гибкости; для функциональных языков формулировочка аргумента может быть несколько иной.)

Ещё несколько паттернов.

4. Синглтон. Неприятный для моих аргументов контрпример. Но хочу заметить, считается антипаттерном!

Часто синглтон используется как корневой объект (Application). Почему не кучка глобальных методов? Во-первых, для унификации, а во-вторых, в skeleton-фреймворках он наследуется из какого-нибудь framework.BasicApplication (в дельфи кажись так было), то есть опять эксплуатируется полиморфизм.

5. Service Provider Interfaces, в т.ч. многоуровневые. Как оформить корневую точку входа — глобальной функцией, методом класса Application или статическим методом (синглтоном) — не принципиально. А дочерние SPI всегда эксплуатируют полиморфизм (иначе паттерн просто теряет смысл).

6. Сериализация. Универсальный рекурсивный алгоритм, использующий рефлексию, опирается на факт существования полиморфного метода getClass().

Вроде бы всё вспомнил, что хотел. Если у кого-нибудь есть пример use-case, опровергающий мои построения, или другие соображения — буду признателен.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, IB, Вы писали:

IB>одного переноса контроля типов в рантайм достаточно, чтобы не рассматривать этот вариант в серьез.
Я, наверное, торможу.
О каком контроле типов может идти речь, когда sql нетипизирован (мы ведь говорим про персистентность). Когда схема базы может измениться независимо от приложения.

ИМХО, в любом случае, используем ли мапер или все делаем ручками, контроль соответствия базы приложению можно осуществить только тестами.

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

A>ИМХО, в любом случае, используем ли мапер или все делаем ручками, контроль соответствия базы приложению можно осуществить только тестами.
Ну что за бред.
Проконтролироать это можно только на одной машине, никто вам не сможет гарантировать что у пользователя будет база соотвествовть приложению.

Надо или код проверочный включить в само приложение, но это уже будет не тест, или забить на все это дело.

Здравствуйте, gandjustas, Вы писали:

A>>ИМХО, в любом случае, используем ли мапер или все делаем ручками, контроль соответствия базы приложению можно осуществить только тестами.
G>Ну что за бред.
G>Проконтролироать это можно только на одной машине, никто вам не сможет гарантировать что у пользователя будет база соотвествовть приложению.
Я где-то утверждаю обратное?

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>ИМХО, в любом случае, используем ли мапер или все делаем ручками, контроль соответствия базы приложению можно осуществить только тестами.
G>>Ну что за бред.
G>>Проконтролироать это можно только на одной машине, никто вам не сможет гарантировать что у пользователя будет база соотвествовть приложению.
A>Я где-то утверждаю обратное?

Фраза "контроль соответствия базы приложению можно осуществить только тестами" утверждает обратное.

Здравствуйте, Aikin, Вы писали:

A>О каком контроле типов может идти речь, когда sql нетипизирован (мы ведь говорим про персистентность).
1. Допустим про персистентность — SQL конечно не типизирован, но есть две большие разницы, generic-маппинг через рефлекшен один раз написать, или каждый класс расписывать через рефлекшен — ты предлагаешь второе. И тут отмазка про то что SQL и так не типизирован, не пройдет, тут тебе рефлекшен боком встанет.
2. Персистентность может быть не только в БД, а в тот же XML, тоже заново все писать будешь, через рефлекшен?
3. А если объект куда передать надо, по веб-сервису например?
4. У тебя же объект создается не только для того, чтобы быть сохраненным в базе, наверное он еще для чего-то нужен? Это что-то ты тоже собираешься через рефлекшен делать?

A>ИМХО, в любом случае, используем ли мапер или все делаем ручками, контроль соответствия базы приложению можно осуществить только тестами.
Речь не о том, что используем маппер или нет, а о том, что в реальных приложениях если у тебя объект куда либо сериализуется (не важно, в базу ли, в XML, на диск...) то все его данные которые нужно персистить находятся в публичном доступе.
Понятно, что при желании можно их спрятать и придумать тридцать-три способа их извлечения в зависимости от ситуации, но практического смысла в этом нет.

Здравствуйте, dimgel, Вы писали:

D>Если у кого-нибудь есть пример use-case, опровергающий мои построения, или другие соображения — буду признателен.
Ты прежде чем в юз-кейсы влезать и примеры требовать, сначала сам определись что хочешь понять/доказать и о чем вообще речь-то идет.. )
Можно начать с определения ООП, а то из твоих тезисов оно не прослеживается.

Здравствуйте, gandjustas, Вы писали:

G>Фраза "контроль соответствия базы приложению можно осуществить только тестами" утверждает обратное.
Не вижу смысла в продолжении дискуссии. Твое уточнение никакой пользы не дает.

СУВ, Aikin

Здравствуйте, IB, Вы писали:

IB>generic-маппинг через рефлекшен один раз написать, или каждый класс расписывать через рефлекшен — ты предлагаешь второе.
Я говорю про генерик-маппинг + метаданные. Второе тоже возможно, но мне это в голову даже не приходило.

IB>2. Персистентность может быть не только в БД, а в тот же XML, тоже заново все писать будешь, через рефлекшен?
IB>3. А если объект куда передать надо, по веб-сервису например?
IB>4. У тебя же объект создается не только для того, чтобы быть сохраненным в базе, наверное он еще для чего-то нужен? Это что-то ты тоже собираешься через рефлекшен делать?
Не нужно раздувать вполне конкретное применение способа (для воссоздания объекта из базы) на общий случай.

IB>Речь не о том, что используем маппер или нет, а о том, что в реальных приложениях если у тебя объект куда либо сериализуется (не важно, в базу ли, в XML, на диск...) то все его данные которые нужно персистить находятся в публичном доступе.
Вот с этим я и спорю.
IB>Понятно, что при желании можно их спрятать и придумать тридцать-три способа их извлечения в зависимости от ситуации, но практического смысла в этом нет.
А мне нравится

СУВ, Aikin

Здравствуйте, dimgel, Вы писали:

D>Тезис собственно такой: единственная существенная польза от ООП, благодаря которой его все используют, — это полиморфизм.
Полиморфизм в функциональных языках так же отлично реализуется.

ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки.

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

A>Здравствуйте, dimgel, Вы писали:

D>>Тезис собственно такой: единственная существенная польза от ООП, благодаря которой его все используют, — это полиморфизм.
A>Полиморфизм в функциональных языках так же отлично реализуется.

Можно конкретный пример, посложнее моего с посетителем? То, что реализуется, я подозреваю, но не знаю как это выглядит на практике. В голове усиленно крутится только реализация на прологе, который вообще из третьей оперы, и мне оно представляется несколько более громоздким.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>1. Посетитель. В функциональном языке это просто суперпозиция функций:

D>

D>def walkTree(root: TreeNode, visitor: TreeNode => Unit)
D>

Это стратегия, а не посетитель.

Здравствуйте, dimgel, Вы писали:

D>Можно конкретный пример, посложнее моего с посетителем? То, что реализуется, я подозреваю, но не знаю как это выглядит на практике. В голове усиленно крутится только реализация на прологе, который вообще из третьей оперы, и мне оно представляется несколько более громоздким.
А смысл?

Ну, допустим, покажешь ты всем, что Посетитель, Стратегия и проч. в функциональных языках -- громоздкие и неудобные конструкции. Ну и что? Что с того, что чисто ООП конструкции имеют неудобный аналог в языках, в которых эти конструкции нафик не нужны, так как имеется куча собственных наработок.

СУВ, Aikin

Здравствуйте, samius, Вы писали:

D>>

D>>def walkTree(root: TreeNode, visitor: TreeNode => Unit)
D>>

S>Это стратегия, а не посетитель.

Это зависит от семантики вызова. Если задача состоит в том, чтобы обойти дерево и в каждом узле выполнить какую-то операцию, то посетитель.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, samius, Вы писали:

S>>Это стратегия, а не посетитель.

D>Это зависит от семантики вызова. Если задача состоит в том, чтобы обойти дерево и в каждом узле выполнить какую-то операцию, то посетитель.

Посетитель — это когда надо выполнить специфическую для типа узла операцию.

Здравствуйте, Aikin, Вы писали:

A>Я говорю про генерик-маппинг + метаданные.
Ok. то есть ты предлагаешь под каждый случай использования данных, вместо публичного доступа использовать генерик-маппинг + метаданные? Какой в этом практический смысл? "Какую задачу ты этим решаешь?" (с)

A>Не нужно раздувать вполне конкретное применение способа (для воссоздания объекта из базы) на общий случай.
Если у тебя объект ни для чего другого кроме как для "воссоздания" из базы не используестя, то действительно не нужно, но в реальной жизни так не бывает.

A>Вот с этим я и спорю.
Напрасно.

A>А мне нравится

Твои проблемы.

Здравствуйте, IB, Вы писали:

A>>Я говорю про генерик-маппинг + метаданные.
IB>Ok. то есть ты предлагаешь под каждый случай использования данных, вместо публичного доступа использовать генерик-маппинг + метаданные?
Нет, я предлагаю под каждый способ использования подобрать способ/инструмент больше всего подходящий для него.

A>>Не нужно раздувать вполне конкретное применение способа (для воссоздания объекта из базы) на общий случай.
IB>Если у тебя объект ни для чего другого кроме как для "воссоздания" из базы не используестя, то действительно не нужно, но в реальной жизни так не бывает.
Воссоздали, изменили через его публичный контракт, отобразили пользователю, сохранили.
Что не так?

A>>Вот с этим я и спорю.
IB>Напрасно.
A>>А мне нравится

IB>Твои проблемы.
Ага, ктоб сомневался

СУВ, Aikin

Здравствуйте, samius, Вы писали:

S>Посетитель — это когда надо выполнить специфическую для типа узла операцию.

Да, точно, попутал.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Aikin, Вы писали:

A>Полиморфизм в функциональных языках так же отлично реализуется.
Полиморфизм реализуется даже в С.. =)

A>ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки.
Думать всем удобнее по разному. Просто в ООП языках такие вещи как полиморфизм, инкапсуляция и всевозможное наследование введены на уровене языка, как следствие, в таких языках этими вещами удобнее пользоваться и выражать логику приложения именно в этих терминах.
В функциональных языках, где на нативно поддерживаются другие вещи, та же логика совершенно естественным образом выражается по другому, в процедурных — по третьему.
И совсем не фокус взять один язык и писать на нем в стиле другого.
Вопрос лиш в том, какая (прости-господи) парадигма лучше подходит под конкретную задачу.

Здравствуйте, Aikin, Вы писали:

A>Нет, я предлагаю под каждый способ использования подобрать способ/инструмент больше всего подходящий для него.
Дело в том, что в качестве способа публичный доступ больше всего подходит для всех способов/инструментов, даже для тех, о которых ты еще не подумал. Причем он универсальный, не надо отдельно приседать в каждом конкретном случае.

A>Воссоздали, изменили через его публичный контракт, отобразили пользователю, сохранили.
A>Что не так?
Да все так, просто публичный контракт — это тривиальный геттер/сеттер. И ничто не мешает реализовать тот же персистанс ровно через этот же публичный контракт.

A>Ага, ктоб сомневался

Ну просто ощущение что "баба яга против".

Здравствуйте, IB, Вы писали:

A>>ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки.
IB>Думать всем удобнее по разному.
Полностью согласен. Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе.

IB>Просто в ООП языках такие вещи как полиморфизм, инкапсуляция и всевозможное наследование введены на уровене языка, как следствие, в таких языках этими вещами удобнее пользоваться и выражать логику приложения именно в этих терминах.
Еще раз: это не более чем плюшки ООП.

IB>В функциональных языках, где на нативно поддерживаются другие вещи, та же логика совершенно естественным образом выражается по другому, в процедурных — по третьему.
IB>И совсем не фокус взять один язык и писать на нем в стиле другого.
+1
IB>Вопрос лиш в том, какая (прости-господи) парадигма лучше подходит под конкретную задачу.
+10000!

СУВ, Aikin

Здравствуйте, IB, Вы писали:

A>>Нет, я предлагаю под каждый способ использования подобрать способ/инструмент больше всего подходящий для него.
IB>Дело в том, что в качестве способа публичный доступ больше всего подходит для всех способов/инструментов, даже для тех, о которых ты еще не подумал. Причем он универсальный, не надо отдельно приседать в каждом конкретном случае.
В этом случае проще. Но объект дизайнился не для того, чтобы его было просто/удобно перистить, а для того чтобы представлять часть бизнесс логики приложения. То что его нужно сохранять/воссоздавать -- задача сервисного слоя.

A>>Воссоздали, изменили через его публичный контракт, отобразили пользователю, сохранили.
A>>Что не так?
IB>Да все так, просто публичный контракт — это тривиальный геттер/сеттер. И ничто не мешает реализовать тот же персистанс ровно через этот же публичный контракт.
Нет, публичный контракт это публичный контракт.
Например метод DoEverythingYouCan(), гетер без сеттера.

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

A>В этом случае проще. Но объект дизайнился не для того, чтобы его было просто/удобно перистить, а для того чтобы представлять часть бизнесс логики приложения.
Иными словами, мы приходим к двум объектам, один для сериализации, а другой для реализации бизнес-логики приложения — ЧТД..

A>То что его нужно сохранять/воссоздавать -- задача сервисного слоя.
Сохранять/загружать нужно не его, а данные, которые он содержит.

A>Нет, публичный контракт это публичный контракт.
A>Например метод DoEverythingYouCan(), гетер без сеттера.
Каким методом ты будешь сериализовать свой объект в XML?
Каким методом ты будешь считать скользящее среднее по коллекции объектов?
Каким методом ты будешь выполнять форматирование ФИО для разных сценариев?
...
Для ответа на все эти вопросы у тебя есть ровно два варианта
1. Во внешних методах нарошно заточеных для такого функционала, а значит у тебя есть публичный доступ к этим данным.
2. С помощю методов реализованных прямо в этом объекте.
Нужно пояснять, почему второй ответ не правильный?

Здравствуйте, Aikin, Вы писали:

A>Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе.
Да вот не факт. Чтобы дорасти до ООП и моделирования в рамках этой концепции мозг приходится вывихнуть довольно основательно. Некоторые вон, до сих пор еще не осилили..

Самый простой подход даже не процедурный, а тупо линейный, другое дело что со сложностью в этом случае вообще не справиться.

A>Еще раз: это не более чем плюшки ООП.
Что ты понимаешь под "плюшками ООП", а что под не плюшками?

Здравствуйте, IB, Вы писали:

A>>В этом случае проще. Но объект дизайнился не для того, чтобы его было просто/удобно перистить, а для того чтобы представлять часть бизнесс логики приложения.
IB>Иными словами, мы приходим к двум объектам, один для сериализации, а другой для реализации бизнес-логики приложения — ЧТД..

Нет. Мы приходим к одному объекту, который сохранить/восстановить можно только через доступ к приватным членам класса (через рефлексию, например).

A>>То что его нужно сохранять/воссоздавать -- задача сервисного слоя.
IB>Сохранять/загружать нужно не его, а данные, которые он содержит.
Мы не на телеигре "Define it right".

IB>Нужно пояснять, почему второй ответ не правильный?
Не, не нужно, я сам смогу это сделать.

IB>1. Во внешних методах нарошно заточеных для такого функционала, а значит у тебя есть публичный доступ к этим данным.
Не нужно преувеличивать. ReadOnly доступ в 99% случаев будет, оставшийся 1% смысла рассматривать нет.

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

A>Здравствуйте, IB, Вы писали:

A>>>ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки.
IB>>Думать всем удобнее по разному.
A>Полностью согласен. Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе.
А вот программы в таком мире не живут. Очень малая часть состоит из долгоживущих объектов, которые имеют какое-то поведение и состояние.

Здравствуйте, IB, Вы писали:

A>>Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе.
IB>Да вот не факт. Чтобы дорасти до ООП и моделирования в рамках этой концепции мозг приходится вывихнуть довольно основательно. Некоторые вон, до сих пор еще не осилили..

IB>Самый простой подход даже не процедурный, а тупо линейный, другое дело что со сложностью в этом случае вообще не справиться.
Пас
Конструктивные аргументы закончились

A>>Еще раз: это не более чем плюшки ООП.
IB>Что ты понимаешь под "плюшками ООП", а что под не плюшками?
Re[18]: Уточняю насчёт GoF и ООП.

ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки.

Т.е. если убрать Наследование и Полиморфизм, то, ИМХО, ООП как было так и останется ООП.
С Инкапсуляцией сложнее, так как она немедленно следует из самого понятия Объект.

СУВ, Aikin

Здравствуйте, gandjustas, Вы писали:

A>>Полностью согласен. Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе.
G>А вот программы в таком мире не живут. Очень малая часть состоит из долгоживущих объектов, которые имеют какое-то поведение и состояние.
Продолжай, продолжай, не стоит останавливаться на полуслове.

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

A>Нет.
Как это нет? Ты же сам все отлично сформулировал — есть две разные цели :
1. Сериализовать.
2. Заниматься бизнес-логикой.
Следуя SRP мы должны сделать два объекта для этих двух обязанностей.

A> Мы приходим к одному объекту, который сохранить/восстановить можно только через доступ к приватным членам класса (через рефлексию, например).
Поехали по кругу.
1. Какую проблему ты решаешь сначала закрывая доступ, а потом протаптывая дырки через рефлекшен?
2. У тебя объект ничем не занимается, кроме восстановления из БД? С другими подсистемами не взаимодействует?

A>Мы не на телеигре "Define it right".
Если ты define it wrong, то разговор вообще бесполезен.

A>Не нужно преувеличивать. ReadOnly доступ в 99% случаев будет, оставшийся 1% смысла рассматривать нет.
То есть хотя бы геттеры у нас все-таки публичные, уже хорошо. Собственно этого достаточно для выноса логики персистентности наружу без извращений, для поднятия из БД достаточно соответствующего конструктора.

Здравствуйте, Aikin, Вы писали:

A>Т.е. если убрать Наследование и Полиморфизм, то, ИМХО, ООП как было так и останется ООП.
A>С Инкапсуляцией сложнее, так как она немедленно следует из самого понятия Объект.
Нет, все немного сложнее. ООП невозможно без инкапсуляции и полиморфизма. Инкапсуляция вполне возможна и без объектов, но не наоборот, то же самое и с полиморфизмом. Это если от этих терминов плясать. Наследование реализаций действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП.

Здравствуйте, IB, Вы писали:

IB>1. Сериализовать.
IB>2. Заниматься бизнес-логикой.
IB>Следуя SRP мы должны сделать два объекта для этих двух обязанностей.
Да, точно! Что-то я туплю. Сорри.

IB>1. Какую проблему ты решаешь сначала закрывая доступ, а потом протаптывая дырки через рефлекшен?
Уменьшение сложности системы путем инкапсуляции логики изменения состояния объекта внутри него (напомню, я проектирую в стиле анемик-анемик-рич). Соответственно я запрещаю изменять состояние объекта в обход этой логики.

IB>2. У тебя объект ничем не занимается, кроме восстановления из БД? С другими подсистемами не взаимодействует?
Я запутался. Есть объект-сущность и объект-"персистер". Я говорю о первом. Сложности второго меня не сильно интересуют, если первый удобно использовать для выполнения его задачи.
Тем более, что принципы персистинга универсальны, а вот бизнес-правила уникальны.

A>>Не нужно преувеличивать. ReadOnly доступ в 99% случаев будет, оставшийся 1% смысла рассматривать нет.
IB>То есть хотя бы геттеры у нас все-таки публичные, уже хорошо.
Да. Не вижу особого смысла в абсолютно приватном "данном".

IB>Собственно этого достаточно для выноса логики персистентности наружу без извращений, для поднятия из БД достаточно соответствующего конструктора.
Это если вручную писать, а если использовать инструменты, то они так же плохо дружат с конструкторами

СУВ, Aikin

Здравствуйте, IB, Вы писали:

A>>Т.е. если убрать Наследование и Полиморфизм, то, ИМХО, ООП как было так и останется ООП.
A>>С Инкапсуляцией сложнее, так как она немедленно следует из самого понятия Объект.
IB>Нет, все немного сложнее. ООП невозможно без инкапсуляции и полиморфизма. Инкапсуляция вполне возможна и без объектов, но не наоборот, то же самое и с полиморфизмом. Это если от этих терминов плясать.
Ага. Полиморфное поведение присуще объектам мира в котором мы живем: если это автомобиль, то вне зависимости от ее марки он будет "рулиться" так же как и другие.
Согласен, без Полиморфизма ООП сильно потерял бы и точно не стал бы мэйнстримом.

Но все равно, изначальный тезис не изменился: "людям тупо удобнее думать в категориях объектов и их взаимодействия". И я на нем настаиваю

СУВ, Aikin

Здравствуйте, dimgel, Вы писали:

D>Тезис собственно такой: единственная существенная польза от ООП, благодаря которой его все используют, — это полиморфизм.

Полиморфизм в конечном счёте сводится к косвенной адресации, которой в ФП соответствует ФВП, а в C простые указатели на функцию. В общем, ничего военного. Только не понятно, почему народ с таким усердием пытается сэмулировать ООП в pure FP языках, а я помниться, после пары лет применения ООП, когда меня заставили писать обратно на C первый параметер своих глобальных функций называл this.

Здравствуйте, IB, Вы писали:

IB>Наследование реализаций действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП.

Только без этого рудимента почему-то не обходится ни одна приличная UI библиотека

Здравствуйте, IT, Вы писали:

IT> Только не понятно, почему народ с таким усердием пытается сэмулировать ООП в pure FP языках, а я помниться, после пары лет применения ООП, когда меня заставили писать обратно на C первый параметер своих глобальных функций называл this.

Ну есть и обратный эффект, пописав на функциональных языках и возвращаясь к объектным, все равно пишешь немного в функциональном стиле и, надо заметить, как правило не плохо получается.

Здравствуйте, IB, Вы писали:

IB>Ну есть и обратный эффект, пописав на функциональных языках и возвращаясь к объектным, все равно пишешь немного в функциональном стиле и, надо заметить, как правило не плохо получается.

Мы это всё уже много раз пережевали. ООП и ФП никак не конфликтуют и отлично дополняют друг друга. Я вообще не понимаю о чём спор

Здравствуйте, IT, Вы писали:

IT>Только без этого рудимента почему-то не обходится ни одна приличная UI библиотека

Ну, как бы эта. Речь то не про обходиться без этого или нет, а про относится это к ООП или нет..

К тому же, если взять, например, тот же WPF, то при его использовании наследование нужно уже гораздо меньше, чем в winforms...

Здравствуйте, IB, Вы писали:

IT>>Только без этого рудимента почему-то не обходится ни одна приличная UI библиотека

IB>Ну, как бы эта. Речь то не про обходиться без этого или нет, а про относится это к ООП или нет..

А к чему оно теперь относится?

IB>К тому же, если взять, например, тот же WPF, то при его использовании наследование нужно уже гораздо меньше, чем в winforms...

Тем не менее, делать свою кнопку (не говоря уже про грид) с нуля, используя только интерфейсы, тебе не захочется даже в страшном сне

Здравствуйте, Aikin, Вы писали:

A>Соответственно я запрещаю изменять состояние объекта в обход этой логики.
То есть ты эту логику прописываешь на все случаи жизни?
А если надо добавить новую логику?

A>Это если вручную писать, а если использовать инструменты, то они так же плохо дружат с конструкторами

Это проблемы инструментов.

Здравствуйте, IT, Вы писали:

IT>А к чему оно теперь относится?
К особенностям реализации конкретных языков.

IT>Тем не менее, делать свою кнопку (не говоря уже про грид) с нуля, используя только интерфейсы, тебе не захочется даже в страшном сне

Что значит "с нуля"? Для произвольной кнопки в WPF достаточно XSAML-а.

Здравствуйте, IB, Вы писали:

IT>>А к чему оно теперь относится?
IB>К особенностям реализации конкретных языков.

Особенностям реализации чего?

IT>>Тем не менее, делать свою кнопку (не говоря уже про грид) с нуля, используя только интерфейсы, тебе не захочется даже в страшном сне

IB>Что значит "с нуля"? Для произвольной кнопки в WPF достаточно XSAML-а.

А XAML во что потом преобразуется, не в объекты ли WPF?

Здравствуйте, IT, Вы писали:

IT>Особенностям реализации чего?
Языков.. )

IT>А XAML во что потом преобразуется, не в объекты ли WPF?
В объекты, но это уже дело WPF, а не мое.. Твой же концепт, что библиотека может быть сколь угодно ужасна, лишь бы внешний интерфейс был прекрасен — вот он в действии..

Здравствуйте, IB, Вы писали:

IB>В объекты, но это уже дело WPF, а не мое.. Твой же концепт, что библиотека может быть сколь угодно ужасна, лишь бы внешний интерфейс был прекрасен — вот он в действии..

Уххх, не удержался... сижу матерюсь на шаблон treeview, а тут вы

В общем чтоб вы всю жисть пытались изменять отдельные свойства в шаблонах WPF контролов как они сейчас есть!
С ViewStateManager оно попроще слекга будет. Когда он выйдет.

Нету сейчас в WPF "прекрасного внешнего интерфейса" для тонкого тюнинга стилей. Максимум что можно — сделать сампл/пообъявлять PART_'ы. Хотите свой фон у кнопочки — пишите template с нуля.

Сорри за резкость, задалбывают прекрасные поверхностные отзывы, особенно когда забурился в прекрасный внешний интерфейс по уши.

Здравствуйте, IB, Вы писали:

IT>>Особенностям реализации чего?
IB>Языков.. )

Трактовка ООП теперь зависит от языков? Т.е. в C++ и в C# у нас два разных ООП'а? Интересно.

IT>>А XAML во что потом преобразуется, не в объекты ли WPF?
IB>В объекты, но это уже дело WPF, а не мое.. Твой же концепт, что библиотека может быть сколь угодно ужасна, лишь бы внешний интерфейс был прекрасен — вот он в действии..

Мой концепт? В моих концептах слова "ужасна" нет вообще. Впрочем, "прекрасен" тоже

Здравствуйте, Sinix, Вы писали:

S>Сорри за резкость, задалбывают прекрасные поверхностные отзывы, особенно когда забурился в прекрасный внешний интерфейс по уши.

К сожалению UI один из наиболее сложных компонентов приложения, хуже всего поддающийся унификации. Соответственно и библиотеки UI делать сложно и придумать, а главное потом реализовать что-то выдающееся очень и очень сложно. WPF тоже не вершина эволюции, особенно в плане реализации. Это точно. И уж ещё более точно, что вершина эволюции 100% не будет построена на ООП, используя только наследование интерфейсов. Звучит красиво, но абсолютно нежизнеспособно.

Здравствуйте, IT!

Сгласен. Я дико извиняюсь, не хотел никого обидеть, просто пост попался в очень удачный момент. Для view сложного контрола на самом деле ничего кроме машины состояний не придумаешь — wpf team к ней и пришла с ViewStateManager.

А louse coupling для view контрола неизбежно превращается в страшные прыжки с просмотром visual tree.

Не пробовали допустим пополучать TreeItem у WPF TreeView? крайне занятная задача. Учитывая что новые узлы не появляются сразу после изменения списка — идёт пинок dispatcher'у и уже он в свободное время по возможности их добавляет.
Ещё забавней — подменить template без потери feyboard focus (обычный остаётся...). Нужно было для редактирования элементов прямо в TreeView (аля в винформс аналоге).

Блин, не кодинг а квест какой-то

Здравствуйте, Sinix, Вы писали:

S>С ViewStateManager оно попроще слекга будет. Когда он выйдет.
На codeplex вроде есть.

S>Нету сейчас в WPF "прекрасного внешнего интерфейса" для тонкого тюнинга стилей. Максимум что можно — сделать сампл/пообъявлять PART_'ы. Хотите свой фон у кнопочки — пишите template с нуля.

Ну насчет "с нуля" не надо перегибать. Темплейты всех контролов в виде xaml доступы. Копипаст и смена только нужных частей решает все проблемы.

Здравствуйте, gandjustas, Вы писали:

G>На codeplex вроде есть.
У ViewStateManager есть баг с утечкой памяти. Месяц назад ещё не пофиксили. Как сейчас —

G>Ну насчет "с нуля" не надо перегибать. Темплейты всех контролов в виде xaml доступы. Копипаст и смена только нужных частей решает все проблемы.

Мдя, тут я перегнул. Но всё равно в плане саппорта извратом выглядит. Допустим шаблон меню для silver theme поменяли в .net 3.0 sp1 (был глюк с тенью). Согласитесь, необходимость перегенеривать шаблоны с каждым мелким фиксом — явный косяк дизайна.

P.S. Если что: мне WPF нравится куда больше винформсов. Ждём fw4, обещали пофиксить ряд багов с биндигом, да и с шаблонами попроще будет.

Здравствуйте, IT, Вы писали:

IT>Трактовка ООП теперь зависит от языков? Т.е. в C++ и в C# у нас два разных ООП'а?
Конечно. ООП — это сфероконь в вакууме, и говорить о чистом ООП имеет смысл, когда нужно разобраться с общей теорией и концептом.
А каждый конкретный язык реализует (интерпретирует, если угодно) ООП по своему. Например, ты же прекрасно знаешь, что в тру-ООП нет никаких виртуальных вызовов, а все происходит посредством обмена сообщениями, однако большинство современных языков реализовали это дело как вызовы методов. В смолтолке, ООП-нутее которого больше не было, в первых версиях никакого наследования не существовало, и так все работало в силу динамичности языка. Понадобилась статика — прикрутили наследование, чтобы полиморфизм получить, и так далее...
То же наличие интерфейсов в C# — уже другая интерпретация по сравнению с C++, где их нет.
Так что таки да, наследование реализаций — это конкретная интерпретация идей ООП в конкретных языках, вполне рабочая и бурно применяемая на практике, кто бы спорил...

И вообще ты меня не путай. Мы о другом немного, тут юноша заявил, что мол "это не ООП", причем использовал это в качестве аргумента непонятно в чем, и я уже устал у него вытягивать, что же он под ООП имеет ввиду и почему "это" не ООП.
Так что мы пока о теории, до практики пока не добрались, а тут ты со своими языками..

IT>Мой концепт? В моих концептах слова "ужасна" нет вообще. Впрочем, "прекрасен" тоже

Это уже детали реализации твоего концепта..

Здравствуйте, IB, Вы писали:

IB>То же наличие интерфейсов в C# — уже другая интерпретация по сравнению с C++, где их нет.

Как это нет, а как же народ пишет COM на плюсах?

IB>Так что таки да, наследование реализаций — это конкретная интерпретация идей ООП в конкретных языках, вполне рабочая и бурно применяемая на практике, кто бы спорил...

Ваня, интерфейсы немного из другой оперы, они имеют больше отношение к компонентности (откуда они и появились), чем к ООП. А ООП в свою очередь наследование никак не разделяет на интерфейс и реализацию, есть просто наследование. Можно, конечно, постоянно менять трактовки и терминологию, но так мы быстро придём к тому, что сделали джависты с ORM — создадим терминологию, в которой термин и то, что он обозначает это два совершенно разных человека. И будем потом объяснять, что true наследование, это наследование интерфейса, при условии наличия lazy loading и хранилища объектов. Иначе это что угодно, но не наследование.

IB>И вообще ты меня не путай. Мы о другом немного, тут юноша заявил, что мол "это не ООП", причем использовал это в качестве аргумента непонятно в чем, и я уже устал у него вытягивать, что же он под ООП имеет ввиду и почему "это" не ООП.
IB>Так что мы пока о теории, до практики пока не добрались, а тут ты со своими языками..

Не-не-не-не. Вы там можете сколько угодно теоретизировать, но оставайтесь в рамках приличия. Не надо вносить ненужные опасные мутации в веками устоявшуюся терминологию.

IT>>Мой концепт? В моих концептах слова "ужасна" нет вообще. Впрочем, "прекрасен" тоже

IB>Это уже детали реализации твоего концепта..

Реализация моего концепта предельно проста — всё должно быть предельно просто

Здравствуйте, IT, Вы писали:

IT>Как это нет, а как же народ пишет COM на плюсах?

Посредством COM интерфейсов.. =)

IT>Ваня, интерфейсы немного из другой оперы, они имеют больше отношение к компонентности (откуда они и появились), чем к ООП.
Опера все та же, просто в какой-то момент догадались эти два понятия разделить (контракт и реализацию), что ни разу не пошло во вред ООП.

IT> А ООП в свою очередь наследование никак не разделяет на интерфейс и реализацию, есть просто наследование.
Правильно, потому что наследование контрактов и наследование реализаций — это конкретные реализации концепции наследования...

Какие-то языки поддерживают оба, какие-то только наследование реализаций, а какие-то вообще без наследования обходятся, что не мешает им быть ООП.

IT> Можно, конечно, постоянно менять трактовки и терминологию,
Трактовки и терминологию никто не меняет, за отсутствием таковых.

IT> Не надо вносить ненужные опасные мутации в веками устоявшуюся терминологию.
Какие мутации? Где эта устоявшаяся терминология?

IT>Реализация моего концепта предельно проста — всё должно быть предельно просто

Но не проще..

Здравствуйте, IB, Вы писали:

IT>>Как это нет, а как же народ пишет COM на плюсах?

IB>Посредством COM интерфейсов.. =)

Так их же нет в плюсах

IT>> А ООП в свою очередь наследование никак не разделяет на интерфейс и реализацию, есть просто наследование.
IB>Правильно, потому что наследование контрактов и наследование реализаций — это конкретные реализации концепции наследования...

Ещё раз. Интерфейс — это атрибутика компонентности, а не ООП.

IT>> Не надо вносить ненужные опасные мутации в веками устоявшуюся терминологию.
IB>Какие мутации? Где эта устоявшаяся терминология?

Твои мутации. Это твоё?

Наследование реализаций действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП.

IT>>Реализация моего концепта предельно проста — всё должно быть предельно просто

IB>Но не проще..

Нет, не проще

Здравствуйте, IT, Вы писали:

IT>Так их же нет в плюсах

Ну это же не значит, что в плюсах их нельзя эмулировать..

IT>Ещё раз. Интерфейс — это атрибутика компонентности, а не ООП.
Еще раз выделение контракта в отдельную сущность — это особенность реализации.

IT>Твои мутации. Это твоё?
У меня мутаций нет..

IT>

IT>Наследование реализаций действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП.

Мое, тебе не понравилось "наследование реализаций"? Могу обобщить — "Наследование действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП"

IT>Нет, не проще

Вооот.. )

Здравствуйте, IB, Вы писали:

IT>>Так их же нет в плюсах

IB>Ну это же не значит, что в плюсах их нельзя эмулировать..

Т.е. они есть

IT>>Ещё раз. Интерфейс — это атрибутика компонентности, а не ООП.
IB>Еще раз выделение контракта в отдельную сущность — это особенность реализации.

Реализации чего? Наследования или компонентности?

IT>>Твои мутации. Это твоё?
IB>У меня мутаций нет..

Мутации есть у всех.

IT>>

IT>>Наследование реализаций действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП.

IB>Мое, тебе не понравилось "наследование реализаций"? Могу обобщить — "Наследование действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП"

Наследование — это один из столпов ООП, как оно может иметь к нему "довольно опосредованное отношение"?

IT>>Нет, не проще

IB>Вооот.. )
Ага.

Здравствуйте, IT, Вы писали:

IT>Т.е. они есть

В виде First Class Object нет, эмулировать можно. Мы в таком стиле долго продолжать можем... )

IT>Реализации чего? Наследования или компонентности?
Реализации наследования в конкретных языках.

IT>Наследование — это один из столпов ООП, как оно может иметь к нему "довольно опосредованное отношение"?
Не совсем так, "столпы ООП" — это инкапсуляция и полиморфизм, так как следуют напрямую из определения Кея. Наследование же, это один из вариантов получения полиморфизма, но настолько вкусный, что его тоже к столпам приписывают.
Собственно, в первых версиях смолтолка, как я уже говорил, наследования не было, и есть целый класс prototype-based языков, наследованием не оборудованных, которые, тем не менее, полноценные ОО языки.

Здравствуйте, IB, Вы писали:

IT>>Наследование — это один из столпов ООП, как оно может иметь к нему "довольно опосредованное отношение"?
IB>Не совсем так, "столпы ООП" — это инкапсуляция и полиморфизм, так как следуют напрямую из определения Кея. Наследование же, это один из вариантов получения полиморфизма, но настолько вкусный, что его тоже к столпам приписывают.

Куда-то непонятно тебя занесло. Давай начнём с базовых определений

Полиморфизм позволяет объекту выбирать правильный метод в зависимости от переданных параметров. А наследование — это механизм позволяющий пораждать новый класс на базе существующего. Они, конечно, связаны через реализацию, но это уже детали реализации.

IB>Собственно, в первых версиях смолтолка, как я уже говорил, наследования не было, и есть целый класс prototype-based языков, наследованием не оборудованных, которые, тем не менее, полноценные ОО языки.

Ну мало ли сколько недоязыков появилось пока концепция не приобрела стройный и законченный вид. Где все эти языки, где твой смолток? В музее. Вот там ему и место. И не стоит доставать его из пыльного шкафа и апеллировать к его исторически оправданным недостаткам. А то так можно договориться до того, что человеку надо поотрезать ухи и ноги, потому что их нет у амёбы.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, IB, Вы писали:

IT>>>Наследование — это один из столпов ООП, как оно может иметь к нему "довольно опосредованное отношение"?
IB>>Не совсем так, "столпы ООП" — это инкапсуляция и полиморфизм, так как следуют напрямую из определения Кея. Наследование же, это один из вариантов получения полиморфизма, но настолько вкусный, что его тоже к столпам приписывают.

IT>Куда-то непонятно тебя занесло. Давай начнём с базовых определений

Полиморфизм позволяет объекту выбирать правильный метод в зависимости от переданных параметров.
Это не так. http://www.rsdn.ru/forum/message/2853873.aspx

IT>А наследование — это механизм позволяющий пораждать новый класс на базе существующего. Они, конечно, связаны через реализацию, но это уже детали реализации.
Это если вводить понятие "класс", которое для ООП совершенно необязательно.

Эти базовые определения рассказывают студентам на первом курсе, взяты они в основномиз C++ и паскаля седьмой версии.

IB>>Собственно, в первых версиях смолтолка, как я уже говорил, наследования не было, и есть целый класс prototype-based языков, наследованием не оборудованных, которые, тем не менее, полноценные ОО языки.

IT>Ну мало ли сколько недоязыков появилось пока концепция не приобрела стройный и законченный вид. Где все эти языки, где твой смолток? В музее. Вот там ему и место. И не стоит доставать его из пыльного шкафа и апеллировать к его исторически оправданным недостаткам. А то так можно договориться до того, что человеку надо поотрезать ухи и ноги, потому что их нет у амёбы.
Понимание ООП в статически и динамически типизруемых языках может кардинально отличаться.

Здравствуйте, gandjustas, Вы писали:

IT>>Куда-то непонятно тебя занесло. Давай начнём с базовых определений

Полиморфизм позволяет объекту выбирать правильный метод в зависимости от переданных параметров.
G>Это не так. http://www.rsdn.ru/forum/message/2853873.aspx

Как это опровергает сказанное?

IT>>А наследование — это механизм позволяющий пораждать новый класс на базе существующего. Они, конечно, связаны через реализацию, но это уже детали реализации.
G>Это если вводить понятие "класс", которое для ООП совершенно необязательно.

Замени "класс" на любое слово, которое тебе нравится и да будет тебе счастье. Аминь.

G>Эти базовые определения рассказывают студентам на первом курсе, взяты они в основномиз C++ и паскаля седьмой версии.

Странно, что через много лет работы программисты начинают в них путаться. Правда? Ваня вот похоже зациклился на нелюбви к наследованию реализации и как следствие перепутал виртуальные методы с наследованием.

G>Понимание ООП в статически и динамически типизруемых языках может кардинально отличаться.

Например?

Здравствуйте, IT, Вы писали:

IT> Полиморфизм позволяет объекту выбирать правильный метод в зависимости от переданных параметров.
Прально! (правда метод — уже конкретика) И this, в случае наследования, у нас тоже параметр, который позволяет вызвать правильный перегруженный или базовый метод.
Конкретно данный механизм называется — неявный ad-hoc полиморфизм по первому аргументу, если ты точных определений хочешь..

IT> А наследование — это механизм позволяющий пораждать новый класс на базе существующего.
Угу, вопрос только "для чего"? Собственно, требования пораждать новый класс на базе существующего в ООП нет (как и классов), но это очень удобный и красивый механизм полиморфизма. Благодаря наследованию происходит неявный вызов перегруженного метода (исполнение нужной логики) у нужного наследника, совершенно прозрачно для вызывающего кода. Ради этого все и задумывалось — чтобы код, реализующий логику вызовов не нуждался в указании того, что именно он вызывает, а нужная логика подставлялась автоматически.
А то, что в следствии таких приседаний еще и вызовы не нужно дублировать, если не нужно базовую реализацию перегружать — приятный бонус. С другой стороны в прототипных языках и без этого с успехом обходятся и они не перестают быть ООП.

IT>Где все эти языки, где твой смолток? В музее.
Ну вот JScript не в музее ни разу.

IT> А то так можно договориться до того, что человеку надо поотрезать ухи и ноги, потому что их нет у амёбы.
Не увлекайся, я тоже много забавных аналогий придумать могу..

Здравствуйте, IT, Вы писали:

IT>Ваня вот похоже зациклился на нелюбви к наследованию реализации и как следствие перепутал виртуальные методы с наследованием.
Где? Это похоже ты зацикликлся, что я зациклился на нелюбви к наследованию реализации..

Здравствуйте, IB, Вы писали:

IB>Конкретно данный механизм называется — неявный ad-hoc полиморфизм по первому аргументу, если ты точных определений хочешь..

Ну понятно, т.е. особых возражений по этому поводу нет.

IT>> А наследование — это механизм позволяющий пораждать новый класс на базе существующего.
IB>Угу, вопрос только "для чего"? Собственно, требования пораждать новый класс на базе существующего в ООП нет (как и классов), но это очень удобный и красивый механизм полиморфизма. Благодаря наследованию происходит неявный вызов перегруженного метода (исполнение нужной логики) у нужного наследника, совершенно прозрачно для вызывающего кода. Ради этого все и задумывалось — чтобы код, реализующий логику вызовов не нуждался в указании того, что именно он вызывает, а нужная логика подставлялась автоматически.

Это кто тебе сказал, что именно ради этого всё и задумывалось? Мне известно множество применений наследования без всяких виртуальных методов.

Всё же у меня создаётся стойкое впечатление, что ты где-то перепутал причину со следствием.

IB>А то, что в следствии таких приседаний еще и вызовы не нужно дублировать, если не нужно базовую реализацию перегружать — приятный бонус. С другой стороны в прототипных языках и без этого с успехом обходятся и они не перестают быть ООП.

Я в стиле ООП писал даже на С в своё время и ничего, работало. А ещё Борланд как-то умудрился запихнуть ООП в TASM. Прикольно было. Так что при желании любой паттерн можно реализовать на чём угодно. Только нужно ли?

IT>>Где все эти языки, где твой смолток? В музее.
IB>Ну вот JScript не в музее ни разу.

ООП в джава-скрипте сделан, мягко скажем, через прототипизацию.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, gandjustas, Вы писали:

IT>>>Куда-то непонятно тебя занесло. Давай начнём с базовых определений

Полиморфизм позволяет объекту выбирать правильный метод в зависимости от переданных параметров.
G>>Это не так. http://www.rsdn.ru/forum/message/2853873.aspx

IT>Как это опровергает сказанное?
Сказанное являтся очень частным случаем, полиморфизма.

IT>>>А наследование — это механизм позволяющий пораждать новый класс на базе существующего. Они, конечно, связаны через реализацию, но это уже детали реализации.
G>>Это если вводить понятие "класс", которое для ООП совершенно необязательно.
IT>Замени "класс" на любое слово, которое тебе нравится и да будет тебе счастье. Аминь.
В javascript нету ничего похожего на классы C++.

G>>Эти базовые определения рассказывают студентам на первом курсе, взяты они в основномиз C++ и паскаля седьмой версии.
IT>Странно, что через много лет работы программисты начинают в них путаться. Правда? Ваня вот похоже зациклился на нелюбви к наследованию реализации и как следствие перепутал виртуальные методы с наследованием.
Похоже он неправльно объяснил свою мысль. Ведь виртуальные методы без наследования не очень то нужны.

G>>Понимание ООП в статически и динамически типизруемых языках может кардинально отличаться.
IT>Например?
Например любой динамический язык (теже puthon и ruby) могут обходится без наследования для получения того же эффекта от полиморфизма (в частности виртуальных методов), как в статически типизируемых языках. А в javascript этого неследования и не было никогда.

Здравствуйте, IT, Вы писали:

IT>Ну понятно, т.е. особых возражений по этому поводу нет.
Ну, кроме того, что ты тут полиморфизм урезал..

IT>Это кто тебе сказал, что именно ради этого всё и задумывалось? Мне известно множество применений наследования без всяких виртуальных методов.
Конечно, но не без полиморфизма..

Вот смотри, глобально ты можешь использовать наследование для двух целей:
1. Перегрузить родительскую реализацию, то есть заиспользовать виртуальность. Как мы выяснили, это неявный ad-hoc полиморфизм — в зависимости от типа выполняется разный код.
2. Не трогая родительскую реализацию, расширить базовый класс новыми методами. Это параметрический полиморфизм — один и тот же код работает в разных классах (типах). Если бы параметрический полиморфизм не был нужен, то, с точки зрения ООП, нет смысла и наследоваться, с тем же успехом можно создать новый тип рядом, с дополнительным функционалом и при необходимость явно обращаться к нему. Таким образом, для чего бы ты наследование не использовал, оно все равно упирается в полиморфизм.

IT>Всё же у меня создаётся стойкое впечатление, что ты где-то перепутал причину со следствием.
Я ничего не путал, я просто в свое время потрудился разобраться откуда ноги растут..

Есть сложившийся стереотип, что наследование, это неотъемлемая часть ООП, но на поверку это не совсем так.

IT>ООП в джава-скрипте сделан, мягко скажем, через прототипизацию.
Но тем не менее, это полноценный ООП, без наследования.

Это и печалит

... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>

Здравствуйте, Sinix, Вы писали:

S>Блин, не кодинг а квест какой-то

В случае винформсов квест как бы не похлеще, просто он уже пройден.

... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>

Здравствуйте, AndrewVK, Вы писали:

AVK>В случае винформсов квест как бы не похлеще, просто он уже пройден.

Так и есть, каждый раз когда готов ругаться на WPF представляю как это пришлось бы делать в винформсах

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, IT, Вы писали:

IT>>Только без этого рудимента почему-то не обходится ни одна приличная UI библиотека

AVK>Это и печалит

А меня сейчас печалит COM, в частности shell extension. Реализуйте данный интерфейс, вот в этих методах можете вернуть E_NOTIMPL, а вот в эти нужно реализовать. Вобщем, без документации — никак. И пользовать эти интерфейсы без учета вышеперечисленного нельзя. Сколько им пришлось проверок реализовать, один Гейтс и знает. Притом, я вполне понимаю почему им пришлось сделать так, а не эдак. Более мелкая грануляция интерфейсов приведет к большей сложности реализации. В случае наследования, можно явно показывать что нужно и обязательно реализовывать, что реализовывать по желанию.

Здравствуйте, GlebZ, Вы писали:

AVK>>Это и печалит

GZ>А меня сейчас печалит COM, в частности shell extension.

Это другого плана печаль, не архитектурная а реализационная.

GZ> Реализуйте данный интерфейс, вот в этих методах можете вернуть E_NOTIMPL, а вот в эти нужно реализовать. Вобщем, без документации — никак. И пользовать эти интерфейсы без учета вышеперечисленного нельзя. Сколько им пришлось проверок реализовать, один Гейтс и знает. Притом, я вполне понимаю почему им пришлось сделать так, а не эдак. Более мелкая грануляция интерфейсов приведет к большей сложности реализации. В случае наследования, можно явно показывать что нужно и обязательно реализовывать, что реализовывать по желанию.

Я где то что то говорил про интерфейсы? Да и интерфейсы — далеко не серебряная пуля. Серебряная пуля это моск.

... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Серебряная пуля это моск.
Не каждый

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Это и печалит

GZ>>А меня сейчас печалит COM, в частности shell extension.
AVK>Это другого плана печаль, не архитектурная а реализационная.
Это, главное, проблема.

AVK>Я где то что то говорил про интерфейсы? Да и интерфейсы — далеко не серебряная пуля. Серебряная пуля это моск.
Именно. Накосячить можно и там и там. Поэтому огульному охаиванию — мы говорим нет.
Что касается WinForms, то в рамках функциональности которая реализована там, на мой взгляд, наследование рулит. В качестве интерфейса библиотеки реализация которой выверено и спрятано, наследование рулит.

Здравствуйте, GlebZ, Вы писали:

AVK>>Это другого плана печаль, не архитектурная а реализационная.
GZ>Это, главное, проблема.

А еще в Африке от голода умирают. И это тоже проблема.
Что касается того, что ты описывал, то корень зла тут совсем не в интерфейсах, а очень даже в СОМ и в том, что в СОМ интерфейсы обязательны и кроме них ничего нет.

AVK>>Я где то что то говорил про интерфейсы? Да и интерфейсы — далеко не серебряная пуля. Серебряная пуля это моск.
GZ>Именно. Накосячить можно и там и там. Поэтому огульному охаиванию — мы говорим нет.

А кто тут огульно охаивал? Тут тонко намекали, что смешивать наследование интерфейсов и реализации в большинстве случаев не очень разумно.

GZ>Что касается WinForms, то в рамках функциональности которая реализована там, на мой взгляд, наследование рулит.

Глядя на мегагромадный контракт Control, который дублируется во всех наследниках, на наличие и частое применение фильтров в конкретных дизайнерах, на кучу гамна в контракте, когда я пытаюсь сделать от какого нибудь грида специфичного, заточенного под конкретные данные наследника, на "превосходный" дизайн SplitterContainer, ProgressBar, XxxStripe и прочая, не могу с тобой согласиться никак.

... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>

Здравствуйте, AndrewVK, Вы писали:

AVK>А еще в Африке от голода умирают. И это тоже проблема.
Дитям в Африке я могу послать кусочек сыра. А вот изменить интерфейс IShellFolder — ну никак.

AVK>Что касается того, что ты описывал, то корень зла тут совсем не в интерфейсах, а очень даже в СОМ и в том, что в СОМ интерфейсы обязательны и кроме них ничего нет.
Нет чего? Наследования реализаций?

GZ>>Что касается WinForms, то в рамках функциональности которая реализована там, на мой взгляд, наследование рулит.
AVK>Глядя на мегагромадный контракт Control, который дублируется во всех наследниках,
В действительности — в этом есть существенный плюс. Тебе не нужно реализовывать Control. Достаточно бегать по текущему контракту, и переделывать то что нужно.

AVK>на наличие и частое применение фильтров в конкретных дизайнерах, на кучу гамна в контракте, когда я пытаюсь сделать от какого нибудь грида специфичного, заточенного под конкретные данные наследника,
Насчет грида — соглашусь. Не видел хорошей реализации грида ни разу. Но от Microsoft — редкостное гумно.

Здравствуйте, gandjustas, Вы писали:

IT>>Как это опровергает сказанное?
G>Сказанное являтся очень частным случаем, полиморфизма.

Т.е. никак не опровергает.

IT>>Замени "класс" на любое слово, которое тебе нравится и да будет тебе счастье. Аминь.
G>В javascript нету ничего похожего на классы C++.

Да там и ООП в общем-то натянут на прототипы. Я уже говорил, что я эмулировал в своё время ООП на C. А ещё был ООП в TASM от Борланды.

G>Похоже он неправльно объяснил свою мысль. Ведь виртуальные методы без наследования не очень то нужны.

Ваня утверждает в точности обратное, а именно, что наследование без виртуальных методов не очень нужно.

G>>>Понимание ООП в статически и динамически типизруемых языках может кардинально отличаться.
IT>>Например?
G>Например любой динамический язык (теже puthon и ruby) могут обходится без наследования для получения того же эффекта от полиморфизма (в частности виртуальных методов), как в статически типизируемых языках. А в javascript этого неследования и не было никогда.

Ну и что? Вы опять зациклились на "наследование нужно только для полиморфизма". Это чушь. Причём полная.

Здравствуйте, IB, Вы писали:

IT>>Ну понятно, т.е. особых возражений по этому поводу нет.
IB>Ну, кроме того, что ты тут полиморфизм урезал..

Ну понятно.

IB>Я ничего не путал, я просто в свое время потрудился разобраться откуда ноги растут..

Есть такие понятия как overengineering, overarchitecture и прочие over-. Вот ты overразобрался.

IB>Есть сложившийся стереотип, что наследование, это неотъемлемая часть ООП, но на поверку это не совсем так.

Ну да. Только ты больше никому не рассказывай, что наследование — это разновидность полиморфизма и всё будешь хорошо. Договорились? Ну вот и славненько.

IT>>ООП в джава-скрипте сделан, мягко скажем, через прототипизацию.
IB>Но тем не менее, это полноценный ООП, без наследования.

Надо же, а мужики то и не знали.

Здравствуйте, IT, Вы писали:

IT>>>Замени "класс" на любое слово, которое тебе нравится и да будет тебе счастье. Аминь.
G>>В javascript нету ничего похожего на классы C++.

IT>Да там и ООП в общем-то натянут на прототипы. Я уже говорил, что я эмулировал в своё время ООП на C. А ещё был ООП в TASM от Борланды.
Что значит ООП натянут на прототипы? Прототипы и есть ООП, они отлично соотвествуют определению Кея (он кстати и smalltalk создал, по этом smalltalk является самым ООП языком).

G>>Похоже он неправльно объяснил свою мысль. Ведь виртуальные методы без наследования не очень то нужны.
IT>Ваня утверждает в точности обратное, а именно, что наследование без виртуальных методов не очень нужно.
В плане ООП — да. Наследование преобрело такую популярность не только потому что дает полиморфизм, оно также дает повторное использование кода (а в случае С++ с можественным наследованием это часто используется).

G>>>>Понимание ООП в статически и динамически типизруемых языках может кардинально отличаться.
IT>>>Например?
G>>Например любой динамический язык (теже puthon и ruby) могут обходится без наследования для получения того же эффекта от полиморфизма (в частности виртуальных методов), как в статически типизируемых языках. А в javascript этого неследования и не было никогда.
IT>Ну и что? Вы опять зациклились на "наследование нужно только для полиморфизма". Это чушь. Причём полная.
См выше. Разговор об ООП, не о наследовании вообще.

Здравствуйте, IT, Вы писали:

IT>Есть такие понятия как overengineering, overarchitecture и прочие over-. Вот ты overразобрался.
Да нет, в самый раз.

IB>>Есть сложившийся стереотип, что наследование, это неотъемлемая часть ООП, но на поверку это не совсем так.
IT>Ну да.
Вот и договорились..

IT> Только ты больше никому не рассказывай, что наследование — это разновидность полиморфизма и всё будешь хорошо.
Я рассказываю, что это способ получить полиморфизм, и все, вообщем-то не плохо..

IT>Надо же, а мужики то и не знали.
Да-да, и во всех этих ссылках мужики рассказывают про разницу между наследованием и прототипированием..

Здравствуйте, gandjustas, Вы писали:

G>См выше. Разговор об ООП, не о наследовании вообще.

Разговор о том, что наследование это (да/нет) разновидность полиморфизма.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, gandjustas, Вы писали:

G>>См выше. Разговор об ООП, не о наследовании вообще.

IT>Разговор о том, что наследование это (да/нет) разновидность полиморфизма.

Это не разновидность. Это способ получить полиморфизм по неявному аргументу.

Здравствуйте, IT, Вы писали:

IT>Ваня утверждает в точности обратное, а именно, что наследование без виртуальных методов не очень нужно.
Ничего подобного Ваня не утверждает. Ваня утверждает, что есть несколько причин прибегнуть к наследованию, но все они все равно упираются в полиморфизм. И так же он утверждает, что полиморфизм не ограничивается перегрузкой виртуальных методов.

IT>Ну и что? Вы опять зациклились на "наследование нужно только для полиморфизма". Это чушь. Причём полная.
А аргументы-то будут?

Здравствуйте, IB, Вы писали:

IT>> Только ты больше никому не рассказывай, что наследование — это разновидность полиморфизма и всё будешь хорошо.
IB>Я рассказываю, что это способ получить полиморфизм, и все, вообщем-то не плохо..

Твоё?

Ваня утверждает, что есть несколько причин прибегнуть к наследованию, но все они все равно упираются в полиморфизм.

Хочешь пример наследования, который не упирается в полиморфизм?

IT>>Надо же, а мужики то и не знали.
IB>Да-да, и во всех этих ссылках мужики рассказывают про разницу между наследованием и прототипированием..

Ты так быстро просмотрел все эти 726,000 сслыки?

Здравствуйте, gandjustas, Вы писали:

G>Это не разновидность. Это способ получить полиморфизм по неявному аргументу.

И именно и только для этого наследование было придумано?

Здравствуйте, IT, Вы писали:

IT>Хочешь пример наследования, который не упирается в полиморфизм?
Давай.

IT>Ты так быстро просмотрел все эти 726,000 сслыки?

Я талантливый..

Здравствуйте, IB, Вы писали:

IT>>Хочешь пример наследования, который не упирается в полиморфизм?
IB>Давай.

class A
{
    public int Field1;
}

class B : A
{
    public int Field2;
}

IT>>Ты так быстро просмотрел все эти 726,000 сслыки?

IB>Я талантливый..

Это я уже понял

Здравствуйте, GlebZ, Вы писали:

GZ>Нет чего? Наследования реализаций?

Зациклился? Нет, к примеру, банальных статических функций.

AVK>>Глядя на мегагромадный контракт Control, который дублируется во всех наследниках,
GZ>В действительности — в этом есть существенный плюс.

Ну тогда дальше разговаривать не о чем.

GZ> Тебе не нужно реализовывать Control. Достаточно бегать по текущему контракту, и переделывать то что нужно.

Отличный путь к бардаку.

GZ>Насчет грида — соглашусь.

А с Control то же самое. На кой жоп мне, к примеру, в базовом контроле ссылка на контекстное меню, да еще и в двух видах, если мне оно в моем контроле без надобности? А TabStop и Focus сотоварищи, если контрол с клавиатурой не взаимодействует? По факту, если внимательно рассмотреть контракт контрола, процентов 80 там к самому контролу отношение имеют весьма опосредованное и грубейшим образом нарушают SRP.
Ну а потом по этой куче гамна написатели наследников "бегают по текущему контракту, и переделывают то что нужно", получая в итоге гамно в квадрате.

GZ> Не видел хорошей реализации грида ни разу. Но от Microsoft — редкостное гумно.

А я не про реализацию вообще то, а про дизайн, который может и прокатывал лет 15 назад, а вот в 2002, когда оно зарелизено было, это уже был моветон.

... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>

От:	server_mouse	about:blank
Дата:	04.05.09 16:36
Оценка:	9 (3)

От:	MozgC	http://nightcoder.livejournal.com
Дата:	04.05.09 16:52
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	04.05.09 17:01
Оценка:	18 (5) +2

От:	MozgC	http://nightcoder.livejournal.com
Дата:	04.05.09 17:05
Оценка:

От:	server_mouse	about:blank
Дата:	04.05.09 17:40
Оценка:

От:	IT	linq2db.com
Дата:	04.05.09 19:40
Оценка:	4 (3) +3

От:	Mike Chaliy	http://chaliy.name
Дата:	09.05.09 21:56
Оценка:

От:	IB	http://rsdn.ru
Дата:	12.05.09 05:02
Оценка:	1 (1) +1

От:	dimgel	https://github.com/dimgel
Дата:	13.05.09 04:20
Оценка:

От:	Нахлобуч	https://hglabhq.com
Дата:	13.05.09 08:59
Оценка:	+1

От:	Aikin	kavaleu.ru
Дата:	13.05.09 12:27
Оценка:	1 (1)

	От:	Blazkowicz
	Дата:	13.05.09 13:11
	Оценка:	1 (1) +1

	От:	mrozov
	Дата:	13.05.09 13:36
	Оценка:	42 (7) +2

От:	mazurkin	http://mazurkin.info
Дата:	14.05.09 17:02
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	15.05.09 04:37
Оценка:	2 (1)

	От:	Gadsky
	Дата:	05.05.09 20:21
	Оценка:

От:	Юрий Жмеренецкий	ICQ 380412032
Дата:	15.05.09 18:09
Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	18.05.09 09:31
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	20.05.09 08:40
Оценка:

От:	Sergey T.	http://overstore.codeplex.com
Дата:	25.05.09 15:08
Оценка: