Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: frebe73 on 29 Jan 2007 17:32 > > Are you totally ignorant about spatial databases? > No, I am of any "relational data structure" (RDS) for the problem > described. Your references to some software products are irrelevant as long > you cannot assert that they solve the problem using such an RDS. In case > they do, please, don't hesitate to present it us. How do you expect such assertion to be made? Disassembling the executables? I understand that you don't trust any documentation, but why do think products like Oracle Spatial and PostGIS have specalized index types, if they are not able to make use of them? Fredrik Bertilsson http://mybase.sf.net
From: Robert Martin on 29 Jan 2007 18:07 On 2007-01-26 15:13:12 -0600, "topmind" <topmind(a)technologist.com> said: >> One of the fundamental rules of Agile is YAGNI, "You >> Aren't Going to Need It." In short, this rule says that you should not >> include support for something just because you think you are going to >> need it. Only provide support for what you need right now. > > Then why do you wrap all your SQL behind classes, methods etc? Was that > an up-front need? Yagni adherence would dictate waiting until you > actually need wrapping. (By the way, I somewhat disagree with Yagni. It > is a good rule of thumb, but should not be sought dogmatically. > Software development is about weighing gajillion tradeoffs. It's a > tradeoff weighting symphony, You don't bang on just one piano key.) I completely agree. I wrap the SQL because I actually write the business rule code before I know what the schema is, or even whether I'll be using an RDB. I need to test those business, so I create interfaces that allow my test drivers to provide data as though it came from a DB. Those interfaces are later implemented by the database layer with SQL. -- Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com The Agile Transition Experts��| web:���www.objectmentor.com 800-338-6716� � � � � � � � ��|
From: Robert Martin on 29 Jan 2007 18:10 On 2007-01-26 21:28:49 -0600, "topmind" <topmind(a)technologist.com> said: >> Then you should also entertain the possibility that objects and RDBs >> can be used synergistically. > > I am not saying it can't happen, only that nobody has *shown* it > happening. OO and RDB's seem to overlap too much. They are different > approaches to fairly similar needs. I think lots and lots of people have shown that the two play nicely together. They are different approaches to very different needs. RDBs store, organize, search, fetch, and process data. OO languages help to organize complex software systems. -- Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com The Agile Transition Experts��| web:���www.objectmentor.com 800-338-6716� � � � � � � � ��|
From: Robert Martin on 29 Jan 2007 18:26 On 2007-01-26 19:01:55 -0600, "Daniel Parker" <danielaparker(a)gmail.com> said: > Hmmm ... whatever happened to your idea of using arrays of > interconnected data structures in 100 gigs or so of non volatile RAM, > in preference to RDBMS? Nothing. For those applications where that would work (e.g. embedded applications) I think it works nicely. One day it may even work well for certain enterprise solutions. -- Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com The Agile Transition Experts��| web:���www.objectmentor.com 800-338-6716� � � � � � � � ��|
From: topmind on 29 Jan 2007 18:54
Robert Martin wrote: > On 2007-01-26 21:28:49 -0600, "topmind" <topmind(a)technologist.com> said: > > >> Then you should also entertain the possibility that objects and RDBs > >> can be used synergistically. > > > > I am not saying it can't happen, only that nobody has *shown* it > > happening. OO and RDB's seem to overlap too much. They are different > > approaches to fairly similar needs. > > I think lots and lots of people have shown that the two play nicely > together. "Play nicely" by what standards? The code in your book *runs*, yes, but I would hate to have to maintain such code. Here are two sets of opinions which suggest the OO+R land is not so rainbowee: http://www.codinghorror.com/mtype/mt-comments-renamed.cgi? entry_id=621 http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer +Science.aspx > They are different approaches to very different needs. RDBs > store, organize, search, fetch, and process data. OO languages help to > organize complex software systems. Those are not necessarily mutually-exclusive. One way to manage "complex software" is to meta-tize much of it such the tables become a kind of domain-specific language such that one is "programming in the tables" so that one is not dealing directly with programming languages. Non-programmers or newbie programmers can then perhaps participate also if a few RAD edit screens/grids are built. Product categories, employee classifications/groups, pay deductions and their sequence/priority, etc. become data in tables instead of boatloads of classes hard-wired into programs. Queries also do much of the collection-oriented work such that one is not wasting code iterating thru linked lists of objects, etc. And if you did factor all these to tables instead of classes, your OO code is more or less procedural wearing bulky OO clothing. All roads lead to Rome. Polymorphism is a smell of hardwiring going on. (If there are not enough changes or "instances" to qualify for tablization, then which paradigm is used for app code will not make much difference anyhow. But I just find procedural simpler at the small level.) > > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T- |