Нужно ли использовать помощники классов при разработке нового кода?

Question

Delphi 8 представила помощники классов для целей сопоставления VCL / RTL с иерархией объектов .NET. Они позволяют внедрять методы в существующий класс, не переопределяя класс и не изменяя оригинал. Более поздние версии Delphi обнаружили улучшенные помощники классов, и они были портированы на Win32.

В справке говорится: «их не следует рассматривать как инструмент проектирования, который будет использоваться при разработке нового кода».

Помощники класса нарушают традиционные ООП, но я не думаю, что это делает их плохими. Это предупреждение оправдано?

Должны ли помощники класса использоваться при разработке нового кода?

Используете ли вы их при разработке нового кода?

Почему или почему нет?

За Комментарии Малкольма : Новый код означает ежедневную разработку приложений, где у вас есть некоторые сторонние библиотеки, некоторый существующий код, а затем код, который вы пишете.

Answer 1

Зависит от того, что вы подразумеваете под «новым кодом».

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

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

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

Answer 2

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

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

Это мое мнение в любом случае ...

Answer 3

LINQ на основе Microsoft тесно связан с их методами расширения. В этом свете вы должны использовать Class Helpers в новом коде, если это улучшает ваш код. См. Что такое хорошее использование для помощников класса? для некоторых хороших применений.

Answer 4

Я их часто использую. Я использую удаленные объекты, и объекты, созданные там, создаются механизмом RO, поэтому вы не можете добавить к ним, не спускаясь с них, а затем другие куски возни. Помощники класса означают, что я могу относиться к ним как к любому другому объекту. и хотя у класса может быть только один помощник, вы можете опускать вспомогательные классы, чтобы получить унаследованное поведение.

Answer 5

Возможно, вы можете использовать хороший подход (как я его использую):

1. Всегда отдавайте предпочтение наследованию , а не помощникам класса, используйте их только тогда, когда наследование недоступно.
2. Дайте предпочтение помощникам класса по сравнению с голыми глобальными методами .
3. Если вам понадобятся функциональные возможности расширения в более чем модуле, попробуйте что-нибудь еще (, например, обертки классов ).

.Net Extensions методы слишком похожи и где созданы и поддерживаются по одной и той же причине: Расширение базовых классов (а не обновление , которое в Delphi.Net не было опцией в чтобы попытаться сделать родной код Delphi как бы «совместимым» с кодом .Net - ИМХО это было слишком амбициозно)

Во всяком случае, Помощники Delphi Class по-прежнему довольно полезны в некоторых ситуациях.

Answer 6

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

Однажды я забыл о параметризации, и если бы помощники класса не существовали в Delphi 2006, это стоило бы ОГРОМНОЕ МНОГО ВРЕМЕНИ ..... С помощниками класса потребовалось 6 часов, чтобы заставить их работать правильно. НО, это была чрезвычайная ситуация - помощники класса являются неясной особенностью языка, и это создает трудности для новых разработчиков, чтобы следить за ходом программы.

Answer 7

Извините, не могу не быть капитаном Очевидность на мгновение: если внутренние Delphi-люди сами заявляют, что «их не следует рассматривать как инструмент проектирования, который будет использоваться при разработке нового кода», то по определению они не должны используемый. Они предназначены для расширения VCL только для их собственных целей. Кто еще даст вам лучшую причину, чем люди, которые это написали?

Answer 8

Мне показалось эта статья очень интересной. Он имеет дело с C ++, но основные идеи не зависят от языка. Основная суть в том, что глобальные подпрограммы иногда предпочтительнее методов даже в среде ООП. С этой точки зрения, меньше помощников в классе.

Answer 9

Я все больше и больше использую их в качестве конструктивной конструкции.

Ситуации, в которых я их использую:

• В настройке клиент / сервер я расширяю общие базовые классы с помощью помощников классов, чтобы обеспечить функциональность только для сервера или клиента.
• Для дополнения классов VCL / RTL (и другого стороннего кода) удобными инструментальными функциями.
• Чтобы обойти различия, когда классы не используют одно и то же дерево наследования (например, использование помощников позволяет иметь общие свойства Count и Items).

На самом деле, я бы хотел, чтобы Delphi принимал несколько помощников для одного базового класса - я даже подал запрос на это, если я правильно помню.

Answer 10

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