Хотелось бы узнать, как технически удобнее будет разделить программу на 2 версии lite и pro? Пишу на Delphi.
Делать через DEFINE/IFDEF не получится — слишком много отличий. Можно скопировать папку и делать PRO версию в ней, но тогда одинаковые изменения нужно будет вносить сразу в 2-х проектах (например, правка какого-то бага).
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте!
А>Хотелось бы узнать, как технически удобнее будет разделить программу на 2 версии lite и pro? Пишу на Delphi. А>Делать через DEFINE/IFDEF не получится — слишком много отличий. Можно скопировать папку и делать PRO версию в ней, но тогда одинаковые изменения нужно будет вносить сразу в 2-х проектах (например, правка какого-то бага).
А>Если кто имеет опыт, прошу поделиться.
А>Спасибо за внимание!
Я думаю, Вам поможет полиморфизм и наследование.
Наследуйте Pro версии классов от Lite расширяя их функциональность. И в зависимости от опций поставки изменяйте набор классов (Абстрактная фабрика, например).
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте!
А>Хотелось бы узнать, как технически удобнее будет разделить программу на 2 версии lite и pro? Пишу на Delphi. А>Делать через DEFINE/IFDEF не получится — слишком много отличий. Можно скопировать папку и делать PRO версию в ней, но тогда одинаковые изменения нужно будет вносить сразу в 2-х проектах (например, правка какого-то бага).
А>Если кто имеет опыт, прошу поделиться.
$IFDEF'ами не может не получиться. Это, как правило наиболее простой и надежный способ. Но некрасивый, особенно если появится необходимость добавить Standаrd версию.
А>скопировать папку и делать PRO версию
Лучше сразу забыть об этом.
Ну а самый грамотный способ — это как сказал Time. Но он самый геморный и сложный, т.к. переделки скорее всего затронут всю программу. Технически довольно гиморно разбить сложную форму на базовую и наследника. А поскольку у вас сейчас есть full версия и вы хотите выделить Lite — то подумайте хорошенько перед тем как выбрать этот способ.
P.S. Все зависит от сложности программы, объема кода и планируемых отличий между версиями, будут ли выпускаться другие версии, квалификации разработчиков, наличии ресурсов, тяги к совершенству. Мне и моим ребятам приходилось использовать все 3 способа. Для лучшего совета недостаточно информации.
NW>Ну а самый грамотный способ — это как сказал Time. Но он самый геморный и сложный, т.к. переделки скорее всего затронут всю программу. Технически довольно гиморно разбить сложную форму на базовую и наследника. А поскольку у вас сейчас есть full версия и вы хотите выделить Lite — то подумайте хорошенько перед тем как выбрать этот способ.
Нет, тут наоборот, есть программа, и из нее делается PRO-версия, а та, что есть сейчас будет Standard Edition. Но, эти программы будут развиваться обе, и нужно как то сразу сделать правильную структуру, а то потом придется переделывать еще больше чем сейчас...
NW>P.S. Все зависит от сложности программы, объема кода и планируемых отличий между версиями, будут ли выпускаться другие версии, квалификации разработчиков, наличии ресурсов, тяги к совершенству. Мне и моим ребятам приходилось использовать все 3 способа. Для лучшего совета недостаточно информации.
Отличия будут в как в плане плане функционала, так и в плане интерфейса (но процентов 60-70 форм будут одинаковые в обоих программах).
Я так понимаю, инструмента, который бы как-то упрощал такие вещи, нет?
А>>Хотелось бы узнать, как технически удобнее будет разделить программу на 2 версии lite и pro? Пишу на Delphi. А>>Делать через DEFINE/IFDEF не получится — слишком много отличий. Можно скопировать папку и делать PRO версию в ней, но тогда одинаковые изменения нужно будет вносить сразу в 2-х проектах (например, правка какого-то бага).
А>>Если кто имеет опыт, прошу поделиться.
А>>Спасибо за внимание!
T>Я думаю, Вам поможет полиморфизм и наследование.
T>Наследуйте Pro версии классов от Lite расширяя их функциональность. И в зависимости от опций поставки изменяйте набор классов (Абстрактная фабрика, например).
Почитал про абстр. фабрику, это вроде то, что нужно (хотя в паттернах познания у меня почти 0, надо еще будет разобраться). Там еще все сделано на интерфейсах, а в интерфейсах нет переменных — как быть в таком случае? Например, класс для сохранения настроек программы. В про версии будут теже настройки что и в лайт, и плюс еще что-нибудь — это делается простым наследованием?
Здравствуйте, fmcoder, Вы писали:
F>Почитал про абстр. фабрику, это вроде то, что нужно (хотя в паттернах познания у меня почти 0, надо еще будет разобраться). Там еще все сделано на интерфейсах, а в интерфейсах нет переменных — как быть в таком случае? Например, класс для сохранения настроек программы. В про версии будут теже настройки что и в лайт, и плюс еще что-нибудь — это делается простым наследованием?
Конечно делается. Вам ничего не мешает объявить Properties в интерфейсе. Лучше не объявлять переменные, если Ваш язык не поддерживает Properties, а создать тогда методы доступа, например, GetMaxFileLength(), и, соотвественно, SetMaxFileLength()
Здравствуйте, fmcoder, Вы писали:
NW>>Ну а самый грамотный способ — это как сказал Time. Но он самый геморный и сложный, т.к. переделки скорее всего затронут всю программу. Технически довольно гиморно разбить сложную форму на базовую и наследника. А поскольку у вас сейчас есть full версия и вы хотите выделить Lite — то подумайте хорошенько перед тем как выбрать этот способ.
F>Нет, тут наоборот, есть программа, и из нее делается PRO-версия, а та, что есть сейчас будет Standard Edition. Но, эти программы будут развиваться обе, и нужно как то сразу сделать правильную структуру, а то потом придется переделывать еще больше чем сейчас...
F>Отличия будут в как в плане плане функционала, так и в плане интерфейса (но процентов 60-70 форм будут одинаковые в обоих программах). F>Я так понимаю, инструмента, который бы как-то упрощал такие вещи, нет?
ООП — это не подходящий инструмент? ИМХО благодаря написанию наследников тех классов, которые реализуют базовый функционал, можно получить PRO-версию, при этом исправление ошибок, свойственных обоим версиям будет заключатся в исправлении предков.
Если ООП не катит, то может отделить основную часть программы( которая выполняет работу) от GUI и сделать версии программы, c отличными GUI( т.е. базовая версия реализует тот же функционал, что и PRO, просто его вызвать нельзя)?
Сразу скажу, что наследование явно не тот инстумент который вам нужен. Как бы они не были хороши в теории. Ну разве что вы не боитесь погрязнуть в иерархиях классов, интерфейах и прочих...
В голове крутятся две идеи:
1) Ядро системы обоих версий сделать общим, ограничения версий делать только на уровне UI обрубанием неоплаченной функциональности. В принципе, подход соответствует DEFINE/IFDEF с его достоинствами и недостатками. Разве что проверки будут только в UI.
2) Второй подход мне нравиться больше, но я не совсем уверен в сложности его реализации Основан он на использовании системах контроля версий, ведении двух бранчей на каждую версию и мерже изменений из Lite в Pro ветку.
Хотя даже во втором подходе можно сделать ядро общим, получив некий симбиоз обоих вариантов.
Здравствуйте, nejest, Вы писали:
F>>Отличия будут в как в плане плане функционала, так и в плане интерфейса (но процентов 60-70 форм будут одинаковые в обоих программах). F>>Я так понимаю, инструмента, который бы как-то упрощал такие вещи, нет? N>ООП — это не подходящий инструмент? ИМХО благодаря написанию наследников тех классов, которые реализуют базовый функционал, можно получить PRO-версию, при этом исправление ошибок, свойственных обоим версиям будет заключатся в исправлении предков.
Неправильный подход — надо делать один базовый класс, который определяет интерфейс и возможно какие-то хелперы и от него два наследника — full и lite. И если уж наследовать один от другого, то lite от full, а не наоборот. Вообще же, конечно ifdef'ы и прочая условная компиляция в данном случае рулит :)
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте!
А>Хотелось бы узнать, как технически удобнее будет разделить программу на 2 версии lite и pro? Пишу на Delphi. А>Делать через DEFINE/IFDEF не получится — слишком много отличий. Можно скопировать папку и делать PRO версию в ней, но тогда одинаковые изменения нужно будет вносить сразу в 2-х проектах (например, правка какого-то бага).
На Delphi я не писал, но на C++ сделал бы так:
Разделил бы lite и pro и на уровне проектов (.vcproj в Visual studio). Всю общую часть (общие классы, UI формы и т.д) вынес бы в отдельную библиотеку, чтобы избавиться от дублирования.
Это позволит уменьшить зависимость между проектами и даст возможность собирать их по-отдельности нажатием одной кнопки
Ну насколько я понимаю задачу, у вас отличия про от лайт версии будут заключаться в дополнитиельных контролах и пунктах меню? Тогда можно сделать вообще просто, иметь одну программу и прятать менюшки в лайт версии. Это, конечно, не страсть как надежно в плане взлома, но я думаю, для многих случаев подойдет.
Здравствуйте, Vamp, Вы писали:
V>Ну насколько я понимаю задачу, у вас отличия про от лайт версии будут заключаться в дополнитиельных контролах и пунктах меню? Тогда можно сделать вообще просто, иметь одну программу и прятать менюшки в лайт версии. Это, конечно, не страсть как надежно в плане взлома, но я думаю, для многих случаев подойдет.
Не совсем так, отличия не в плане скажем в лайт версии N контролов, а в про версии N+M — это, конечно, тоже есть, но также есть множество других отличий, и простым Visible := False тут точно не отделаться.
Всем спасибо за советы! Пока начну наверное с наследования/интерфейсов/паттернов, это как мне кажется наиболее подходящий, хотя им не самый простой путь, а там как пойдет.
Здравствуйте, fmcoder, Вы писали:
F>Всем спасибо за советы! Пока начну наверное с наследования/интерфейсов/паттернов, это как мне кажется наиболее подходящий, хотя им не самый простой путь, а там как пойдет.
Не забудь рассказать про результаты, ибо очень интересно.
И еще я бы посоветовал сбацать небольшой прототипчик системы
F>>Всем спасибо за советы! Пока начну наверное с наследования/интерфейсов/паттернов, это как мне кажется наиболее подходящий, хотя им не самый простой путь, а там как пойдет. A>Не забудь рассказать про результаты, ибо очень интересно. A>И еще я бы посоветовал сбацать небольшой прототипчик системы A>СУВ, Aikin A>P.S. Ну не верю я в "магию наследования"
Вот начал делать через наследование, на прототип времени нет, все надо сделать быстро
Пока полет нормальный, выделено много общих кусков кода, да и в целом даже становится лучше как-то...
Здравствуйте, fmcoder, Вы писали:
F><...> все надо сделать быстро
Очень плохой признак.
F>Пока полет нормальный, выделено много общих кусков кода, да и в целом даже становится лучше как-то...
На начальном этапе всегда так. Гемор начинается на этапах развития функциональности в уже заложенной архитектуре и сопровождения.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, fmcoder, Вы писали:
F>><...> все надо сделать быстро КЛ>Очень плохой признак.
F>>Пока полет нормальный, выделено много общих кусков кода, да и в целом даже становится лучше как-то... КЛ>На начальном этапе всегда так. Гемор начинается на этапах развития функциональности в уже заложенной архитектуре и сопровождения.
Как раз при использовании других подходов неизбежно приводящих к дублированию кода и поведению системы не зависящему от кода (что приводит к отсуствию проверок компилятором), а зависящему от настроек компилярота (директивы препроцессора и прочее) количество проблем с развитием системы будет увеличиваться и рано или позно встанет необходимость "написать всё заново"
Здравствуйте, Time, Вы писали:
T>Как раз при использовании других подходов неизбежно приводящих к дублированию кода и поведению системы не зависящему от кода (что приводит к отсуствию проверок компилятором), а зависящему от настроек компилярота (директивы препроцессора и прочее) количество проблем с развитием системы будет увеличиваться и рано или позно встанет необходимость "написать всё заново"
Поверьте, применение полиморфизма для разделения версий (на Lite и Pro) приведёт к неменьшим проблемам, чем применение для той же цели директив препроцессора. Правильный подход, на мой взгляд, описан в сообщении Aikin'а
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Time, Вы писали:
КЛ>Поверьте, применение полиморфизма для разделения версий (на Lite и Pro) приведёт к неменьшим проблемам, чем применение для той же цели директив препроцессора. Правильный подход, на мой взгляд, описан в сообщении Aikin'а
В любых задачах чрезмерное злоупотребление полиморфизмом приводит к известным проблеммам. В юности я использовал директивы для разделения версий, с появлением опыта и ростом сложности\колличества версий этих программ, их пришлось переделывать, используя наследование\полиморфизм, о чем никто за последние 5 лет не пожалел. Но мой случай значительно более сложен, изначально было 7 разновидностей программ, каждая из которых имела по 6 отдельных версий, общего кода между которыми было от 50 до 80 процентов. Выделить базовые классы и формы — это очень непростая была задача.
Здравствуйте, Time, Вы писали:
А>>Хотелось бы узнать, как технически удобнее будет разделить программу на 2 версии lite и pro? Пишу на Delphi. T>Я думаю, Вам поможет полиморфизм и наследование. T>Наследуйте Pro версии классов от Lite расширяя их функциональность. И в зависимости от опций поставки изменяйте набор классов (Абстрактная фабрика, например).
Ужас: о более бестолковом использовании наследования ещё не слышал. Ладно бы реализовывать интерфейсы предложили бы по-разному, так ведь
T>Наследуйте Pro версии классов от Lite расширяя их функциональность.
Более надёжного способа связать намертво компоненты программы вообразить непросто. А когда Enterprise версия появится, ещё раз всё продублируем?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Аноним, Вы писали:
А>Хотелось бы узнать, как технически удобнее будет разделить программу на 2 версии lite и pro? Пишу на Delphi. А>Делать через DEFINE/IFDEF не получится — слишком много отличий. Можно скопировать папку и делать PRO версию в ней, но тогда одинаковые изменения нужно будет вносить сразу в 2-х проектах (например, правка какого-то бага).
А не можете рассказать, как получаются связаны "слишком много отличий" и "Делать через DEFINE/IFDEF не получится"? Что-то не ясно, как из второго следует первое
Help will always be given at Hogwarts to those who ask for it.
Основан он на использовании системах контроля версий, ведении двух бранчей на каждую версию и мерже изменений из Lite в Pro ветку. 
