Don't Repeat Yourself vs Dependencies
in [OOP]
|
Prev: Showing exceptions on UML class diagram
Next: Call for Papers: International MultiConference of Engineers and Computer Scientists IMECS 2008
From: elephant on 12 Oct 2007 11:16 This is possibly a stupid question, but, I haven't decided the correct way to approach this and I thought I'd seek out more knowledgeable advice. On a project I'm working on a few different classes that access a database. Currently they do this by going through a separate class that they're coupled with (please forgive me if I just used, or do use terms incorrectly, I'm fairly new to OOP). I have 4 separate classes that use this one class, but a couple of these classes may be used in other projects. Is it better to implement database connect procedures in these classes, so that I can freely take them out and plug them in to another project without also taking the DB class, or is it better to keep this central DB connection, and only add in another connection class when it becomes necessary. Alternatively is this something that depends, and that I'll just have to learn it as I gain more experience? The goal with the code in this project is maintainability, and I'm just not sure which would provide more. Thank you for your time.
From: Daniel T. on 12 Oct 2007 14:28 elephant <matt.minix(a)gmail.com> wrote: > This is possibly a stupid question, but, I haven't decided the > correct way to approach this and I thought I'd seek out more > knowledgeable advice. > > On a project I'm working on a few different classes that access a > database. Currently they do this by going through a separate class > that they're coupled with (please forgive me if I just used, or do > use terms incorrectly, I'm fairly new to OOP). I have 4 separate > classes that use this one class, but a couple of these classes may > be used in other projects. Is it better to implement database > connect procedures in these classes, so that I can freely take them > out and plug them in to another project without also taking the DB > class, or is it better to keep this central DB connection, and only > add in another connection class when it becomes necessary. > Alternatively is this something that depends, and that I'll just > have to learn it as I gain more experience? > > The goal with the code in this project is maintainability, and I'm > just not sure which would provide more. Thank you for your time. Generally, duplication is less maintainable than indirection. So we tend to favor indirection when it can be used to remove duplication. When it comes time to use one or more of your four classes in another system, you will want to use your database class there as well. If the other system needs to use a variation of the database class, then you have reason to make an abstract database class that both systems use.
From: Phlip on 13 Oct 2007 11:14 elephant wrote: >... I have 4 separate classes > that use this one class, but a couple of these classes may be used in > other projects. Is it better to implement database connect procedures > in these classes, so that I can freely take them out and plug them in > to another project without also taking the DB class... This sounds like speculation, not duplication. You currently have only one database and one connection. More than one database is a problem you'd like to have. You should be thankful you have only one database, and not > The goal with the code in this project is maintainability How are your unit tests doing? -- Phlip http://www.oreilly.com/catalog/9780596510657/ "Test Driven Ajax (on Rails)" assert_xpath, assert_javascript, & assert_ajax
From: H. S. Lahman on 13 Oct 2007 13:00 Responding to Elephant... > This is possibly a stupid question, but, I haven't decided the correct > way to approach this and I thought I'd seek out more knowledgeable > advice. Far from stupid. Accessing persistence mechanisms has been an ongoing debate on this forum for a couple of decades. > On a project I'm working on a few different classes that access a > database. Currently they do this by going through a separate class > that they're coupled with (please forgive me if I just used, or do use > terms incorrectly, I'm fairly new to OOP). I have 4 separate classes > that use this one class, but a couple of these classes may be used in > other projects. Is it better to implement database connect procedures > in these classes, so that I can freely take them out and plug them in > to another project without also taking the DB class, or is it better > to keep this central DB connection, and only add in another connection > class when it becomes necessary. Alternatively is this something that > depends, and that I'll just have to learn it as I gain more > experience? When in doubt, think: encapsulation. The mechanisms for accessing stored data in flat files, an RDB, an OODB, or on clay tablets will be quite different. Do the applications that need to access stored data care about those details? No; they just want to think in terms of, "Here's a pile of data I call 'X'. Save it until I ask for 'X' sometime in the future." Do the storage mechanisms care what problem the application is solving? No; in fact, RDBs were originally designed to store data in a manner that is independent of its usage. So the bottom line is to encapsulate the persistence access mechanisms in a subsystem or layer and provide a generic interface to it (e.g., saveX(...)). Then you can swap persistence mechanisms freely without touching the applications that use the data because they "see" the same interface. And quite different applications can access the same data through that interface. (Note that subsystem interfaces are commonly implemented as GoF Facade design patterns.) You can also get large scale reuse out of it. When the persistence mechanisms are encapsulated, you can abstract the invariants of the mechanisms and relegate details to configuration data. So the same subsystem that models Schema, Table, Query, etc. objects for an RDB can be reused for different databases simply by providing different configuration data for initializing instances. (The category "Invariants and Parametric Polymorphism" in my blog has some examples of this sort of thing that may be of interest to you.) ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: topmind on 14 Oct 2007 16:30
On Oct 13, 10:00 am, "H. S. Lahman" <h.lah...(a)verizon.net> wrote: > Responding to Elephant... > > > This is possibly a stupid question, but, I haven't decided the correct > > way to approach this and I thought I'd seek out more knowledgeable > > advice. > > Far from stupid. Accessing persistence mechanisms has been an ongoing > debate on this forum for a couple of decades. Databases are for far more than mere "persistence". People who tend to call them only persistence use them as mere object dumping grounds (dumb filing system) and end up unnecessarily reinventing database concepts in app code rather than let the DB do what it does best. > H. S. Lahman -T- oop.ismad.com |