BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Re: Interface Hierarchies Resembling Class Hierarchies -- Is Goto page 1, 2  Next          BorlandTalk.com Forum Index -> Delphi OO design View previous topic :: View next topic   Author Message Joanna Carter (TeamB) Guest Posted: Wed Nov 12, 2003 9:39 am    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is Sean Dockery wrote: Quote: ...but Rob does not go on to explain it is such a bad thing. I have used interface hierarchies that resemble class hierarchies to leverage the benefit of automatic reference counting in my own projects over the past several years. I simply don't get the point that Rob is attempting to subtly convey (while basically inferring that I'm stupid if I don't get it). Can someone explain it to me? Type real slow so I can understand, okay? FMPOV, Interface hierarchies should not be designed out of class hierarchies, because classes know too much about 'how' things are done, whereas interfaces should only know 'what' is being done. Interfaces are essentially behaviour descriptors or contracts. It should be possible to design whole systems using nothing but interfaces. This then allows you to hand out these interfaces to different people to develop implementing classes and not worry about how they are implemented. Extracting interfaces from classes is a poor cousin to designing interfaces and then implementing them. This is mainly due to the fact that a correctly designed interface hierarchy will end up with some classes implementing more than one interface, some classes delegating responsibility for a particular interface to an aggregated class, some interfaces never being implemented without being derived from, etc... Automatic reference counting is not my main reason for using interfaces; I use them because it promotes better design and encapsulation. Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top Bob Dawson Guest Posted: Wed Nov 12, 2003 12:54 pm    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is "Sean Dockery" wrote Quote: ...but Rob does not go on to explain it is such a bad thing. His explanation is 2nd paragraph following: "(So where did we get to with the question above? The problem with duplicating the class hierarchy is that the interface code is no more reusable than the class code was. Interfaces should be small bits of functionality, for a pick and mix approach to coding. Better to have interfaces ILettuce, ITomato, IChips, ILasagne, IFish and IWine, than IMondaysLunch, ITuesdaysLunch, etc. That way, I can have lasagne and salad, fish and chips, or lasagne and chips, with or without wine, without needing any new interfaces. If my interface was the whole meal, then I can only reuse it for precisely the same meal.)" and in the way that his TaoBigParent class does not become an IaoBigParent interface, but rather a supporter of six distinct 'aspect' interfaces. I don't find the argument all that convincing, however, in that to whatever extent IMondaysLunch is a bad idea as an interface, it's also a bad idea as a class. And in any real application, we'd start seeing the IaoParent interface growing to become a reflection of the TaoBigParent class; if it didn't (or didn't need to), then I'd have to question the cohesion of the class design. Perhaps you should forward your question to Rob (his email is at the end of the article). He might be willing to respond in more detail here. bobD Back to top Bryan Crotaz Guest Posted: Thu Nov 13, 2003 1:30 am    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is I use a combination of a class-heirachy style and a usage style in my interfaces. So I have IElement, ITextElement, IVideoElement etc, but I also have ISubject, IObserver, IStreamable etc. I use interfaces for 3 reasons: Ref-counted and garbage disposal Accessing objects across DLL plugins Multithreaded access to objects without worrying that another thread has freed the object Works fine for me! Bryan Back to top Christian Kaufmann Guest Posted: Thu Nov 13, 2003 8:17 am    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is Hi Joanna, Quote: FMPOV, Interface hierarchies should not be designed out of class hierarchies, because classes know too much about 'how' things are done, whereas interfaces should only know 'what' is being done. I think, I understand that. But do you think, interface inheritance should be avoided too? I'm waiting for multiple inheritance and then I plan something like this for DB access: IColumns = interface property AsInteger[AColumnName: String]: Integer; .... end; IParams = interface property ParamAsInteger[AColumnName: String]: Integer; .... end; // a general sql command with parameters ISqlCommand = interface(IParams) property Sql: String; end; // a select sql command ISqlQuery = interface(ISqlCommand, IColumns) procedure First; procedure Next; function HasData end; // an insert/update/delete sql command ISqlExecute = interface(ISqlCommand) function Execute: Integer; end; Now do you think, this hierarchy is to close to an implementation? If I think, some hierarchy is necessary, because otherwise I have to typecast all the time. Or should I do it this way: var qry : ISqlCommand; cols : IColumns; begin qry := .... cols := qry as IColumns; qry.First; while qry.HasData x := cols.AsInteger['xxx']; qry.Next; end; cu Christian Quote: Interfaces are essentially behaviour descriptors or contracts. It should be possible to design whole systems using nothing but interfaces. This then allows you to hand out these interfaces to different people to develop implementing classes and not worry about how they are implemented. Extracting interfaces from classes is a poor cousin to designing interfaces and then implementing them. This is mainly due to the fact that a correctly designed interface hierarchy will end up with some classes implementing more than one interface, some classes delegating responsibility for a particular interface to an aggregated class, some interfaces never being implemented without being derived from, etc... Automatic reference counting is not my main reason for using interfaces; I use them because it promotes better design and encapsulation. Joanna Back to top Joanna Carter (TeamB) Guest Posted: Thu Nov 13, 2003 9:22 am    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is Christian Kaufmann wrote: Quote: I think, I understand that. But do you think, interface inheritance should be avoided too? I'm waiting for multiple inheritance and then I plan something like this for DB access: Multiple inheritance of interfaces can be just as dangerous as MI of classes. In using inheritance, you must always remember that it implies an 'is a' relationship. So far, I have never found a use for MI of interfaces, I tend to implement multiple interfaces in a class, which is subtly different from inheritance. SO I would have TSqlQuery = class(TInterfacedObject, IParams, ISqlCommand, IColumns) private procedure First; procedure Next; function HasData // IParams property ParamAsInteger[AColumnName: String]: Integer; // ISqlCommand property Sql: String; // IColumns property AsInteger[AColumnName: String]: Integer; end; ISqlExecute = interface function Execute: Integer; end; // an insert/update/delete sql command TSqlExecute = class(TSqlCommand, ISqlExecute) private function Execute: Integer; end; This kind of arrangement is known as 'mix in' where you can implement some of the base behaviour(s) in one class and then add in 'enhancing' behaviours in derived classes. You can also use the 'implements' directive in a class to delegate responsibility to an aggregated object that implements common behaviour. Without insulting your design, I feel that what you are doing is trying to find to justify MI of interfaces rather than having thought through the design carefully. Your analysis says: An ISqlCommand 'is' an enhanced IParams. FMPOV a Command may 'contain' Params, but that is no inheritance, that is aggregation or composition. An ISqlQuery 'is' an enhanced ISQLCommand (which implies that it is also an enhanced IParams) and it also 'is' an enhanced IColumns. Likewise a Query may be made up from a Command which may contain Params, and it may contain Columns, but this is not inhertance either; it also is either nested aggregation or composition. I think you are making the same mistake that I made when I first tried OOAD; using inheritance for everything and forgetting aggregation and composition :-) Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top Jim Cooper Guest Posted: Thu Nov 13, 2003 1:39 pm    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is Quote: it was for automatic object lifecycle management enabled through them. That's a side-effect of the Delphi implementation of interfaces. It has both positives and negatives (it's why mixing object and interface references is fraught with danger, for instance). In the .NET world, if I have it straight, it will no longer be an issue, and then interfaces can be considered from a pure language feature POV. I'm not sure what the issues will be with plug-in architecture. I **think** that difference will also disappear, but I'm not familiar enough with .NET assemblies to be sure. There are times interfaces are inappropriate, and times when they are a good idea. I don't believe that there are problems that can only be solved using just interfaces or just pure class inheritance, but there are definitely times when one is cleaner than the other. Eg the Template Method pattern is more natural for class inheritance, whereas Observer (and therefore MVC,MVP) normally benefit from heavy use of interfaces. But you can do both either way. Often (even most??) times, there is little advantage going one way or the other and it comes down to personal preference. This is particularly the case where the design consists of small, shallow hierarchies, which are loosely-coupled to each other. I also don't believe that interfaces automatically make reuse easier, BTW It depends on other things. Cheers, Jim Cooper ____________________________________________ Jim Cooper [email]jcooper (AT) tabdee (DOT) ltd.uk[/email] Tabdee Ltd http://www.tabdee.ltd.uk TurboSync - Connecting Delphi with your Palm ____________________________________________ Back to top Iman L Crawford Guest Posted: Thu Nov 13, 2003 2:34 pm    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is Christian Kaufmann <christian.kaufmann (AT) gmx (DOT) net> wrote in news:K52zP4ubN=JT0va5Ubbv6wTNhfjm (AT) 4ax (DOT) com: Quote: Never looked at that before, but this looks really usefull. I'll probably delete many lines of code with this language construct. Be mindful that borland has said it may not be supported on the .NET platform. -- Iman Back to top Christian Kaufmann Guest Posted: Thu Nov 13, 2003 3:21 pm    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is Quote: You can also use the 'implements' directive in a class to delegate responsibility to an aggregated object that implements common behaviour. Never looked at that before, but this looks really usefull. I'll probably delete many lines of code with this language construct. Quote: I think you are making the same mistake that I made when I first tried OOAD; using inheritance for everything and forgetting aggregation and composition I'm aware of this problem and you are right about the confusion I made with "is a" and "has a" relation. Params probably should be a property and the type is something like IWriteableColumns. And an ISqlQuery has a Columns property: // a general sql command with parameters ISqlCommand = interface property Sql: String; property Params: IWriteableColumns; end; // a select sql command ISqlQuery = interface(ISqlCommand) procedure First; procedure Next; function HasData; property Columns: IColumns; end; // an insert/update/delete sql command ISqlExecute = interface(ISqlCommand) function Execute: Integer; end; using this means: qry.First; while qry.HasData do begin x := qry.Columns.AsInteger['xxxx']; y := qry.Columns.AsString['zzz']; z := qry.Columns.AsDateTime['yyy']; qry.Next; end; // while Did I understand you correctly with this? It's just more typing with the additional ".Columns." but I could still do the following: TSqlQuery = class(TInterfacedObject, ISqlQuery, IColumns) private FColumns: IColumns; public property Columns: read FColumns implements IColumns; end; But if I have a ISqlQuery I still need a typecast: x := (qry as IBSColumns).AsInteger['xxxx']; and with multiple inheritance in interfaces this wouldn't be necessary. cu Christian Back to top Joanna Carter (TeamB) Guest Posted: Thu Nov 13, 2003 5:33 pm    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is Iman L Crawford wrote: Quote: Be mindful that borland has said it may not be supported on the .NET platform. If it isn't then you just have to write wrapper methods to forward the interface requests to the delegate. Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top Joanna Carter (TeamB) Guest Posted: Thu Nov 13, 2003 5:35 pm    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is Christian Kaufmann wrote: Quote: Did I understand you correctly with this? It's just more typing with the additional ".Columns." but I could still do the following: and with multiple inheritance in interfaces this wouldn't be necessary. There is still a bad smell about what you are trying to do. So far I see no reason for even single inheritance given the interfaces involved. If you disagree, then you have to justify your case like any good OO designer ;-) Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top Christian Kaufmann Guest Posted: Fri Nov 14, 2003 1:11 pm    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is Quote: There is still a bad smell about what you are trying to do. So far I see no reason for even single inheritance given the interfaces involved. If you disagree, then you have to justify your case like any good OO designer If you are a purist, then you are right. But I think, one of the most important skill for software developper is to find the correct tradeoffs. That's why we do this in our design: For example we have Columns, Iterators and SqlQueries. I agree, that an Iterator is not a "Columns", but in real life, the Iterator without Columns doesn't make sence for us. So here comes the tradeof that we inherit the Iterator interface from the Columns interface to save some typing: IColums = interface property AsInteger[] ... end; IIterator = interface(IColumns) procedure First; procedure Next ... end; ISqlQuery = interface(IIterator) property Sql: String; end; But I agree. If you are a purist, both inheritance could be removed and it would look like this: ISqlQuery = interface property Sql: String; property Iterator : IIterator; property Columns: IColumns; end; cu Christian Back to top Andrea Raimondi Guest Posted: Fri Nov 14, 2003 1:28 pm    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is Christian Kaufmann wrote: <snip> The problem here, imho, is not being purist or not: the point is mantainability. You can't know from now on if and when you're going to change your classes for what reason, thus keeping things well defined and separated will help upon mantainance time. All this, obviously, IMHO. Cheers, Andrew Back to top John Elrick Guest Posted: Fri Nov 14, 2003 2:26 pm    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is "Joanna Carter (TeamB)" <joannac (AT) btinternetXX (DOT) com> wrote Quote: Christian Kaufmann wrote: | I think, I understand that. But do you think, interface inheritance | should be avoided too? I'm waiting for multiple inheritance and then I | plan something like this for DB access: Multiple inheritance of interfaces can be just as dangerous as MI of classes. SNIP Quote: TSqlQuery = class(TInterfacedObject, IParams, ISqlCommand, IColumns) SNIP Quote: An ISqlCommand 'is' an enhanced IParams. FMPOV a Command may 'contain' Params, but that is no inheritance, that is aggregation or composition. However, doesn't a class implementing multiple interfaces actually introduce the concept of "can be a"? Using the above: localSqlQuery : ISqlCommand; localSqlQuery := SomeFactory.makeNew; Then the way to get to get to IColumns is to treat localSqlQuery as "can be a": if Supports(localSQLQuery, IColumns, localColumns) then .... Contains or "has a"...wouldn't that be more like this: ISqlCommand = interface ... function Columns: IColumns; end; ?? I see this more as a limitation of Delphi...in Java or C#, we could utilize the _real_ class and simply use it's interfaces as appropriate. However, in general, I wonder if casting under OO is it's own concept. John Back to top Joanna Carter (TeamB) Guest Posted: Fri Nov 14, 2003 8:50 pm    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is John Elrick wrote: Quote: However, doesn't a class implementing multiple interfaces actually introduce the concept of "can be a"? this is more a case of 'exhibits this behaviour'. A class does not relate to an interface as an 'is a' relationship, more a 'does' relationship; don't forget an interface does not contain any state. Quote: I see this more as a limitation of Delphi...in Java or C#, we could utilize the _real_ class and simply use it's interfaces as appropriate. However, in general, I wonder if casting under OO is it's own concept. There is no reason why you can't use the 'real' class or interface in Delphi. This discussion is more about OO conceepts than language. Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top John Elrick Guest Posted: Sat Nov 15, 2003 4:09 pm    Post subject: Re: Interface Hierarchies Resembling Class Hierarchies -- Is "Joanna Carter (TeamB)" <joannac (AT) btinternetXX (DOT) com> wrote Quote: John Elrick wrote: | However, doesn't a class implementing multiple interfaces actually | introduce the concept of "can be a"? this is more a case of 'exhibits this behaviour'. A class does not relate to an interface as an 'is a' relationship, more a 'does' relationship; don't forget an interface does not contain any state. TRectangle = class(..., IShape, IPersitable) procedure draw; end; localThing : IPersistable; localThing := CShapeFactory.load(sFileName); localCanvas.handle(aThing as IShape); Here is a (very contrived) example of how a Persistable "can be a" Shape. There is no enforcement or guarantee that it will be one, but it can be. Quote: | I see this more as a limitation of Delphi...in Java or C#, we could | utilize the _real_ class and simply use it's interfaces as | appropriate. However, in general, I wonder if casting under OO is | it's own concept. There is no reason why you can't use the 'real' class or interface in Delphi. Well...reference counting problems<g> Quote: This discussion is more about OO conceepts than language. Perhaps...from what I have seen, duplicating entire class hierachies is more a Delphi problem. When you examine Java interfaces, they tend to be very atomic and tiny...it tends to be the Delphi ones that get massive. And, I believe that stems from the inability to easily and safely use a class and an interface at the same time. FWIW John 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.