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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

. Методы расширений .NET слишком похожи и созданы и поддерживаются по одной и той же причине: Сделать расширение базовых классов (а не обновление, которое в Delphi.Net не было вариантом чтобы попытаться сделать собственный код Delphi "совместимым" с .Net кодом - IMHO, это было слишком амбициозным)

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

Ответ 8

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

Ответ 9

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

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

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

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

Ответ 10

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