BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Problems in class helper Goto page 1, 2  Next          BorlandTalk.com Forum Index -> Delphi OO design View previous topic :: View next topic   Author Message Definey Guest Posted: Sun Apr 22, 2007 3:04 pm    Post subject: Problems in class helper Hi, everyone. I think the class helper is a very useful utility to expand classes without touching source code. But I wonder how to reuse the existing code. For instance, say you have this class: Type TClassA=class public procedure Test; end; Now you have made a class helper for TClassA: Type TClassAHelper=class helper for TClassA public procedure Test; end; procedure TClassAHelper.Test; begin //do the old TClassA.Test //do some new things end; Here, You may want to do more things in your Test method. You may call the old TClassA.Test first, and then add some additional code. How do I call the origin method in class helper? Thanks in advance. Back to top Joanna Carter [TeamB] Guest Posted: Sun Apr 22, 2007 5:58 pm    Post subject: Re: Problems in class helper Definey a écrit : Quote: Hi, everyone. I think the class helper is a very useful utility to expand classes without touching source code. But I wonder how to reuse the existing code. For instance, say you have this class: Class helpers are meant to be adapters, providing missing methods to satisfy the interface of another class; any methods on the "helped" class do not need a helper, methods in the helper class are meant to be in addition to existing methods on the helped class, not as extenders of existing methods. What you are trying to do here is to use a helper class to change the functionality of an existing class, not adapt it to fit another class interface. I suggest you look at inheriting from the existing class instead. Joanna -- Joanna Carter [TeamB] Consultant Software Engineer Back to top Marc Rohloff [TeamB] Guest Posted: Sun Apr 22, 2007 6:04 pm    Post subject: Re: Problems in class helper On Sun, 22 Apr 2007 18:04:49 +0800, Definey wrote: Quote: How do I call the origin method in class helper? Try: inherited Test; just like when you are subclassing. -- Marc Rohloff [TeamB] marc -at- marc rohloff -dot- com Back to top Definey Guest Posted: Mon Apr 23, 2007 5:41 pm    Post subject: Re: Problems in class helper Marc Rohloff [TeamB] wrote: Quote: On Sun, 22 Apr 2007 18:04:49 +0800, Definey wrote: How do I call the origin method in class helper? Try: inherited Test; just like when you are subclassing. Thanks Marc, it really works. That's exactly what I mean. Actually, I take the class helper as an AOP approach. I've discussed it with some of my friends, we think this compiler trick serves as some sort of cross-cutting solution for delphi. As far as I can tell, there is no practical third-party AOP solution for delphi right now, but the class helper is most possible way. IMO, if a class helper can help more than one classes via some wild card mechanism, it will be much like an AOP stuff. Do you think so? Back to top Wayne Niddery [TeamB] Guest Posted: Mon Apr 23, 2007 7:53 pm    Post subject: Re: Problems in class helper Definey wrote: Quote: Thanks Marc, it really works. That's exactly what I mean. Actually, I take the class helper as an AOP approach. I've discussed it with some of my friends, we think this compiler trick serves as some sort of cross-cutting solution for delphi. As far as I can tell, there is no practical third-party AOP solution for delphi right now, but the class helper is most possible way. IMO, if a class helper can help more than one classes via some wild card mechanism, it will be much like an AOP stuff. Do you think so? Class helpers were developed by the Delphi team in order to allow them to map the VCL into the .Net framework - so when you look at the .Net System.Object type in Delphi, you see all the familiar properties and methods even though they are not, in fact, present in the .Net System.Object. There is a very strong caveat in using class helpers in application code (it is recommended that you don't). While there are some parallels to AOP, it is not intended to be that. There are very important implications that can bite you very easily: - class helpers apply to all descendants of the class you help. So defining a helper for, say, TStrings, will affect TStringList and the TStrings descendants used for ComboBoxes, ListBoxes, Memos, StringGrids, and many other components. - more than a single class helper can be defined for the same class - or at any point in a class heirarchy, and code scope will determine which one has precedence - if any. This can be a *great* source of difficult to diagnose bugs. Finally, for the example you provided, class helpers are *completely* the wrong tool to to use, what you needed was simple inheritance. As for actual AOP, while obviously very powerful and thus tempting, in my opinion it is an accident waiting to happen - it is the perfect weapon to turn well-designed OO models and applications into complete spaghetti. -- Wayne Niddery - Winwright, Inc (www.winwright.ca) "A man is likely to mind his own business when it is worth minding, when it is not, he takes his mind off his own meaningless affairs by minding other people's business." - Eric Hoffer Back to top Joanna Carter [TeamB] Guest Posted: Mon Apr 23, 2007 8:48 pm    Post subject: Re: Problems in class helper Wayne Niddery [TeamB] a écrit : Quote: Class helpers were developed by the Delphi team in order to allow them to map the VCL into the .Net framework - so when you look at the .Net System.Object type in Delphi, you see all the familiar properties and methods even though they are not, in fact, present in the .Net System.Object. There is a very strong caveat in using class helpers in application code (it is recommended that you don't). While there are some parallels to AOP, it is not intended to be that. There are very important implications that can bite you very easily: - class helpers apply to all descendants of the class you help. So defining a helper for, say, TStrings, will affect TStringList and the TStrings descendants used for ComboBoxes, ListBoxes, Memos, StringGrids, and many other components. - more than a single class helper can be defined for the same class - or at any point in a class heirarchy, and code scope will determine which one has precedence - if any. This can be a *great* source of difficult to diagnose bugs. Finally, for the example you provided, class helpers are *completely* the wrong tool to to use, what you needed was simple inheritance. As for actual AOP, while obviously very powerful and thus tempting, in my opinion it is an accident waiting to happen - it is the perfect weapon to turn well-designed OO models and applications into complete spaghetti. Definey, I would really recommend that you take note of what Wayne and I have written. Even though you can do this, you really don't want to, for your sake and that of those who will follow you. Joanna -- Joanna Carter [TeamB] Consultant Software Engineer Back to top Joanna Carter [TeamB] Guest Posted: Tue Apr 24, 2007 7:42 pm    Post subject: Re: Problems in class helper Definey a écrit : Quote: Actually, when I'm discussing some OO design with some Java developers, they often question the possibility of applying full OO methodology in delphi(but it's true that most delphi projects are organized with event handlers). I think delphi still has a long way to go to keep up with modern languages and methodologies. Delphi is a very good OO language, it is usually the programmers that restrict its abilities :-) There is nothing wrong with event handlers, provided your business logic isn't restricted to them. I once met a team where they used event handlers assigned to the OnClick event of hidden buttons, just because they didn't know that you could write your own procedures in a unit !!! IMO, the only things that Delphi lacks is the likes of reflection (better than RTTI), non-COM interfaces and generics. In theory, Delphi for .NET 2.0+ should give us most of these things; at least it has in C#. Joanna -- Joanna Carter [TeamB] Consultant Software Engineer Back to top Definey Guest Posted: Tue Apr 24, 2007 8:01 pm    Post subject: Re: Problems in class helper Joanna Carter [TeamB] wrote: Quote: Wayne Niddery [TeamB] a écrit : Class helpers were developed by the Delphi team in order to allow them to map the VCL into the .Net framework - so when you look at the .Net System.Object type in Delphi, you see all the familiar properties and methods even though they are not, in fact, present in the .Net System.Object. There is a very strong caveat in using class helpers in application code (it is recommended that you don't). While there are some parallels to AOP, it is not intended to be that. There are very important implications that can bite you very easily: - class helpers apply to all descendants of the class you help. So defining a helper for, say, TStrings, will affect TStringList and the TStrings descendants used for ComboBoxes, ListBoxes, Memos, StringGrids, and many other components. - more than a single class helper can be defined for the same class - or at any point in a class heirarchy, and code scope will determine which one has precedence - if any. This can be a *great* source of difficult to diagnose bugs. Finally, for the example you provided, class helpers are *completely* the wrong tool to to use, what you needed was simple inheritance. As for actual AOP, while obviously very powerful and thus tempting, in my opinion it is an accident waiting to happen - it is the perfect weapon to turn well-designed OO models and applications into complete spaghetti. Definey, I would really recommend that you take note of what Wayne and I have written. Even though you can do this, you really don't want to, for your sake and that of those who will follow you. Joanna You're right. Actually I and my team are just discussing some possible solutions to cross-cutting concerns. The example that I have shown is not for extension purpose, it is a cross-cutting concern. I mean you may apply the before, after and around point-cuts, for logging, security check, etc. Traditionally, I think the dynamic proxy is a more realistic approach, just as what EJB has shown us. I wonder if there's someone has tried this in delphi before? Actually, when I'm discussing some OO design with some Java developers, they often question the possibility of applying full OO methodology in delphi(but it's true that most delphi projects are organized with event handlers). I think delphi still has a long way to go to keep up with modern languages and methodologies. Back to top Wayne Niddery [TeamB] Guest Posted: Tue Apr 24, 2007 8:30 pm    Post subject: Re: Problems in class helper Definey wrote: Quote: Actually, when I'm discussing some OO design with some Java developers, they often question the possibility of applying full OO methodology in delphi What do you or they perceive as missing from Delphi with regard to "full OO"?? Quote: I think delphi still has a long way to go to keep up with modern languages and methodologies. As above - what's missing from an OO point of view? -- Wayne Niddery - Winwright, Inc (www.winwright.ca) "At the apex of every great tragedy of mankind there stands the figure of an incorruptible altruist." - Ayn Rand Back to top Andreas Dorn Guest Posted: Wed Apr 25, 2007 2:38 am    Post subject: Re: Problems in class helper Joanna Carter [TeamB] wrote: Quote: Definey a écrit : I think delphi still has a long way to go to keep up with modern languages and methodologies. Delphi is a very good OO language, it is usually the programmers that restrict its abilities :-) IMO, the only things that Delphi lacks is the likes of reflection (better than RTTI), non-COM interfaces and generics. In theory, Delphi for .NET 2.0+ should give us most of these things; at least it has in C#. While non-COM interfaces and generics would be nice to have I'd also mention - Namespaces - Lambda expressions - Better Interface inheritance Because of the lack of generics I make heavy use of code-generation and that proved to be more powerful than anything I could have achieved with generics, so generics went a bit down in my wish-list. For interfaces there are at least some usable workarounds around that ref-counting. Recently the lack of multiple interface inheritance disturbed me a bit more. All that said, while there are a lot of things that could be done to improve the language, I'd rather have better GUI-components available which provide more usable interfaces to the OO-world. At the moment I sometimes still have to hack my way down to the windows-events to get what I want. -- Andreas Back to top Joanna Carter [TeamB] Guest Posted: Wed Apr 25, 2007 8:13 am    Post subject: Re: Problems in class helper Andreas Dorn a écrit : Quote: Joanna Carter [TeamB] wrote: While non-COM interfaces and generics would be nice to have I'd also mention - Namespaces - Lambda expressions - Better Interface inheritance I would also agree that these things are useful but, with regard to the assertion that Delphi is not a proper OO language, they would not prevent Delphi from being the reasonably good OO language it already is. Quote: Because of the lack of generics I make heavy use of code-generation and that proved to be more powerful than anything I could have achieved with generics, so generics went a bit down in my wish-list. You wait until you get generics *and* lightweight code generation :-) Seriously, writing code that generates code, for generic types, is *very* useful, especially for avoiding calls to Activator.CreateInstance. Quote: For interfaces there are at least some usable workarounds around that ref-counting. Recently the lack of multiple interface inheritance disturbed me a bit more. Having struggled long and hard to get large frameworks up and running with Delphi interfaces, I find it such a relief to use .NET where interfaces just "are". Quote: All that said, while there are a lot of things that could be done to improve the language, I'd rather have better GUI-components available which provide more usable interfaces to the OO-world. At the moment I sometimes still have to hack my way down to the windows-events to get what I want. This is the main reason why we wrote our own MVP (Model View Presenter) framework, using Adapter classes and Interactors to connect to UI controls. We never got around to writing designers though, so everything had to be hooked up in code. Once again, .NET is *soooo* much simpler and better in this regard. Joanna -- Joanna Carter [TeamB] Consultant Software Engineer Back to top Peter Morris Guest Posted: Wed Apr 25, 2007 2:06 pm    Post subject: Re: Problems in class helper Quote: I once met a team where they used event handlers assigned to the OnClick event of hidden buttons, just because they didn't know that you could write your own procedures in a unit !!! FIRED! My boss thinks he's a bit of a programmer. He drops a hidden TMemo onto forms just to use its Lines property. Some people :-) Pete Back to top Definey Guest Posted: Wed Apr 25, 2007 6:10 pm    Post subject: Re: Problems in class helper Wayne Niddery [TeamB] wrote: Quote: Definey wrote: Actually, when I'm discussing some OO design with some Java developers, they often question the possibility of applying full OO methodology in delphi What do you or they perceive as missing from Delphi with regard to "full OO"?? I think delphi still has a long way to go to keep up with modern languages and methodologies. As above - what's missing from an OO point of view? For correction, in tradition, delphi is a a good OO language, but it's a bit of out of date right now, comparing with java, c#, etc. So, I'd rather say delphi is not so modern. Back to top Definey Guest Posted: Wed Apr 25, 2007 6:41 pm    Post subject: Re: Problems in class helper Joanna Carter [TeamB] wrote: Quote: Wayne Niddery [TeamB] a écrit : Class helpers were developed by the Delphi team in order to allow them to map the VCL into the .Net framework - so when you look at the .Net System.Object type in Delphi, you see all the familiar properties and methods even though they are not, in fact, present in the .Net System.Object. There is a very strong caveat in using class helpers in application code (it is recommended that you don't). While there are some parallels to AOP, it is not intended to be that. There are very important implications that can bite you very easily: - class helpers apply to all descendants of the class you help. So defining a helper for, say, TStrings, will affect TStringList and the TStrings descendants used for ComboBoxes, ListBoxes, Memos, StringGrids, and many other components. - more than a single class helper can be defined for the same class - or at any point in a class heirarchy, and code scope will determine which one has precedence - if any. This can be a *great* source of difficult to diagnose bugs. Finally, for the example you provided, class helpers are *completely* the wrong tool to to use, what you needed was simple inheritance. As for actual AOP, while obviously very powerful and thus tempting, in my opinion it is an accident waiting to happen - it is the perfect weapon to turn well-designed OO models and applications into complete spaghetti. Definey, I would really recommend that you take note of what Wayne and I have written. Even though you can do this, you really don't want to, for your sake and that of those who will follow you. Joanna I have a little case which uses the class helper feature, but I'm not gonna call it a good case. It's as following: I'm using InstantObjects as my persistent framework. All persistent classes are derived from TInstantObject, if you've used it, you will know this. The problem is what if you wanna your classes implements some interfaces. I've gone through the source code of instantobjects, and found the TInstantObject class does implement some basic methods of IInterface. type TInstantObject=class(TPesistent) //...... protected procedure QueryInterface(GUID,out obj); procedure _AddRef; procedure _Release; //...... end; I don't know they have these methods protected, but it really makes trouble in using interface. If you have this class: Type ITest=interface procedure DoSomething; end; TClassA=class(TInstantObject, ITest) //....... procedure DoSomething; end; When you write this code: var test:ITest; objs:TObjectList; begin objs:=TObjectList.Create; objs.Add(TClassA.Create); test:=ITest(objs.Items[0]); //the compiler will reject this line test.DoSomething; end; Because the three interface method is protected, I suppose the system can not call QueryInterface method, so you cannot use the type cast. Well, we've come to this. First, InstantObjects is a third party framework, I'm not gonna change it. Second, I don't all of my persistent classes are derived from another base class just for make these methods public, that's weird. And, that's where class helper comes to use. I make a TInstantObjectHelper to make the three methods for TInstantObject public. But still, I don't think it's an elegant way. Actually, I've not extended the class, just changed its visibility. I don't know if someone has experienced the same scenario, but the approach is really strange. Back to top Peter Morris Guest Posted: Wed Apr 25, 2007 8:06 pm    Post subject: Re: Problems in class helper Quote: For correction, in tradition, delphi is a a good OO language, but it's a bit of out of date right now, comparing with java, c#, etc. So, I'd rather say delphi is not so modern. But that's an opinion, not an example. Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> Delphi OO design All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.