Каков наилучший способ использовать повторно используемый код? - PullRequest
6 голосов
/ 11 июня 2011

Чаще всего, скорее всего, вы не столкнетесь с ситуацией, когда вам может понадобиться функция или процедура, скорее всего, вы уже написали этот код раньше.

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

Я думал о том, чтобы объединить все свои процедуры и функции в один модуль и добавить этот модуль в предложение Uses необходимых форм.и т. д.

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

Чем я являюсь в принципеВопрос в том, что является лучшим методом для повышения производительности и удобства, для управления, обслуживания и использования повторно используемого кода?

ОБНОВЛЕНИЕ

После некоторых информативных постов я решилпродолжить и использовать один единственный источник, который содержит все мои подпрограммы многократного использования.Я включил использование редактора кода Delphi Code Folding для создания пользовательских областей, для разделения различных типов на группы, а также области.Все регионы будут свернуты, а также будут иметь значимые названия регионов.Я добавил единичный исходный модуль в путь к библиотеке, который я могу добавить к любому условию использования форм и получить доступ ко всем подпрограммам многократного использования.Посмотрите на скриншот для лучшей идеи:

Screenshot

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

Спасибо.

Ответы [ 4 ]

10 голосов
/ 11 июня 2011

Вместо одной единицы используйте папку с несколькими единицами.

Организуйте единицы в соответствии с предметом и старайтесь поддерживать высокую когезию и низкую связь.Другими словами: модули должны содержать функции и процедуры, которые тесно связаны, и использовать как можно меньше других ваших модулей (конечно, можно свободно использовать vcl / rtl).

Если вам нужно вдохновение, какогоединиц, которые вы могли бы иметь: я бы взял лист из VCL и RTL.То, как организованы юниты и какие вещи складываются вместе с тем, что получает отдельный юнит, может дать вам довольно четкое понимание того, как организовать свои собственные вещи.

6 голосов
/ 11 июня 2011

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

Распространение подпрограмм многократного использования в одном или нескольких отдельных модулях является обычной практикой.В какой степени вы нормализуете, это зависит от ваших собственных процедур или навязанных правил (например, от вашей компании).

Лично мне нравится называть единицы, как Delphi: AwControls, AwUtils, AwDB, AwForms, AwMenus дляподпрограммы и классы, которые расширяют VCL по умолчанию или содержат новые или производные компоненты.Но я также создаю отдельные модули для довольно больших компонентов или для необычных подпрограмм или классов, таких как AwPlanGrid, AwDxf, AwIpTypes.Просто предложение.

Еще один совет: добавьте папку, содержащую эти единицы, в путь поиска проекта по умолчанию (для настройки параметров проекта, когда проект не загружен в IDE).

1 голос
/ 12 июня 2011

Сегодня я попытался добавить модуль в мой код, и он использовал другой модуль.Это подразделение использовало еще три.И три из них, которые он использовал, использовали в общей сложности 27 других юнитов.

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

Если вы думаете, что это экстремально, просто попробуйте использовать НЕКОТОРЫЕ из JEDI JCL или JVCL, не используя намного больше.

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

Я думаю, что для моего следующего проекта вместо монолитного dUnit длямодульные тесты, что все тесты для одного многократно используемого фрагмента кода должны быть встроены в свои собственные исполняемые файлы для каждого класса, который они тестируют, и сконфигурированы так, чтобы явно включать нужные им модули, без каких-либо папок поиска / папок библиотеки, которые могутмодули просто молча будут добавлены в код.Тогда я каждый раз, когда кто-то разбирается, разбивает юнит-тесты, и мы узнаем, что случилось что-то плохое.

В любом случае, как мне кажется, это один из способов гарантировать, что ваш код избегает связывания, и что вы можете написать небольшое или новое приложение и вставить в свой код только кусочки (компоненты, если хотите)что вам нужно, без гигантского череда «ада USE-Clause-зависимости».

То же самое, что и заявление Марьяна о том, что «Единый юнит» - это не тот путь, по которому нужно идти;Зависимости в огромном сервисном подразделении станут бесполезными.Чтобы построить любой проект, который использует этот модуль Utility, вам нужно будет иметь доступ ко всем модулям в его разделе интерфейса и реализации.

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

0 голосов
/ 12 июня 2011

Я поместил весь свой общий код в общую библиотеку (на самом деле в одной папке около 4 файлов PAS)Который действительно huuuge.Но только необходимый код будет добавлен в ваш exe, а не всю библиотеку.Компилятор Delphi достаточно умен, чтобы знать, какой код нужен.

...