ООП в Lotus Nd

[oshmianski]

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

Бурная дискуссия развернулась по сабжу вот

Ссылка скрыта от гостей

.

Интересно ваше мнение.

Как по мне, так старые проекты трогать точно не стоит. А вот новые можно и попробовать.
У меня в этом опыта нет, но очень хочется попробовать. Может есть у кого идеи, ссылки, готовые решения (применительно к Lotus).

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

 

[GROMILA]

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

Хотя весьма полезно для лотусистов будет узнать о существовании дизайн-паттернов,
о которых в статье идет повествование. Многие в лотус приходят не имея опыта разработки
серьезных проектов на ООП языках С++, C# и знают лишь LotusScript. Данная статья может
очень продвинуть подобных лотусистов и открыть глаза на мир.

 

[oshmianski]

Для: GROMILA
мне интересен опыт людей, уже пользующих \ использовавших данный подход.
судя по постам на форуме интертраста, без опыта проектирования систем и использования ООП можно в конце концов нарваться на переписывание всей системы.

твой скептицизм мне не понятен. был "горький" опыт?

 

[GROMILA]

Вопрос не совсем понятен. Переделывать прийдется в любом случае, если система будет плохо спроектирована, причем тут подход?

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

Простой тест на пригодность лотуса к ООПу:
Как вы пишете?
Messagebox "блаблабла", 16, "Ошибка"
или
Messagebox "блаблабла", MB_ICONSTOP, "Ошибка"


идея проста - насколько удобно повсеместно применять MB_ICONSTOP, на столько LS удобен для работы с классами

 

[oshmianski]

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

а пишу я вот так (процедура вынесена в библу):

Sub MsgOk(MsgStr As String, MsgType As String, MsgTitle As String)
'****************************************************Описание****************
**************************************************
' Аргументы:
' MsgStr As String = строка сообщения
' MsgType As String = тип сообщения ("Info", "Quest", "Exclam", "Error")
' MsgTitle As String = заголовок сообщения
'****************************************************************************
**************************************************
'MB_ICONSTOP			16 	Stop sign
'MB_ICONQUESTION		32 	Question mark 
'MB_ICONEXCLAMATION			 48 	Exclamation point
'MB_ICONINFORMATION			 64 	Information

On Error Goto errorhandler
Select Case Lcase(MsgType)
Case "error": Msgbox MsgStr, 0 + 16, MsgTitle
Case "quest": Msgbox MsgStr, 0 + 32, MsgTitle
Case "exclam": Msgbox MsgStr, 0 + 48, MsgTitle
Case "info": Msgbox MsgStr, 0 + 64, MsgTitle
Case Else: Msgbox MsgStr, 0 + 64, MsgTitle
End Select	
Ex:
Exit Sub
errorhandler:
Print "MsgOk error: " & Error, Erl
Resume Ex
End Sub

/****пример использования****/
MsgOk Error, "Error", "Ошибка"

 

[GROMILA]

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

Подобная ситуация возникает и с классами. Объявление базового класса довольно часто приходится тягать по всей проге и возникает ситуация, гогда ГРУДА КЛАССОВ СУПЕРКЛАССНЫХ написана, а заюзать ты их не можешь по-пацански, можешь только привести к типу Variant, лишая себя кульных рюшечек (подсказки методов по точке) и теряешь контроль типов. Директива %IF в IDE не работает - корявка лотусиная.
И ты начинаешь понимать, что времени на уже эту новуюю ООПКОДОСЛИЗЬ уходит еще больше и даже ТУПИК в разработке.

Но О БОЖЕ есть старое доброе структурное программирование, на которое всеми лапами нацелен Лотус.
Спроектируй программу по функциональному признаку, вынеси функции в библиотеки и ФСЕ:
"легко готовить, легко стирать" и нафига козе баян??? Лотусу-Лотусовое

В статье меня особенно прибили классы-обертки. Я первый застрелю такого прогера, который будет прятать от меня реальные названия полей, а я буду по коду читать его Set и Get не видя перед глазками названий полей в базе. Нужно просто проектировать базу в каком-нить Visio или Rose и далее юзать в лотусе, радуясь лаконичному и правильному именованию.

 

[oshmianski]

Для: GROMILA
когда ты говоришь о структурном программировании, ты имеешь в виду процедурное?
если так, то не могу с тобой согласиться, ибо использование базовых классов дает много преимуществ.
взять хотябы многоразовое использование скрипта, а не тупое копирование процедур.

кроме того, всплывающие подсказки после точки реализованы только для родных лотусовых классов (пока). так что этими рюшечками я и так воспользоваться не смогу в User Defined Classes.

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

 

[oshmianski]

Для: GROMILA
link removed тебе реальный пример полезности использования подхода ООП.
был бы у него класс, в который бы он обворачивал свой основной док + действия для работы с этим доком зашивались бы в методы этого класса, проблем бы не было с журнализацией.

это все естественно, имхо

 

[GROMILA]

когда ты говоришь о структурном программировании, ты имеешь в виду процедурное?

И да и нет, процедура - это термин другого уровня.

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

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

кроме того, всплывающие подсказки после точки реализованы только для родных лотусовых классов (пока). так что этими рюшечками я и так воспользоваться не смогу в User Defined Classes.

ТЕМ БОЛЕЕ, ЭТО ЛИ НЕ УЖАС ?
плюс все методы в разделе Declaration добивают прикладом.

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

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

 

[v2v]

Возможно ли каким либо образом использовать классы ( ООП впринципе ) написанные на с ++ использовать в Lotuse .. ну допустим я создам библиотеку .. а как библиотеку подключить с использованием Lotus Script я уже разобрался, осталось понять, каким образом работать классами.
Благодарю за помощь.

 

[Fossil Code]

Бурная дискуссия развернулась по сабжу вот

Ссылка скрыта от гостей

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

Не собираюсь высказываться в духе "религиозных войн" вокруг ООП подхода, но в Лотусе, IMAO, классы используются исключительно как средство доступа к библиотекам интерфейсных (в широком смысле интерфейса к системе) функций. Методология ООП и т.п. для данного случая, по-моему не особенно релевантна в рамках разработки на LS.

 

[Elena Nefedova]

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

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

Что же касается спора между ООП и процедурным подходом - оба они "выросли" из жизни. А жизнь у нас такая - то к маме обратишься, то к папе...

 

[Mihal]

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

Например, при нажимании на кнопку почти всегда надо: 1. Попросить подтверждение операции, 2. Выполнить операцию, 3. Выдать сообщение о завершении операции. При этом в стандартный класс прошивается и игра с AutoReload'ом (что почти всегда надо) и "держание" ws, uidoc, doc. И весь код сосредоточен в одном месте (что опять же позволяет быстрее разобраться в уже написаном).

В общем, я за ООП в Лотусе.

 

[Mihal]

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

Что предлагает статья? Вычленяем объекты и, отдельно!, действия. Пишем классы под объекты. Пишем по классу под каждое действие. После чего уже ВО ВРЕМЯ выполнения программы связываем класс с действием (метод Accept в статье). Я правильно пониманию? Ну и сделали такую мегаполезную вешчь как "фабрика". Мы туда документ - оно нам на выходе объект. Ведь, опять же, зачастую каждому типу лотус-докумсенов отдельный класс. Но не слишком ли много классов будет? И ведь не все действия применимы ко ВСЕМ объектам. Не будет ли слишком много "ненужных" действия (в методе, собственно, будет пустота). Хотя тут можно просто не переопределять в дочернем... И как лучше классов разбить по библиотекам (раньше у меня одна библиотека - один класс).