---|Ветка была без названия|---

← →
euru (2003-10-03 18:49) [120]

>vuk ©
Рабочая неделя закончилась. А в выходные у меня не будет возможности выйти в Интернет. Если есть желание, можно будет продолжить на следующей неделе.

>Некрофил-затейник__ ©
Может за выходные еще несколько решений предложите? :)
Это эмоции. Просто было неожиданно узнать, что кто-то еще наблюдает за нашей дискуссией с Вуком.

← →
iZEN (2003-10-04 09:46) [121]

Касательно баз данных и хранимых процедур.
Для vuk © (18.09.03 16:45) [30]:
Я вообще не очень представляю, как можно делать unit-тесты на систему, у которой почти вся логика живет на сервере БД, а клиент почти только отображением и вызовами процедур и занимается. Не пользовательский же интерфейс тестировать...

Я тут одно мнение вычитал в книжке "Горький вкус ava"
http://www.piter.com/book_about.phtml?id=978588782323&web_ok=yes
, что в трёхуровневой системе при работе с БД можно полностью отказаться от хранимых процедур и переложить всю логику бизнес-приложения на слой сервера приложений. Увеличение быстродействия (понятно, что х.п. выполняются быстрее любого прикладного кода) достигается за счёт кэширования команд, результатов запросов в сервере приложений, кардинального уменьшения удалённых вызовов клиентом сервера с помощью программной прослойки - "фасада".
Автор книжки приводит несколько примеров, каким образом полностью абстрагироваться от БД, делая всю систему независимой от сторонних разработчиков.

← →
Vuk (2003-10-04 11:57) [122]

to iZEN:
Если не стоит задача абстрагирования от БД или автоматического распределения нагрузки, то я вообще не вижу смысла в построении системы с количеством звеньев больше двух. Трехзвенка ради трехзвенки? А оно надо? Ведь получается лишнее усложнение как взаимодействия так и внутренней архитектуры приложения. Да и где гарантия того, что среднее звено и взаимодействие с ним получится построить эффективнее, чем взаимодействие с сервером БД? К тому же абстрагирование от ДБ получается довольно-таки условное, т.к. для эффективной работы на другом сервере скорее всего придется перекраивать среднее звено. Если оно, конечно, не работает чисто на хранимых процедурах. :o) И чем это тогда лучше двузвенной системы?

← →
iZEN (2003-10-04 12:27) [123]

Для Vuk © (04.10.03 11:57) [122].
Так дело может обернуться обратной стороной: программисты будут вынуждены поддерживать ещё и бизнес-логику в проприетарной БД, таким образом возлагая на себя ответственность за правильную работу б.л. в БД, что, согласитесь, специфично.
Если имеется независимый от БД слой сервера приложений (и клиента), то программистам придётся поддерживать только это ПО (в дебри конфигураций различных БД) они уже могут не смотреть - для них актуально только структура таблиц и связей главный/подчинённый, индексы и всё!
Слой "фасада" (кстати, это - одноимённый паттерн проектирования) успешно (я не вижу каких-то сильных заморочек) реализуется в сервере приложений на том языке программирования, на котором пишется сам сервер (Delphi, Java и т.д.).

← →
Vuk (2003-10-06 10:09) [124]

to euru:
>Выполнение операции - это выполнение каких-то вполне
>определенных действий, по истечению которых операция будет
>считаться завершенной. Причем это никак не зависит,
>регистрируется операция или нет.
Регистрация в любом случае не может повлиять на возможность завершения операции. Это и так понятно.

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

>В первом случае необходимо будет определить дополнительные
>М-сущности для всех возможных комбинаций регистрируемых
>операций.
Вот здесь не понял. Зачем? Ведь в этом случае операция и сущность неразделимы (операция - аналог метода объекта). Вы же не описываете новый класс для введения каждого метода.

to iZEN:
Не понял. А откуда взялась проприетарная БД? О ней вроде как и речи-то не было...

>Слой "фасада" успешно реализуется в сервере приложений
Средний слой для реализации паттерна вовсе не обязателен. С таким же успехом "фасад" может быть расположен на клиенте (в системе с двумя уровнями).

← →
euru (2003-10-06 10:23) [125]

Vuk © (04.10.03 11:57) [122]
Не стоит забывать, что после внедрения продукта мир не замирает, а продолжает развиваться. С течением времени в продукт придется вносить изменения. И чем слабее будут связи между слоями хранения информации, ее обработки и предоставления клиенту, тем легче будет сопровождать такую систему. Пример тому SAP R/3.

Так что с моделью про регистрации операций?

← →
vuk (2003-10-06 10:59) [126]

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

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

← →
euru (2003-10-06 12:39) [127]

>vuk © (06.10.03 10:59) [126]
Сорри. Произошла небольшая задержка между временем получения и временем ответа, поэтому [124] прозевал.

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

>...Ведь в этом случае операция и сущность неразделимы (операция - аналог метода объекта).
Построим модель одной из М-сущностей - например, М1.
class M1 { ... o1() {}; o2() {}; ... }
В этой сущности реализованы операции О1 и О2, но пока они не знают ничего про регистрацию. В ходе дальнейшего анализа выясняется, что некоторые экземпляры (не все) этой сущности должны регистрировать некоторые операции, в общем случае разные для для каждого экземпляра. Допустим, выяснилось, что есть следующие варианты:
- экземпляр не регистрирует операции;
- экземпляр регистрирует операцию О1;
- экземпляр регистрирует факт запуска операции О1 и операцию О2.

Как расширить существующую модель?
1. Использовать наследование - наиболее рекомендуемый способ в ООД (в первом же практическом примере Буч создал описание датчиков, которых нет в реальной системе).
class M1 { ... o1() {}; o2() {}; ... } class M1_O1: M1 { o1() { R.log("M1", "O1", BEFORE); super.o1(); R.log("M1", "O1", AFTER); } } class M1_O1O2: M1 { o1() { R.log("M1", "O1", BEFORE); super.o1(); } o2() { R.log("M1", "O2", BEFORE); super.o2(); R.log("M1", "O2", AFTER); } }
Теперь для каждого вида экземпляра существует собственный класс - потомок сущности М1.
Однако в будущем может так случиться, что процесс регистрации в реальной системе изменится (будут регистрироваться дополнительные операции, поменяется способ регистрации текущих операций, например, регистрация некоторых отменится), тогда нужно будет внести изменения в модель. Если придерживаться данного способа решения, тогда нужно будет порождать дополнительные М-сущности, являющиеся потомками либо класса М1, либо его потомков, которые будут учитывать эти изменения.

2. Реализовать все известные на момент проектирования виды регистрации в самой М-сущности
class M1 { private: isLog_o1(...): Boolean; isLog_o2(...): Boolean; public: o1() { if isLog_o1(BEFORE) R.log("M1", "O1", BEFORE); // Здесь выполняется сама операция if isLog_o1(AFTER) R.log("M1", "O1", AFTER); } o2() { if isLog_o2(BEFORE) R.log("M1", "O2", BEFORE); // Здесь выполняется сама операция if isLog_o2(AFTER) R.log("M1", "O2", AFTER); } }
В данном случае уже усложняется сама М-сущность: мало того, что она сама регистрирует операции, но она еще и сама должна определять, нужно ли регистрировать эту операцию для данного экземпляра. Причем эта проверка будет проводиться во всех регистрируемых операциях всех объектов. И ведь не факт, что проверка будет тривиальной - она может занять непозволительно много времени.

Так ведь еще и М-сущностей может быть гораздо больше, а у них регистрируемых операций может быть тоже не 2. Да и экземпляры этих сущностей регистрируются по-разному.
А теперь еще учтем дополнительный пункт 2 из [119] и попытаемся его реализовать. Во что это выльется? Так ли уж это будет небольшое усложнение?.

← →
Vuk (2003-10-06 13:01) [128]

to euru:
>Во-вторых, такая модель уже не так точно соответствует реальной
>системе
Вроде как система только проектируется и имеется необходимость протоколирования операций. Что значит "неточно соответствует"? Неточно соответствует требованиям? Вроде нет, т.к. требуется протоколирование. Тогда что?

>В данном случае уже усложняется сама М-сущность: мало того, что
>она сама регистрирует операции, но она еще и сама должна
>определять, нужно ли регистрировать эту операцию для данного
>экземпляра.
Совершенно верно. Действие должен выполнять тот, кто обладает максимальными знаниями для выполнения этого действия. Тем более, что для правильной регистрации действия может возникнуть необходимость доступа к внутренней структуре М...

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

>А теперь еще учтем дополнительный пункт 2 из [119] и попытаемся
>его реализовать.

Вот это, как я понял:

>2. Может появиться еще какой-нибудь процесс, подобный
>регистрации. С другой стороны, регистрация может быть вообще
>отменена.
Это как? Нужно иметь возможность прикрутить неизвестно что, неизвестно к чему и неизвестно зачем? Или как?

← →
euru (2003-10-06 14:37) [129]

>Vuk © (06.10.03 13:01) [128]

Так ведь операция уже запротоколирована, а регистрация не имеет никакого к ней отношения.
Пример. Есть сущность "Помещение", у нее есть операции "Войти в Помещение" и "Включить Освещение".
Первая операция включает такие, например, шаги:
1. Открыть дверь в помещение.
2. Войти.
3. Закрыть за собой дверь.
Вторая операция выполняется так:
1. Повернуть рычаг выключателя освещения в положение "Вкл."

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

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

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

← →
vuk (2003-10-06 15:35) [130]

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

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

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

← →
euru (2003-10-10 20:38) [131]

Однако, задержался я с ответом... Однако, работа...
Я буду отвечать снизу вверх.

>Если все именно так, то я не вижу никаких проблем.
Кроме этих координат (что, где и как) нужно еще учитывать координату времени (когда). Обычно реальная система продолжает развиваться и после того, как была спроектирована, разработана и внедрена ее модель. И наверняка наступит такой момент "когда", когда неизвестные до этого "что", "где" и "как" станут вполне определенными. А эти новые изменения нужно будет внести в уже действующую модель. И чем меньше изменений придется внести, тем больше будет вероятность, что в модели не будет ошибок.

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

В чем разница между существенными элементами модели и реальной системы? Возможно я ошибаюсь, но я пока вижу всего два пункта:
1. Отсутствие в модели свойств, которые мы посчитали несущественными.
2. Появление в модели свойств, которых нет в реальной системе, но которые упрощают ее моделирование.

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

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

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

Лучшим решением, по-моему, было бы введение дополнительной сущности, которая обладала бы информацией как о всех М-сущностях, так и о регистраторах. В свою очередь, ни те, ни другие не знали бы о ее существовании. Тогда, с одной стороны, изменение свойств сущностей реальной системы отразилось бы только на соответствующих свойствах сущностей модели и никак не затронуло бы свойства дополнительной сущности. А с другой стороны, изменения, связанные с регистрацией операций, коснулись бы только этой дополнительной сущности и никак не отразились бы на сущностях модели.

Осталось только узнать, как это можно сделать с помощью объектно-ориентированного проектирования.

← →
vuk (2003-10-10 21:53) [132]

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

Проводя аналогии в область анализа разработки ПО приходим к тому, что наблюдаемый объект должен иметь какие-то средства взаимодействия с регистратором а также выдавать ему информацию.
В терминологии объектной модели можно сказать, что М должен предоставлять некий интерфейс, которым воспользуется регистратор. Точно так же регистратор должен предоставить экземпляру М какой-то интерфейс, который М будет использовать для того, чтобы регистратор узнал об изменении состояния М. По наличию конкретного интерфейса у экземпляра M, можно определить, возможно ли подключение к нему конкретного регистратора.

← →
euru (2003-10-11 11:32) [133]

>А в реальных системах бывает по-разному.
Допустим, в этой реальной системе эти объекты независимы.

>Может быть журнал (aka лог), в который кто хочет пишет, что хочет
Кто хочет - это кто? Это может быть либо сам объект, выполняющий операцию, либо объект-наблюдатель, отслеживающий операции объекта, сам же журнал пассивен.

>А может быть подобие датчика
Датчик - это не регистратор, это как раз-таки объект-наблюдатель. Он показывает только текущее состояние отслежываемого объекта, но он может фиксировать в регистраторе эти состояния.

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

>Проводя аналогии ... наблюдаемый объект должен иметь какие-то средства взаимодействия с регистратором а также выдавать ему информацию.
А у меня получилось, что наблюдаемый объект, конечно, может взаимодействовать с регистратором, но не только не должен, но даже и не обязан это делать. Более того, он может даже и не знать, что за ним наблюдают и фиксируют все его операции.

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

И как это выразить в объектно-ориентированном подмножестве объектного проектирования?

← →
Vuk (2003-10-11 13:30) [134]

to euru:
>Датчик - это не регистратор, это как раз-таки
>объект-наблюдатель.
Да. Возможно я не совсем правильно выразился, но имелось в виду именно это.

>Интересно, где это у электродвигателя и лампочки такие
>специальные разъемы, куда нужно подключать вольтметр.
Два (или три) провода есть? Есть. Вот это и есть место подключения. Это место подключения датчика более-менее универсально и туда можно подключить много чего, но нельзя подключить что угодно, например датчик давления воды.

>И где на вольтметре написано, что данный вольтметр предназначен
>для измерения напряжения только на лампочках.
И не надо. В терминах объектной модели можно сказать, что интерфейс для определенного регистратора могут предоставлять объекты совершенно разных классов. И в этом случае без разницы, какого класса объект. Главное - наличие интерфейса взаимодействия с датчиком.

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

← →
euru (2003-10-16 19:41) [135]

У лампочки, правда, проводов нет, но это к делу не относится (это мое мнение, могу и ошибаться).

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

← →
vuk (2003-10-16 20:57) [136]

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

← →
euru (2003-10-16 21:14) [137]

а астрономия?

← →
vuk (2003-10-16 21:26) [138]

И что, там совсем без взаимодействия? А свет + глаз (или что еще)?

← →
euru (2003-10-16 21:47) [139]

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

← →
vuk (2003-10-16 22:00) [140]

>Она просто излучает электромагнитные волны.
То есть опять же поставляет информацию, которая может быть перехвачена и проанализирована. см. [134]:

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

← →
Анонимщик (2003-10-17 11:51) [141]

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

Самой первой была программа, где с заказчиком я встречался два раза в неделю и сразу, без проектирования, все писал. Итог: деньги мне заплатили заранее обусловленные, но сроки растянулись в три раза. А нервов сколько с обоих сторон было ...

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

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

Сейчас у меня проект, который в первом приближении реализован, и тоже много аппаратуры, которая тоже до конца не доделана, но хотя бы ясно, что должно быть. Так вот, поскольку мне с начальником удалось пару раз поговорить о цели проекта и я ориентировался именно на возможности этой аппаратуры, которые хорошо знаю, и предполагал, что программа должна реализововывать работу с этими возможностями, то и делал я ее, в общем, недолго, и совсем без перепроектирования. Но вот пришел заказчик, который ориентируется не на аппаратуру (точнее, на нее, но косвенно), а на необходимость решать с ее помощью свои задачи. В результате: нужно перепроектировать базу данных и нужно "чуть-чуть" перепроектировать программу. Это бы я тоже за те же два месяца (или месяц, возможно) сделал, но... начальник говорит: "Выясни у заказчика, что ему нужно", заказчик говорит: "Выясни с начальником задание, я ему рассказал". Боюсь, никогда ничего не заработает, потому как помню и о другом. Не знаю, нормальная ли это ситуация, но в другом проекте мне заказчик говорил: "А эту кнопку смести на пять пикселов вправо, что он был под тем элементом меню, а то мне от кнопки к меню раз триста в день передодить нужно".

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

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

← →
euru (2003-10-17 16:10) [142]

>vuk © (16.10.03 22:00) [140]
Она не поставляет информацию. Она не проектировалась, для того чтобы поставлять информацию. И от того что мы стали за ней наблюдать, у нее не появилось новых атрибутов и она не стала посылать какие-то особые сообщения наблюдателю. Весь интерфейс ложится на плечи наблюдателя. Это он должен знать, куда нужно встроить свой интерфейс в наблюдаемый объект, чтобы получать от него информацию и правильно ее интерпретировать, а если возможно, то и вмешаться в процесс.

То же самое и с лампочкой. Ее напряжение можно измерить, когда она подключена в эл. цепь. Но это не означает, что в этой цепи обязательно должны быть специальные разъемы для подключения измерительных приборов (хотя было бы удобно). Достаточно добраться до токопроводящих элементов этой цепи. А для этого, возможно, придется прокусить изоляционный материал тех самых проводов. Это возможно сделать для любого прибора, измеряющие электрические характеристики цепи и ее элементов. Причем вряд ли проектом был предусмотрен такой вариант подключения датчиков.

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

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

ИТОГО. В общем случае наблюдаемый объект не должен предоставлять никаких интерфейсов или генерировать специальные события для взаимодействия с наблюдателем, но у него должны быть некие места, куда в дальнейшем можно будет "приткнуть" интерфейс. Наблюдатель должен обладать возможностью встраивания своего интерфейса в наблюдаемый объект для получения от него информации, а при необходимости и для воздействия на сам объект.

>Анонимщик © (17.10.03 11:51) [141]
>Так вот, сравнив усилия, вижу, что попытка полного проектирования экономит и время, и деньги, и нервы.
С этим, по большому счету, не поспоришь. Так только если по мелочам...

← →
Vuk (2003-10-17 16:27) [143]

to euru:
>Она не поставляет информацию.
Да ну? А излучение как же?

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

>А с датчиком измерения давления воды так не получится, потому
>что он измеряет те характеристики, которых нет у электроцепи.
Именно! см. выше.

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

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

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

← →
euru (2003-10-17 18:03) [144]

Сначала не по существу.

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

>Это, извините, уже не наблюдатель, а что-то совсем другое.
Ну, можно назвать его агентом. Тоже ведь наблюдает, но при случае и наган может вытащить и пострелять. :)

А теперь по теме.
С вашей легкой руки я узнал про аспектно-ориентированное программирование. Программа про регистрирование операций на языке, поддерживающем АОП, выглядела бы следующим образом (это псевдокод):
class M1 { void o1(int i) {}; void o2(int i) {}; } class M2 { void o2(double d) {}; void o3() {}; } class M3 { void o1() {}; void o3() {}; } class Writer { static void log(string s) { write(s); }; }
Обращаю внимание. М-сущности являются независимыми классами и не имеют каких-либо механизмов для регистрации своих операций. Регистратор (Writer) тоже ничего не знает об М-сущностях.
aspect Log { pointcut log_o1() = "*.o1(*)"; pointcut log_o2() = "*.o2(*);" pointcut log_o3() = "*.o2();" advice call(log_o1()) : around { Writer.write("Вызов операции o1()"); trigger(); // Здесь происходит вызов метода o1 нужного класса Writer.write("Операция о1 завершена"); } advice call(log_o2()) : before { Writer.write("Вызов операции o2()"); } advice call(log_o2()) : after { Writer.write("Операция о3 завершена"); }
При компиляции программы все места, где будет происходит вызов операций o1, o2, o3 независимо от типа класса М-сущности и параметра операции (кроме о3), этот вызов будет заменяться соответсвующей последовательностью описанной в аспекте Log.
Все будет регистрироваться, при этом не понадобилось добавлять дополнительных атрибутов и событий в М-сущности, что пришлось бы сделать в ОО-языке.

← →
euru (2003-10-17 19:40) [145]

Ошибочка небольшая
aspect Log { pointcut log_o1() = "*.o1(*)"; pointcut log_o2() = "*.o2(*);" pointcut log_o3() = "*.o3();" advice call(log_o1()) : around { Writer.write("Вызов операции o1()"); trigger(); // Здесь происходит вызов метода o1 нужного класса Writer.write("Операция о1 завершена"); } advice call(log_o2()) : before { Writer.write("Вызов операции o2()"); } advice call(log_o3()) : after { Writer.write("Операция о3 завершена"); } }

← →
euru (2003-10-20 14:46) [146]

← →
euru (2003-10-21 19:30) [147]

← →
Vuk (2003-10-21 19:36) [148]

Я дико извиняюсь, но отвечать пока не имею времени.:o(

---|Ветка была без названия|--- Найти похожие ветки