Should Class Helpers be used in developing new code?

混江龙づ霸主 提交于 2019-12-03 12:06:14
Malcolm Groves

Depends what you mean by "new code".

They aren't really relevant for classes you are newly developing, so in that case, no, they probably shouldn't be used.

But even in a brand new project, you may still need to modify an existing class that you can't change in other ways (vcl class, third-party class, etc). In this case, sure, I'd say go ahead.

They're not evil in and of themselves. Like most other things, you just need to understand how they work and use them in an appropriate context.

Before embracing class helpers as a new tool for fancy code, I think you have to understand the limitations is includes. There is only possible to provide one class helper for one class. So what will happen if you provide class helpers for your classes, and your classes derives from a common class that some other have provided a class helper for?

CodeGear introduces class helpers as 'a hack' to prevent breaking things, not as a cool design feature. When you design code, design it without class helpers. I know you can. When dealing with existing code that you can control, use refactoring. When there is no other way, reach for class helpers.

Thats my opinion any way...

Lars Truijens

Microsoft based LINQ heavily around their Extension Methods. In that light you should use Class Helpers in new code if that improves your code. See What are good uses for class helpers? for some good uses.

I use them a lot. I use Remote Objects and the objects there are created by the RO engine so you cannot add to them without descending from them and then other bits of messing around. Class Helpers mean I can treat them like any other object. and while a class can only have one helper, you can descend helper classes so you get the inherited behaviour.

Sorry, can't help but be Captain Obvious for a moment: If the internal Delphi people themselves state "they should not be viewed as a design tool to be used when developing new code" then by definition they shouldn't be used. They are there for extending the VCL for their own purposes only. Who else is going to give you a better reason than the people that wrote it?

I agree with Vegar in this: class helpers as a emergency tool. When you know they are the only way to get things done in the time provided. Later, if there's time to it, remove them.

I one time forgot a parametrization thing, and if class helpers didn't exist in Delphi 2006 it would cost A ENORMOUS LOT OF TIME..... With class helpers, it took 6 hours to make thigs work right. BUT, it was an emergency situation - class helpers are an obscure language feature and it create difficulties to new developers to follow the flow of the program.

Maybe a good aproach you can use is (as I use it):

  1. Always give preference to inheritance over class helpers, use them only when inheritance is not an option.
  2. Give preference to Class helpers over bare global methods.
  3. If you're going to need the extendend functionality in more than a Unit, try something else (like class wrappers).

.Net Extensions methods are way too similar and where created and supported for the exactly same reason: Make an Extention of the base classes (rather than an upgrade wich in Delphi.Net was not an option in order to try to make Delphi native code kind of "compatible" with .Net code - IMHO this was too ambitious)

Anyway, Delphi Class helpers are still quite a tool in some situations.

These sound like C# extension methods. I would say that while extension methods like these are useful when you don't have the ability to modify a class that you need to extend with functionality, they are a poor way to design your own code. When designing your own code, you'd like all the functionality to be located in the same code file as much as possible rather than spread across different classes. I'd say use them for what they were intended for -- basically as decorators to add new functionality to closed classes -- and don't use them in designing your own code.

I find myself using them more and more as a design construct.

Situations in which I use them :

  • In a client/server setup, I extend shared base-classes with class helpers to provide server- or client-only functionality.
  • To complement VCL/RTL classes (and other third party code) with handy tooling functions.
  • To work around differences when classes don't share the same inheritance tree (using helpers makes it possible to have have generic Count and Items properties, for example).

In fact, I wish Delphi would accept multiple helpers for the same base class - I've even filed a request for this if I'm remembering correctly.

I found this article very interesting. It deals with C++ but the main ideas are language independent. The main gist is that global routines are sometimes preferrable to methods even in an OOP environment. From this view point, there's less need for class helpers.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!