Смысл такой
нужно функции из 1 ой использовать во второй и наоборот =)
как быть?)

 

zum
вынести в 3ю

 

Вынести все функции, которые могут использоваться перекрестно в третью библиотеку. Или каждую разделить на 2 части: Core и Interface.

и никак иначе...

 

агентами
екзекуте

всё зависит как курить

 

Вынести все функции, которые могут использоваться перекрестно в третью библиотеку. Или каждую разделить на 2 части: Core и Interface.

и никак иначе...

Расскажите подробнее о разделении библиотек на core и interface, пожалуйста.

 

ABarmin
Это просто условные названия, назвать можно как угодно.
Смысл в том, чтобы выделить функции по общему признаку в одну библиотеку.
Функции работающие внутри системы, которые вызываются из других функций, записать в одной библиотеке.
Функции, которые вызывают внутренние функции записать в другую библиотеку.
Во второй сделать Use первой.

Мой подход разделять функции по библиотекам в зависимости от работы: внутренние (libName) и для работы с GUI (libName_UI)
Например, у меня куча функций для работы с пользовательским интерфейсом(выбор документов, открытие разных окон, поиск) объединяю их в одну библиотеку libname_UI, в весь механизм поиска осуществляется во внутренней библиотеке libName.

 

ABarmin
Это просто условные названия, назвать можно как угодно.
Смысл в том, чтобы выделить функции по общему признаку в одну библиотеку.
Функции работающие внутри системы, которые вызываются из других функций, записать в одной библиотеке.
Функции, которые вызывают внутренние функции записать в другую библиотеку.
Во второй сделать Use первой.

Мой подход разделять функции по библиотекам в зависимости от работы: внутренние (libName) и для работы с GUI (libName_UI)
Например, у меня куча функций для работы с пользовательским интерфейсом(выбор документов, открытие разных окон, поиск) объединяю их в одну библиотеку libname_UI, в весь механизм поиска осуществляется во внутренней библиотеке libName.

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

Нет никакого а-ля нормальный лоадер для лотуса? Ну, кроме execute |User "some"|, конечно?)

 

плохо себе представляю как это можно разделить...

те первая библиотека отвечает за документы класс DocumentManager
вторая отвечает за расписание класс TimeManager

те получается что из первой надо проверять расписание при определенных условиях, а из второй документы при работе с раписанием

хоть убейте не представляю как это сделать даже через третью библиотеку

 

Можно:
1) параметры функций проверки сделать типа Variant;
2) для классов DocumentManager и TimeManager сделать базовый класс(ы).
Вы бы хоть описания функций привели, чтобы было о чём рассуждать.

 

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

 

сделать включение одного класса в другой...
например патерн декоратор http://en.wikipedia.org/wiki/Decorator_pattern

Добавлено: или на русском http://habrahabr.ru/post/86255/

 

Декоратор - не совсем то.

 

Декоратор - не совсем то.

этпочему?

 

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

 

задача увязать разный ф-ционал, кот. может наращиваться

 

Если все части функционала находятся в одной либе, то тут и проблем нет, хоть декоратором, хоть наследованием.

Ладно, смотрим пример.

Библиотека data.lotus.DTProcess

Use "data.lotus.DTTask"

public class DTProcess as DTDocument
private tasks as DTList

public function getTasks() as DTList
if (me.tasks is nothing) then
set me.tasks = new DTList()

' получение объектов DTTask волшебным кодом
end if
set getTasks = me.tasks
end function
end class

Библиотека data.lotus.DTTask

public class DTTask as DTDocument
private parentProcess as DTProcess

public function getParentProcess() as DTProcess
if (me.parentProcess is nothing) then
' получение объекта DTProcess волшебным кодом
end if
set getParentProcess = me.parentProcess
end function
end class

Чтобы второй класс заработал надо подключить data.lotus.DTProcess, что вызовет ошибку компиляции про рекурсивный USE.

 

например патерн декоратор http://en.wikipedia.org/wiki/Decorator_pattern

Зачем давать на буржуинским, если то же самое есть на русском?

Добавлено:

Если все части функционала находятся в одной либе, то тут и проблем нет, хоть декоратором, хоть наследованием.

Вы сами ответили на свой вопрос + ещё выше люди всё сказали.
Без одной библиотеки либо без классов-интерфейсов в 3-й общей либо без использования Execute, т.е. так, как вы хотите (вероятно волшебным образом), оно работать не будет, так чего возить г-но по унитазу?

 

Зачем давать на буржуинским, если то же самое есть на русском?

родной язык для большинства "технологий" - англицкий, интерпретация в русской версии может сильно отличаться

 

Зачем давать на буржуинским, если то же самое есть на русском?

Добавлено: Вы сами ответили на свой вопрос + ещё выше люди всё сказали.
Без одной библиотеки либо без классов-интерфейсов в 3-й общей либо без использования Execute, т.е. так, как вы хотите (вероятно волшебным образом), оно работать не будет, так чего возить г-но по унитазу?

Остается только Execute.

 

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