BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  How to design this? Goto page 1, 2  Next          BorlandTalk.com Forum Index -> Delphi OO design View previous topic :: View next topic   Author Message Rael Guest Posted: Mon Mar 19, 2007 12:15 am    Post subject: How to design this? Hi, Imagine an object hierachy like: TAnimal | TDog, TDuck, TCat..... Now each descendant also have sub types TMale, TFemale, which may contain certain method that are mostly or entirely the same for the different classes (TDogMale, TCatMale). Any suggestions on how to go about designing this? I'm thinking along the lines of Creating classes TDogMale, TDogFemale, TDuckMale, etc...and then have some "Helper" claseses with class methods e.g. TMale.dothis... TMale.dothat..., TFemale...., which the above classes use. Or put in a different way, imagine three different states State1, State2, State3. Although each state is different, they all have the SAME three sub-states. So in total we have State1-a, State1-b, State1-c; State2-a, State2-b, etc.... So my question is how to best design a situation where you have a normal splitting hierarchy, but then lower down the hierarchy, different classes have similarities/the same code. Perhaps this is an obvious pattern? Thanks, Rael Back to top Peter Morris Guest Posted: Mon Mar 19, 2007 12:50 am    Post subject: Re: How to design this? Quote: Now each descendant also have sub types TMale, TFemale, which may contain certain method that are mostly or entirely the same for the different classes (TDogMale, TCatMale). Any suggestions on how to go about designing this? I'd say that Cat/Dog etc are types, but the Gender is a state, so I would have a property indicating the Gender. I would then implement the common behaviour and expose it as interfaces, any methods that do not apply given the current gender I would throw an InvalidOperationException from. It would then be the responsibility of the user of the instance to check the gender before doing anything gender specific; I shall not provide an example method name ;-) -- Pete Blessed are the geek, for they shall public class GeekEarth : Earth {} ==== Audio compression components, DIB graphics controls, ECO extensions, FastStrings : http://www.droopyeyes.com My blog : http://mrpmorris.blogspot.com Back to top Rolf Lampa [RIL] Guest Posted: Mon Mar 19, 2007 1:08 am    Post subject: Re: How to design this? Peter Morris wrote: Quote: Now each descendant also have sub types TMale, TFemale, which may contain certain method that are mostly or entirely the same for the different classes (TDogMale, TCatMale). Any suggestions on how to go about designing this? I'd say that Cat/Dog etc are types, but the Gender is a state, so I would have a property indicating the Gender. Hm, a state can change and then there should be support for some kind of trans... ah well, in context of software it's called state machine. Quote: ...> check the gender before doing anything gender specific; I shall not provide an example method name ;-) Question is if gender really is a "state" (being picky now). However, one could also think of using "configurable types" avoiding mess in the inheritance chain. A TypeInfo-link from TAnimal determining the gender would also do, like so: [TAnimal]-*----genderInfo--1-[TGender] | | [TMale] [TFemale] In terms of behavior this solution wouldn't be much different from regarding a State but I think that associating gender with "type" is closer to reality than "state". Regards, // Rolf Lampa Back to top Guillem Guest Posted: Mon Mar 19, 2007 3:41 pm    Post subject: Re: How to design this? Rael wrote: Quote: Hi, Imagine an object hierachy like: TAnimal | TDog, TDuck, TCat..... Now each descendant also have sub types TMale, TFemale, which may contain certain method that are mostly or entirely the same for the different classes (TDogMale, TCatMale). Any suggestions on how to go about designing this? I'm not sure to what extent you need this, but just in case you are creating a class for any possible animal you should consider 3 things: - some kinds of animals change gender during their life depending on ambiental, social or other circumstances. - some kinds of animals are hermafrodite, i.e., they have both genders. - some kinds of animals have no gender. So basically I agree with Peter. Gender should be a state and common behaviour could be exposed via interfaces. Just my 0.02 cents, -- Best regards :-) Guillem Vicens Meier Dep. Informatica Green Service S.A. www.clubgreenoasis.com -- Contribute to the Indy Docs project: http://docs.indyproject.org -- In order to contact me remove the -nospam Back to top Michael Baytalsky Guest Posted: Mon Mar 19, 2007 4:09 pm    Post subject: Re: How to design this? Use interfaces. IMale, IFemale. Any class can implement them, that's it. You can also provide IGender interface telling which one of the above two is implemented. Regards, Michael Rael wrote: Quote: Hi, Imagine an object hierachy like: TAnimal | TDog, TDuck, TCat..... Now each descendant also have sub types TMale, TFemale, which may contain certain method that are mostly or entirely the same for the different classes (TDogMale, TCatMale). Any suggestions on how to go about designing this? I'm thinking along the lines of Creating classes TDogMale, TDogFemale, TDuckMale, etc...and then have some "Helper" claseses with class methods e.g. TMale.dothis... TMale.dothat..., TFemale...., which the above classes use. Or put in a different way, imagine three different states State1, State2, State3. Although each state is different, they all have the SAME three sub-states. So in total we have State1-a, State1-b, State1-c; State2-a, State2-b, etc.... So my question is how to best design a situation where you have a normal splitting hierarchy, but then lower down the hierarchy, different classes have similarities/the same code. Perhaps this is an obvious pattern? Thanks, Rael Back to top Peter Morris Guest Posted: Mon Mar 19, 2007 8:07 pm    Post subject: Re: How to design this? Quote: Hm, a state can change and then there should be support for some kind of trans... Rolf, you should really try harder to keep your personal interests out of your posts :-) Quote: Question is if gender really is a "state" (being picky now). However, one could also think of using "configurable types" avoiding mess in the inheritance chain. A TypeInfo-link from TAnimal determining the gender would also do, like so: [TAnimal]-*----genderInfo--1-[TGender] | | [TMale] [TFemale] Yes, the gender of an animal is really a physical and functional attachment. I considered this option when replying but decided that it would be too much. Of course it is hard to decide how far to go unless we are provided with the real example! Pete Back to top Charles McAllister Guest Posted: Mon Mar 19, 2007 8:23 pm    Post subject: Re: How to design this? Rael wrote: Quote: So my question is how to best design a situation where you have a normal splitting hierarchy, but then lower down the hierarchy, different classes have similarities/the same code. Perhaps this is an obvious pattern? Strategy pattern? http://groups.google.com/group/borland.public.delphi.oodesign/browse_frm/thread/82154464d790b741/74fdf9fb7ccf8a7e#74fdf9fb7ccf8a7e http://en.wikipedia.org/wiki/Strategy_pattern Back to top Rael Guest Posted: Mon Mar 19, 2007 9:08 pm    Post subject: Re: How to design this? Quote: Question is if gender really is a "state" (being picky now). The intention of my question is where Gender is a state. If the example is not so good, that's why I added the second case scenario (State1, State2, etc..) Quote: However, one could also think of using "configurable types" avoiding mess in the inheritance chain. This sounds like what I could be looking for... Quote: A TypeInfo-link from TAnimal determining the gender would also do, like so: [TAnimal]-*----genderInfo--1-[TGender] | | [TMale] [TFemale] Sorry, I don't follow this. Can you elaborate? Thanks Rael Back to top Rael Guest Posted: Mon Mar 19, 2007 9:13 pm    Post subject: Re: How to design this? "Michael Baytalsky" wrote: Quote: Use interfaces. IMale, IFemale. Any class can implement them, that's it. You can also provide IGender interface telling which one of the above two is implemented. Well, the main point of my question, is that the implementation of IMale in the different animals is going to be the same (or almost the same...). So it sounds like you're agreeing with me - If there's some common functionality between the different classes, then just put it into a group of procedures or some class methods (perhaps of TAnimal or TGender). Rael Back to top Bob Dawson Guest Posted: Mon Mar 19, 2007 9:42 pm    Post subject: Re: How to design this? "Charles McAllister" wrote in message news:45feab00$1 (AT) newsgroups (DOT) borland.com... Quote: Rael wrote: So my question is how to best design a situation where you have a normal splitting hierarchy, but then lower down the hierarchy, different classes have similarities/the same code. Perhaps this is an obvious pattern? Strategy pattern? Yes, exactly http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/StrategyPattern.htm The characteristics (behavior/properties) of an object that vary according to an external paradigm are delegated to an internal object dedicated to that problem. I have some reservations, however, that gender is really a good candidate for this treatment. bobD Back to top Rolf Lampa [RIL] Guest Posted: Tue Mar 20, 2007 1:47 am    Post subject: Re: How to design this? Rael wrote: Quote: However, one could also think of using "configurable types" avoiding mess in the inheritance chain. This sounds like what I could be looking for... A TypeInfo-link from TAnimal determining the gender would also do, like so: [TAnimal]-*----genderInfo--1-[TGender] | | [TMale] [TFemale] Sorry, I don't follow this. Can you elaborate? Peter is probably right in that the solution above may be a bit "too much". I assume that Peter mean with that that "handcrafting" of persistent relations is perhaps not so easy (both me and Peter are namely "spoiled" from using Bold / ECO, and when using such application frameworks the only effort you take for creating persistent associations is "think it, and draw it" and then the tools take care of the the rest, the implementation). However, it may be of general interest to see the point with the ASCII-model above, which goes something like this: TAnimal has a pointer with name genderInfo assigned to an object comaptible with the type TGender (abstract). The actual instance assigned will be either a TMale or TFemale though. By associating gender like this you can in RT do the same cheks as Peter suggested, only a bit different. Your gender dependet code would look something like: procedure TAnimal<or SubClass>.DoSomething; // TMale and TFemale should be singletons. begin if Self.genderInfo is TMale then begin // do something masculine end else if genderInfo is TFemale then // do it less masculine else // well, do it like an androgyne would have done it. end; You can of course achieve the same distinction using a simple type as a member attribute instead, which would be "less" in terms of work required to implement. So Peter may well be right here, even if it at first seems so hard to believe... :) Regards, // Rolf Lampa Back to top Rolf Lampa [RIL] Guest Posted: Tue Mar 20, 2007 1:53 am    Post subject: Re: How to design this? Rael wrote: Quote: However, one could also think of using "configurable types" avoiding mess in the inheritance chain. This sounds like what I could be looking for... A TypeInfo-link from TAnimal determining the gender would also do, like so: [TAnimal]-*----genderInfo--1-[TGender] | | [TMale] [TFemale] Sorry, I don't follow this. Can you elaborate? Peter is probably right in that the solution above may be a bit "too much". I assume that Peter meant with that that "handcrafting" of persistent relations is perhaps not so easy (both me and Peter are namely "spoiled" from using Bold / ECO, and when using such application frameworks the only effort you take for creating persistent associations is "think it and draw it" and then the tool takes care of the the rest, the implementation). However, it may be of interest to see the point with the ASCII-UML-model above, which goes something like this: TAnimal has a pointer named genderInfo which is assigned to an object compatible with the type TGender (abstract). The actual instance assigned will be either a TMale or TFemale (well, nil could be "aqndrogyne...?). By associating gender in this way you can in RT do the same checks as Peter suggested, only a bit different. Your gender dependent code would look something like: procedure TAnimal<or sub class>.DoSomething; // TMale and TFemale should be singletons. begin if Self.genderInfo is TMale then begin // do something masculine end else if genderInfo is TFemale then // do it less masculine else // well, do it like an androgyne would have done it. end; You can of course achieve the same distinction using a simple type for a member attribute instead, which would be "less" in terms of work required to implement. So Peter may well be right here, even if it at first seems so hard to believe... :) Regards, // Rolf Lampa Back to top Charles McAllister Guest Posted: Tue Mar 20, 2007 2:27 am    Post subject: Re: How to design this? Bob Dawson wrote: Quote: I have some reservations, however, that gender is really a good candidate for this treatment. yes. i was assuming the example wasn't quite realistic. unless Rael works in the veterinary industry like me Back to top Bob Dawson Guest Posted: Tue Mar 20, 2007 5:03 am    Post subject: Re: How to design this? "Charles McAllister" wrote Quote: yes. i was assuming the example wasn't quite realistic. unless Rael works in the veterinary industry like me Where you at, Charles? Seems to me I recently saw a note about a Delphi shop in Missouri doing vet. software. That you? I'm in Iowa. bobD Back to top Charles McAllister Guest Posted: Tue Mar 20, 2007 7:10 am    Post subject: Re: How to design this? Bob Dawson wrote: Quote: Where you at, Charles? Seems to me I recently saw a note about a Delphi shop in Missouri doing vet. software. That you? I'm in Iowa. yes i work in Farmington, MO which is about an hour south of St. Louis. btw we've posted an opening recently on the jobs group. 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.