ООП в Lotus Nd

Тема в разделе "Lotus - Программирование", создана пользователем oshmianski, 6 окт 2006.

  1. oshmianski

    oshmianski Гость

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

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

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

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

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

    GROMILA Well-Known Member

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

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

    oshmianski Гость

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

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

    GROMILA Well-Known Member

    Регистрация:
    8 апр 2004
    Сообщения:
    297
    Симпатии:
    0
    Вопрос не совсем понятен. Переделывать прийдется в любом случае, если система будет плохо спроектирована, причем тут подход?

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

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


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

    oshmianski Гость

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

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

    Код (Text):
    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", "Ошибка"
     
  6. GROMILA

    GROMILA Well-Known Member

    Регистрация:
    8 апр 2004
    Сообщения:
    297
    Симпатии:
    0
    Ну вот :( ты используешь числовые константы и более того, ты их подменил строковыми константами.
    Это лишний раз говорит о том, что при тягании за собой файла LSS рано или поздно возникнет неразрешимая ситуация, лотус будет ругаться на дубли объявлений и ты плюнешь на все и начнешь использовать константы!!!

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

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

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

    oshmianski Гость

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

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

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

    oshmianski Гость

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

    это все естественно, имхо
     
  9. GROMILA

    GROMILA Well-Known Member

    Регистрация:
    8 апр 2004
    Сообщения:
    297
    Симпатии:
    0
    И да и нет, процедура - это термин другого уровня.

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

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

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

    v2v Гость

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

    Fossil Code Гость

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

    Elena Nefedova Гость

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

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

    Mihal Гость

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

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

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

    Mihal Гость

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

    Что предлагает статья? Вычленяем объекты и, отдельно!, действия. Пишем классы под объекты. Пишем по классу под каждое действие. После чего уже ВО ВРЕМЯ выполнения программы связываем класс с действием (метод Accept в статье). Я правильно пониманию? Ну и сделали такую мегаполезную вешчь как "фабрика". Мы туда документ - оно нам на выходе объект. Ведь, опять же, зачастую каждому типу лотус-докумсенов отдельный класс. Но не слишком ли много классов будет? И ведь не все действия применимы ко ВСЕМ объектам. Не будет ли слишком много "ненужных" действия (в методе, собственно, будет пустота). Хотя тут можно просто не переопределять в дочернем... И как лучше классов разбить по библиотекам (раньше у меня одна библиотека - один класс).
     
Загрузка...
Похожие Темы - ООП Lotus
  1. Trafik
    Ответов:
    0
    Просмотров:
    535
  2. NLP
    Ответов:
    10
    Просмотров:
    3.555
  3. Sevas
    Ответов:
    1
    Просмотров:
    1.060
  4. Shouldercannon
    Ответов:
    1
    Просмотров:
    2.325
  5. akat
    Ответов:
    11
    Просмотров:
    5.289

Поделиться этой страницей