Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: topmind on 30 Jan 2007 00:46 Robert Martin wrote: > On 2007-01-28 11:41:50 -0600, frebe73(a)gmail.com said: > > > OO people claim that OO can be used for everything. So why don't you > > use a OODBMS? What are the benefits with SQL databases that makes you > > to use them instead? > > I think that time has shown that OODBMS has been a dead end. The > arguments you relational guys have been making about RA have proven > correct, and the industry has almost completely sided with you. Oh I > know a few OODBMS hold-outs; but not many. The technology may make a > comeback one day when RAM storage becomes cheaper than disk. We'll see. Why would that change anything? One can make the RAM/Disk difference transparent. In fact, caching and virtual memory does this even now. (Cheap RAM can benefit RDBMS also, I would note.) OODMS are dead because they had most of the same problems that navigational DB's had in the 60's (which motivated Dr. Codd to clean up the scene.) > > Most people who use relational databases use them as the back end to an > OO middle and front end? Most? Like I keep saying, OO gets more lip service than actual usage in practice. Many OO proponents have agreed with me on this. (They say it is because people don't yet "get OO" or are allegedly too lazy to "do it right", not because OO is flawed.) > Business rules (other than searching and > corelating) are done in the middle layers by OO programs. I've seen a lot of "business rules" being handled by SQL. Lots. (Even over-using SQL beyond its comfort zone.) A good portion of biz rules can be reduced to sets and attributes if organized properly. > Presentation > is done by OO programs at the front end. Not always. A lot is strait HTML+JavaScript these days (for good or bad). > Transport between system is > done by OO programs in the middleware and front end. etc. > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: topmind on 30 Jan 2007 01:03 Robert Martin wrote: > On 2007-01-28 11:41:50 -0600, frebe73(a)gmail.com said: > > > The most common data structures used in current programming languages > > are lists and maps > > Not so fast there partner. The most common data structure used in > current programming language is: object. An object is a tuple, very > similar to a table row. Objects can be connected into graphs through > the use of pointers. Objects are essentially maps with a little syntactic surgar. In the simplest OO languages, objects and maps are nearly indistinguishable. > > Now I know you think this is a network database and you get all hot and > bothered about that since the relational gods proved that network > databases were demon spawn. But these aren't network databases. These > are just transient networks of objects that are used to facilitate > calculations and decision making. Transient small network databases? Does that separate them significantly from the those that are "demon spawn"? If they are small and trivial, then procedural would be simplier. If they are large and complex, then they more resemble the "demon spawn" mentioned. You are essentially stuck between a rock and a hard place: At the trivial end, procedural is simpler, and at the complex end they become a twin brother of navigational or network databases. And in between they suffer half the problems of both. And OO has not found a clean way to manage all that transientivity. In procedural you focus on one task at a time, saving any "state" to the DB when done, and clearing out just about everything. It has cleaner boundaries because each task is nearly a clean slate. Objects float around until they catch syphillus or the like. (And event-driven programming has reduced the app-side complexity of the procedural "master loop".) > > It is these graphs of objects that are the most common data structures > in object oriented programs. > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: topmind on 30 Jan 2007 01:06 Robert Martin wrote: > On 2007-01-27 23:56:27 -0600, frebe73(a)gmail.com said: > > > As much business logic as possible should be implemented in SQL. But > > due to the limitations in the SQL language, it is not possible to > > implement all business logic in SQL. The rest you have to implement in > > the application. > > Now that we all agree that SQL is good for some things, and OO is good > for others, all we have left to argue about is degree. Is it just me, or did somebody make a huge leap in interpretation here? > > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: topmind on 30 Jan 2007 01:21 Robert Martin wrote: > On 2007-01-27 11:05:57 -0600, frebe73(a)gmail.com said: > > > If the database isn't availible for developers, I suggest solving that > > problem instead of changing the way you design software. Installing a > > full database on a laptop has not been a problem for the last 10 years. > > Eclipse uses more memory and CPU on my laptop than my SQL Server, > > Oracle, Postgres and MySQL instances together. > > ;-) You haven't talked to some of the DBAs that I've talked to. Some > won't allow the developers do TOUCH the database, let alone have a copy > on their laptops. There are ongoing battles between DBA's and app developers because they both have different missions. DBA's are charged with keeping the data sound, clean, consistent, and non-redundant. App developers on the other hand want to get *their* app out as quickly as possible and don't really have a vested interest in company-wide data consistency. In the end some compromise should be made. Whether the DBA lets you compromise is a political issue, not a technical one. It is like having a "base class master" who is not very forgiving. > > But actually, I agree with you. If I'm developing an application I > want a copy of the database on my laptop because, as a developer, > nothing should be outside of my control. > > Still, I want to be able to run tests without the database running. If most of the real biz logic is done by the DB, then you mostly are just testing output transfers if you go that route. It often makes more economic sense to test them together to kill two birds with one stone. Companies are cheap: they are happy when you do 2 things at the same time. Perhaps you come from different environments, but where I've been they want to squeaze maximum productivity out of every little human movement, and having too many layers to test and coordinate can get in the way of that. Perhaps if the domain is life- support medical systems, then the extra e-beurocracy is justified. > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: AndyW on 30 Jan 2007 03:39
On Mon, 29 Jan 2007 21:46:13 -0600, Robert Martin <unclebob(a)objectmentor.com> wrote: > >>> "an object is a relation" ??? A relation in relational theory, >>> consisting of a set of tuples, is roughly analogous to the idea of a >>> table, consisting of a list of rows. > >An object is an instance of a relation. The relation itself is >described by the class of the object. Sorry, I cant agree with that last sentence. Could you explain what you mean by that statement in case my understanding is wrong. I've always understood a relation to be an abstract thing. Andy |