Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Нет. ООП предназначена *именно* для простоты понимания 25.08.04 10:41 Число просмотров: 2639
Автор: amirul <Serge> Статус: The Elderman
|
И производных от него: простота проектирования, простота поддержки, простота реюза и т.д..
> ОП это не для "простоты понимания", а для моделирования
> материальных объектов!
Ага. Для простоты понимания в моделировании материальных объектов. Эволюция парадигм программирования направлена именно на устранение лишних зависимостей, чтобы код стал более управляемым. ООП предназначена ИСКЛЮЧИТЕЛЬНО для человека. А машина все равно выполняет машкод (то есть любую ОО-программу можно написать на ассемблере).
> БД предназначены для управления реальными объектами:
> цехами, складами, сотрудниками... Чем точнее мы смоделируем
> эти объекты и их взаимодействие, тем эффективней будет
> программа. Вы опять сползаете с объектной модели на уровень
> таблиц и запросов. Объект-модель, как раз будет формировать
Вы, возможно, будете удивлены, но БД состоит именно из таблиц и запросов. Это НУЖНО учитывать. Все равно, что фармацевту сказать, что он-де "сползает" с уровня организма на уровень клеточной биохимии. Приведите пример ЭФФЕКТИВНОГО лекарства, которое лечит организм совершенно без учета специфики его устройства.
> наиболее эффективный сложный запрос ко всем связанным с ним
> таблицам одновременно. Только не надо его для этого
> разбивать на "удобопонимаемые" субъединицы, не имеющие
> материальных аналогов.
Видел возмущения одного человека по поводу того, что разные субмодули той же TikiWiki делают штук 50 запросов (в том числе перекрывающихся) к БД на один показ. Вот и понимаешь, что монолитная архитектура эффективнее даже модульной, и уж тем более эффективнее объектной. В объектной модели каждый объект должен сам обрабатывать свое состояние и инкапсуляция не позволит объектам на высоких уровнях абстракции вообще знать что-либо о БД и прочем - слижком уж низкоуровневая вещь и учитываться должна на низком уровне - уровне конкретных классов. А их будет туча, причем все связи вертикальные (друг о друге объекты на одном уровне не знают ничего) и каждому нужны запросы к БД для обновления своего состояния.
Как я уже писал, единственный выход - кеширующая прослойка с отложенным выполнением операций.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
