Лучший подход к модульному программированию в Delphi - PullRequest
11 голосов
/ 15 августа 2011

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

Позвольте мне опубликовать то, что я уже написал там .

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

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

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

Что мне делать, чтобы быстрее исправлять ошибки во многих проектах?Я думаю об одном из следующих подходов.Если у вас есть идеи получше, пожалуйста, дайте мне знать.

  • Поместите общий код в отдельные и автономные модули PAS, поэтому, когда в одном из них есть исправление ошибки, достаточно скопировать его на всепроекты (перезаписать старые файлы) и перекомпилировать все из них.Это означает, что каждый модуль копируется столько раз, сколько проектов он использует.

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

  • Создание BPL для всего общего кода, но связывание ихEXE-файлы, так что EXE-файлы автономны.

Для меня это кажется лучшим решением сейчас, но есть некоторые недостатки.Если я исправлю ошибку в BPL, каждый программист должен будет обновить BPL на своем компьютере.Что если они забудут это сделать?Тем не менее, я думаю, что это небольшая проблема.Если мы позаботимся о том, чтобы информировать друг друга об изменениях, все должно быть хорошо.Как вы думаете?

  • И последняя идея, предложенная CodeInChaos (я не знаю, правильно ли я ее понял).Обмен файлами PAS между проектами.Это, вероятно, означает, что нам придется хранить общий код в отдельной папке и заставить все проекты искать этот код там, верно?И всякий раз, когда необходимо изменить проект, он должен быть загружен из SVN вместе с папкой общих файлов, я думаю.Каждое изменение в общем коде должно вызывать перекомпиляцию каждого проекта, использующего этот код.

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

Большое спасибо.

Ответы [ 2 ]

5 голосов
/ 15 августа 2011

Вы говорите:

  • Создайте BPL для всего общего кода, но свяжите их с EXE-файлами, поэтому что EXE-файлы автономны.

Вы не можете связать BPL в исполняемый файл. Вы просто связываете в отдельных единицах, которые также находятся в BPL. Таким образом, вы на самом деле не используете или даже не нужно BPL вообще.

BPL предназначены для использования в качестве общего кода, то есть вы помещаете общий код в один или несколько BPL и используете его из каждого из .exes, .dll или других .bpls. Исправления (если они не изменяют открытый интерфейс BPL) просто требуют перераспределения этого фиксированного BPL.

Как я уже сказал, определитесь с открытым интерфейсом DLL, а затем не меняйте его. Вы можете добавить подпрограммы, типы и классы, но вы не должны изменять общедоступные интерфейсы любых существующих классов, типов, интерфейсов, констант, глобальных переменных и т. Д., Которые уже используются. Таким образом, исправленная версия BPL может быть легко распространена.

Но учтите, что BPL сильно зависят от версии компилятора. Если вы используете новую версию компилятора, вам также придется перекомпилировать BPL. Вот почему имеет смысл давать суффиксы BPL, такие как 100, 110 и т. Д., В зависимости от версии компилятора. Затем исполняемый файл, скомпилированный с версией компилятора 15.0, будет использовать BPL с суффиксом 150, а исполняемый файл, скомпилированный с версией 14.0, будет использовать BPL с суффиксом 140. Таким образом, разные версии BPL могут мирно сосуществовать. Суффикс может быть установлен в настройках проекта.

Как вы управляете разными версиями? Создайте каталог со структурой, подобной моей, для моего ComponentInstaller BPL (этого эксперта вы можете увидеть в Delphi / C ++ Builder / RAD Studio XE IDE в меню Компоненты -> Установить компонент):

Projects
  ComponentInstaller
    Common
    D2007
    D2009
    D2010
    DXE

Общий каталог содержит файлы и ресурсы .pas (точечные рисунки и т. Д.), Совместно используемые каждой версией, а каждый из каталогов Dxxxx содержит .dpk, .dproj и т. Д. Для этой конкретной версии BPL. Каждый из пакетов использует файлы в общем каталоге. Конечно, это можно сделать для нескольких BPL одновременно.

Система управления версиями может сделать это намного проще, кстати. Просто убедитесь, что у каждой версии BPL свой суффикс.

Если вам действительно нужны автономные исполняемые файлы, вы не используете BPL, а просто соединяете их в отдельных модулях. Опция "compile with BPLs" управляет этим.

3 голосов
/ 15 августа 2011

С моей точки зрения, пытаясь управлять такими артефактами, как блоки Delphi, библиотеки и исполняемые файлы, вы выполняете поиск в неправильном месте.Я предлагаю вам развернуться и начать с рефакторинга кода, основанного на реализации Шаблоны проектирования .

Например, все общие функции могут быть помещены в один класс Singleton , экземпляры общих классов могут быть созданы с помощью Abstract Factory , классы могут взаимодействовать через собственную реализацию интерфейсов Delphiвместо прямого использования и тд.Даже вы можете реализовать Фасад для всех общих частей проектов.

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

Некоторые другие вещи:

  1. Конечно, вы должныследуйте предложению @CodeInChaos и делитесь одной копией исходного файла между всеми проектами вместо того, чтобы копировать ее в каждый проект вручную.Это может быть полезно, если вы примете какой-то стандарт для среды разработки, который будет обязательным для всех разработчиков (одинаковая структура папок, расположение библиотек, настройки среды).
  2. Попробуйте проанализировать процесс сборки и развертывания: для меня этовыглядит ненормально, когда решение не построено с последней версией кода и не проверено перед развертыванием.(это для вашей фразы «Если я исправлю ошибку в BPL, каждый программист ...»).
  3. Вариант с автономными исполняемыми файлами выглядит лучше, потому что значительно упрощает организацию среды тестирования и развертывание проекта.Просто выберите подходящие соглашения для управления версиями.
...