Это не IT сказал, что в его подходе нет ООП. Это IT в споре с AVK вспомнил, что когда-то Дон Бокс говорил, что ООП сосет для ряда задач.
Чувствуешь разницу?
D>У меня вообще складывается ощущение, что большинство здешних "гуру от архитектуры" нарочно запутывают простые вещи, чтобы утвердиться в собственной крутизне.
У меня складывается ощущение, что кто-то слишком много хамит в последнее время.
D> Многие ли тут способны повторить этот подвиг?
Просто перед Игорем ты испытываешь определенный пиетет и поэтому он единственный, кого ты прочитал внимательно.
Здравствуйте, IB, Вы писали:
IB>Потому что, если речь идет о персистентном хранении этих данных, то без публичного доступа к ним ты не обойдешься. Так как в противном случае, в твой бизнес объект придется "заинкапсулировать" взаимодействие со всеми возможными хранилищами, и вообще всеми подсистемами с которыми объект имеет дело.
Можно использовать рефлекшин, можно дать доступ к полям через определенный интерфейс, можно сделать protected доступ и генерить наследников, можно использовать вложенные классы для доступа... да мало ли что еще можно сделать
Здравствуйте, dimgel, Вы писали:
D>Прочитай ссылку на его пост, которую я тебе дал.
Я не о том спрашивал, я спросил, почему ты так решил. Мне интересно чем ты руководствовался, когда, проанализировав подход IT решил, что это не ООП. Расскажи, продемонстрируй интеллект.
D>Прочитай заголовок темы. Приведи примеры, имеющие отношение к исходному вопросу. Скажи что-нибудь умное по второй половине моих примеров. Короче, продемонстрируй интеллект.
Пока не вижу смысла бисер метать.
Здравствуйте, IB, Вы писали:
D>> Многие ли тут способны повторить этот подвиг? IB>Просто перед Игорем ты испытываешь определенный пиетет и поэтому он единственный, кого ты прочитал внимательно.
Почему же единственный? Тут ещё минимум четыре человека, включая только что подключившегося Синклера, которые опускаются до разбора конкретных ситуаций. Тебя среди них, к сожалению, нет.
Здравствуйте, Aikin, Вы писали:
A>Можно использовать рефлекшин, можно дать доступ к полям через определенный интерфейс, можно сделать protected доступ и генерить наследников, можно использовать вложенные классы для доступа...
Ты эти варианты в серьез рассматриваешь?
A>да мало ли что еще можно сделать
Реалистичные решения будут?
Здравствуйте, IB, Вы писали:
IB>Мне интересно чем ты руководствовался, когда, проанализировав подход IT решил, что это не ООП. Расскажи, продемонстрируй интеллект.
Пожалуйста. Тем, что разобранный им конкретный пример чётко ложится в тот самый его пост, где "данные отдельно, алгоритмы отдельно" и "ООП идёт лесом".
IB>Пока не вижу смысла бисер метать.
Здравствуйте, IB, Вы писали:
IB>Ты эти варианты в серьез рассматриваешь?
Рефлексию -- да (все остальное было добавлено для массовости). Обращение в базу настолько дорогая операция, что затраты на рефлексию можно не рассматривать.
Здравствуйте, dimgel, Вы писали:
D> Тем, что разобранный им конкретный пример чётко ложится в тот самый его пост,
Этот пост совсем про другое и совершенно по другому поводу.
D> где "данные отдельно, алгоритмы отдельно" и "ООП идёт лесом".
Так вот я и хочу, чтобы ты ответил на вопрос — почему ты считаешь, что если данные отдельно, а алгоритмы отдельно, то ООП идет лесом. Конкретно ты, а не IT, AVK или Дон Бокс.
D>А мне не трудно.
Да я вижу.
Здравствуйте, dimgel, Вы писали:
D>Почему же единственный? Тут ещё минимум четыре человека, включая только что подключившегося Синклера, которые опускаются до разбора конкретных ситуаций. Тебя среди них, к сожалению, нет.
Ну, то есть ты признаешься, что остальных ты все равно не читаешь..
Здравствуйте, IB, Вы писали:
D>> Тем, что разобранный им конкретный пример чётко ложится в тот самый его пост, IB>Этот пост совсем про другое и совершенно по другому поводу.
Да ну? А мне показалось, что букафки похожи!
Не важно, по какому он поводу. Важно, что вполне подходит к рассмотренному здесь примеру. "По другому поводу" — это просто отмазка. Книжки с описаниями паттернов пишут тоже — каждый автор по своему поводу.
IB>Так вот я и хочу, чтобы ты ответил на вопрос — почему ты считаешь, что если данные отдельно, а алгоритмы отдельно, то ООП идет лесом.
Потому что это нарушение инкапсуляции данных. Да и наследованием там не пахнет. (Я не говорю, что оно там нужно, а что им там не пахнет.) То, что остаётся (инкапсуляция алгоритмов в BL-слоях) — это строго говоря не ООП, а модульное программирование. Если не согласен, изволь обосновать.
Здравствуйте, 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>Рефлексию -- да (все остальное было добавлено для массовости). Обращение в базу настолько дорогая операция, что затраты на рефлексию можно не рассматривать.
Дело не в дороговизне (хотя и тут не все так просто), одного переноса контроля типов в рантайм достаточно, чтобы не рассматривать этот вариант в серьез.
Ответ на вопрос стоит ли тестировать код с БД или нет будет разным в каждой конкретной ситуации. Я тестирую и так и так, а иногда вообще никак, если это неадекватно по затратам. В 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>Я это и пытаюсь сделать уже на протяжении нескольких постов. Просто бесполезно тебе что-то объяснять, пока ты базовых вещей не уяснишь... Собственно, твои требования конкретики из той же оперы — ты опять понадергаешь из контекста не разобравшись, так и не поняв, почему и зачем. Ну и какой смысл разоряться?
Здравствуйте, IB, Вы писали:
IB>Ты просто фразу из контекста вырвал, где слова знакомые, в суть не вникая. IB>Просто бесполезно тебе что-то объяснять, пока ты базовых вещей не уяснишь... Ну и какой смысл разоряться?
Вот к этому и сводятся все твои аргументы. "Ты дурак и потому объяснять тебе бесполезно."
IB>Я это и пытаюсь сделать уже на протяжении нескольких постов.
Единственный твой вклад в данное обсуждение — это строгое определение инкапсуляции. Остальные посты — бла-бла-бла и понты.
Здравствуйте, IT, Вы писали:
IT>И если ООП где-то пощёл лесом, то это значит только одно — он мне не подошёл в конкретном случае для решения конкретной задачи.
Вот я и пытаюсь всё время говорить о конкретной задаче. О той, которую ты разобрал (других тут не проскакивало). С точки зрения IB это выглядит, по-видимому, так: "мы тут, панимаешь, сидим в своём болоте, квакаем о высоких материях, тут приходит какой-то лось, срёт всем на головы и портит малину своими идиотскими требованиями конкретики". С моей же точки зрения это выглядит как разговор со свидетелями Иеговы, которые мастера говорить о высоких материях, знают трактовку каждой буквы в обоих Заветах, но столкни их носом к носу с самым простеньким конкретным чудом, загремят либо в дурку, либо на кладбище.
Здравствуйте, IB, Вы писали:
IB>Дело не в дороговизне (хотя и тут не все так просто), одного переноса контроля типов в рантайм достаточно, чтобы не рассматривать этот вариант в серьез.
Эх, столкнуть бы тебя сейчас с Мамутом, защищавшим не так давно динамически типизированные языки...
Здравствуйте, gandjustas, Вы писали:
G>Круто, теперь каждый кто читает твой код должен понимать где ты провел границу между воскоуровневой и низкоуровневой логикой.
На самом деле там весьма просто. Я ж несколько раз уже приводил примеры того, что я называю низкоуровневыми конструкциями. Количество этих конструкций ограничено.
G>Рассмотрим на примере древовидного форума, так как ближе всего к твоему случаю. G>Варианты использования: G>............. G>Любые потребности применения деревьев в БД можно расписать по таким сценариям.
Всё отлично расписал. ППКС.
G>Обобщенный код по работе с деревьями вряд ли понадобится.
Мне одному начинает казаться, что мы спорим, с какого конца чистить яйцо? По сути-то — что в триггерах, что в TreeController, что у меня в базовом классе TreeNode — это отдельный слой. Разница в сущности только в сигнатуре вызова. Не находишь?
Мы уже победили, просто это еще не так заметно...
Если нам не помогут, то мы тоже никого не пощадим.
