BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Specialized classes vs. a class with more properites?          BorlandTalk.com Forum Index -> Delphi OO design View previous topic :: View next topic   Author Message Shawn Oster Guest Posted: Mon Oct 27, 2003 6:57 pm    Post subject: Specialized classes vs. a class with more properites? Let me try to make the subject more clear. When do you decide to stop creating specialized decendant classes and start adding in properties to support the various states? I have the two options as I see it below, using two different class hierarchies. A) Specialized Classes: TMyDatabase = class; // base object to open, close databases TSingleFileDatabase = class(TMyDatabase); // opens databases that use a single file to contain multiple tables TMultipleFileDatabase = class(TMyDatabase); // a file equals a table (dBase style) TAccessDatabase = class(TSingleFileDatabase); TExcelDatabase = class(TSingleFileDatabase); TDBase = class(TMultipleFileDatabase); TParadox = class(TMultipleFileDatabase); TShape TRect(TShape) TTrianle(TShape); OR B) Large multi-purpose Class: TMyDatabase = class; TDaoDatabaseType = (dtAccess, dtExcel, dtdBase, dtParadox); TDaoDatabase = class(TMyDatabase) property DatabaseType: TDaoDatabaseType; end; TShapeType = (stRect, stTriangle); TShape property ShapeType: TShapeType; property Points; end; Any thoughts? Shawn Back to top Jim Cooper Guest Posted: Mon Oct 27, 2003 11:04 pm    Post subject: Re: Specialized classes vs. a class with more properites? Quote: Any thoughts? Which route you go mostly depends on : - How much code would be different between the classes. In the shapes class example say, it might just be a case statement in a Paint routine, so it'd be ok all in one class. - Are you going to need to modify/inherit from those classes later? What type of changes might be needed? What'll be easier/make more sense - a new class or an extra enumeration? - Who the end users of the classes are. If it's you then you have more freedom of action. If it's part of a framework that will be used in multiple apps, or by people you don't know (eg if you're selling the framework), you need to try and get it right earlier. These days I tend to do things the simplest way first, and refactor as I need to, as the code takes shape. 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 Bob Dawson Guest Posted: Tue Oct 28, 2003 3:19 am    Post subject: Re: Specialized classes vs. a class with more properites? "Shawn Oster" wrote Quote: When do you decide to stop creating specialized descendant classes and start adding in properties to support the various states? Considerations: One generally thinks of states as mutable--if the state can change during the lifetime of the object, then we don't really have two different class, just one class with state. Does (or should) any other object care about the state? (Example: in the code myDB := TMyDatabase.Create(ConnectionInfo); myDB.Connect; why should any outside class care if we've just created a single file database or a multi?) If no other class does care, then the original question becomes Should the line myDB := TMyDatabase.Create(ConnectionInfo); be implemented as a class factory (returning the proper TMyDatabase subclass) or as a simple parameterized constructor? Do whichever seems to make the code cleaner and more maintainable overall. In general, the more complex and far-reaching the effect of the state/property is, the more one considers making it a subclass Quote: I have the two options as I see it below, Remember also that there's a third choice: variation by internal delegation to strategy objects. This becomes very important if an object has multiple state paradigms. Imagine TMyDataBase --MyDatabaseWithXofAWithYofA --MyDatabaseWithXofAWithYofB --MyDatabaseWithXofBWithYofA --MyDatabaseWithXofBWithYofB oops--third dimension? 12 descendents! In this case, a top level object with three implementer strategy objects (one for each dimension) simplifies the design by 9 classes. The top level class just has to internally create whichever it needs in a mix and match manner, rather than being forced into the permutation explosion that class specialization would lead to, or the constant and convoluted case checking.that multiple, simple state-flags can entail. bobD Back to top Brad White Guest Posted: Wed Oct 29, 2003 5:23 pm    Post subject: Re: Specialized classes vs. a class with more properites? "Shawn Oster" <soster (AT) moc (DOT) xelfroloc> wrote Quote: Let me try to make the subject more clear. When do you decide to stop creating specialized decendant classes and start adding in properties to support the various states? I have the two options as I see it below, using two different class hierarchies. You may find Refactoring To Patterns helpful. http://www.industriallogic.com/xp/refactoring/ -- HTH, Brad White Back to top Shawn Oster Guest Posted: Wed Nov 05, 2003 7:51 pm    Post subject: Re: Specialized classes vs. a class with more properites? Thanks for your (and the other's) suggestions. Helped me take a step back from the design I was mired in. For now I'm going with a state flag to avoid a huge hierarchy. If it grows any more complex then I will go down the strategy pattern road. I like the concept of being able to change the internal working classes while keeping the same exterior class. Thanks again, Shawn "Bob Dawson" <RBDawson (AT) prodigy (DOT) net> wrote Quote: Remember also that there's a third choice: variation by internal delegation to strategy objects. This becomes very important if an object has multiple state paradigms. Imagine TMyDataBase --MyDatabaseWithXofAWithYofA --MyDatabaseWithXofAWithYofB --MyDatabaseWithXofBWithYofA --MyDatabaseWithXofBWithYofB oops--third dimension? 12 descendents! In this case, a top level object with three implementer strategy objects (one for each dimension) simplifies the design by 9 classes. The top level class just has to internally create whichever it needs in a mix and match manner, rather than being forced into the permutation explosion that class specialization would lead to, or the constant and convoluted case checking.that multiple, simple state-flags can entail. 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 Page 1 of 1   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.