Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: Patrick May on 30 Jan 2007 20:34 "topmind" <topmind(a)technologist.com> writes: > On Jan 30, 3:32 pm, Patrick May <p...(a)spe.com> wrote: >> "topmind" <topm...(a)technologist.com> writes: >> > Robert Martin wrote: >> >> Anyway, I'm not talking about ORM necessarily. My point is that >> >> relational databases play very nicely with OO languages. I've >> >> seen this many times. There are books and articles published >> >> about the techniques and patterns that can be used. And >> >> virtually every major website on the net makes use of the two. >> >> >> Are there problems marrying the two? Certainly. But mostly >> >> those problems come from the misaprehension that there is some >> >> kind of overlap between their functions. When you realize that >> >> RDBs and OO are different tools that solve different problems, >> >> you find that they work quite nicely together. >> >> > I've asked for examples to examine before, and you recommended >> > your book. Your only semi-realistic biz example, payroll, does >> > not demonstrate simplicity by any stretch. If you embraced the DB >> > instead of spend all your code wrapping it, the app would be >> > noticably simpler. >> >> That's a positive claim. Prove it. Let's see your >> implementation. > > First I wish to settle the wrap/don't-wrap issue, as that is > somewhat orthogonal to OO versus p/r. Otherwise you will just say, > "Yours is smaller because he wrapped and you didn't." First, smaller is not necessarily simpler. Second, you haven't shown that a solution that "embraced the DB" would be shorter, more understandable, more maintainable, more extensible, more easily testable, or "simpler" by any other metric. Third, Mr. Martin said that OO techniques and relational databases "work quite nicely together." You are the one who equated that with "simplicity." You've repeatedly asked for code demonstrating the benefits of OO during your years in this newsgroup, now let's see yours. Prove that your approach provides the same benefits as the OO techniques demonstrated by Mr. Martin, more simply. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: topmind on 30 Jan 2007 23:55 Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > On Jan 30, 3:32 pm, Patrick May <p...(a)spe.com> wrote: > >> "topmind" <topm...(a)technologist.com> writes: > >> > Robert Martin wrote: > >> >> Anyway, I'm not talking about ORM necessarily. My point is that > >> >> relational databases play very nicely with OO languages. I've > >> >> seen this many times. There are books and articles published > >> >> about the techniques and patterns that can be used. And > >> >> virtually every major website on the net makes use of the two. > >> > >> >> Are there problems marrying the two? Certainly. But mostly > >> >> those problems come from the misaprehension that there is some > >> >> kind of overlap between their functions. When you realize that > >> >> RDBs and OO are different tools that solve different problems, > >> >> you find that they work quite nicely together. > >> > >> > I've asked for examples to examine before, and you recommended > >> > your book. Your only semi-realistic biz example, payroll, does > >> > not demonstrate simplicity by any stretch. If you embraced the DB > >> > instead of spend all your code wrapping it, the app would be > >> > noticably simpler. > >> > >> That's a positive claim. Prove it. Let's see your > >> implementation. > > > > First I wish to settle the wrap/don't-wrap issue, as that is > > somewhat orthogonal to OO versus p/r. Otherwise you will just say, > > "Yours is smaller because he wrapped and you didn't." > > First, smaller is not necessarily simpler. Agreed, but Martin has not spent is his code wisely enough to make up for the bloat IMO. > Second, you haven't > shown that a solution that "embraced the DB" would be shorter, more > understandable, more maintainable, more extensible, more easily > testable, or "simpler" by any other metric. I don't claim I can show it objectively better. It just won't be objectively worse. I've resigned to the fact that my preference for relational, tables, and sets may be purely subjective. But I do know they fit the way I think much better than OO. And I try to convey the psychology going on the best I can. I don't see you guys trying very hard at that end. Subjective preferences are the deciding factor if there is no objective betterment. > Third, Mr. Martin said > that OO techniques and relational databases "work quite nicely > together." You are the one who equated that with "simplicity." > > You've repeatedly asked for code demonstrating the benefits of OO > during your years in this newsgroup, now let's see yours. What? He didn't show better OO code. It runs and it fits the requirements. That is all I give him right now. > Prove that > your approach provides the same benefits as the OO techniques > demonstrated by Mr. Martin, more simply. I will, on my own time-table. > > Sincerely, > > Patrick > > ------------------------------------------------------------------------ -T-
From: topmind on 31 Jan 2007 13:51 Thomas Gagne wrote: > Robert Martin wrote: > > <snip> > > 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. > You're correct, but does that mean we should stop there? Let's say RDBs > are great for prototyping and production. Their flexible structure > makes them great for trying things out, proving them correct, and even > shipping to production. Once the /model/ has been proven correct is > there any reason it can't be hard-wired into a network database and made > even faster and more compact? Is it possible the RDB is the > scripting-language prototype language for DBs and that network databases > might be there compiled form? > > I remember doing some testing (I admit it's a bit outdated) between > network and relational databases--same model, different implementation, > same tasks, and found the network model to be /significantly/ faster > than relational. I haven't the time (or the network database) to do the > same comparison now, but the thought has been brewing now for a while... Is speed really such an issue that you would *abandon flexibility* to acheive it? Nothing is stable in business. Schemas will always need changing. One-to-one (single table) relationships can grow into one-to- many, for example. As a company grows, there will always be changes to the "quantity-of-relationships" between things. You might start out with one address per customer, but then find that multiple are needed for bigger customers. Thus, you may want to farm such off to a Contact table instead of keep address in Customer table so that a customer can have many addresses (contacts). I can agree that a special-purpose database could be faster than a general-purpose one, at least for known calculation/query paths, but flexibility is generally a *good* thing for most businesses. Managing the complexity of change seems a bigger problem than more horse-power. Sure, we want both, but flexibility is rated higher in my opinion. Especially since Free Trade is forcing the US to specialize in change: stable commodities move overseas where labor is cheaper. Plus, a flexible system may be easier to keep clean. Performance problems are often due to nobody willing to make the leap to clean up accumulated cruft and fudges. If the cost to change is higher due to hard-wiring stuff, then people would be even more likely to put bandaids over problems instead of refactor stuff. It is an interesting question, though. Also, being dedicated and being non-relational are not necessarily the same thing. A hard-wired relational schema could also be a source of speed. > > -- > Visit <http://blogs.instreamfinancial.com/anything.php> > to read my rants on technology and the finance industry. -T-
From: Robert Martin on 31 Jan 2007 17:38 On 2007-01-29 18:34:26 -0600, "topmind" <topmind(a)technologist.com> said: > > Robert Martin wrote: >> 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 think this is often a bad idea. The schema tells you a lot about the > biz. For example, suppose you are about to write the following specs: > > * Send a notice to student's mailing address. > > But if you look at the schema, you may notice that a given student has > *multiple* potential addresses (many-to-one). You now know that the > above is not sufficient. You need to rework it to be something like: > > If student has a home address, then send it home. > Else if student has a campus address, then send it to campus address. > Else if student has a "parents" address, then send to parents. > Otherwise, log the error. > > The schema can tell you "free" information that you would have to ask a > gazillion questions about from a human. Well, yes, IF you have a schema. Clearly if you have a schema already, you are going to have to create behaviors that are compatible with that schema, and of course this will give you lots of "free" information about the system you are writing. No argument. However, what if you don't have a schema? For example, I am currently writing a little system that manages substitute teachers. Teachers call in to an answering machine and leave verbal messages with the dates that they will need substitutes. The user of the system listens to these messages and enters on a screen and stores them into a database. etc. etc. (BTW, I'm using MSQL, though that's not particularly relevant). I talked to my user for a good long time and got a nice list of requirements. Then, for some silly reason I worked out an ER diagram for the system. I won't bore you with the details. I wrote the DDL for the Schema and generated my database. Then I started putting screens together and binding them to the database. Everything was wonderful. A short time later I had one tiny bit of the application working, and I showed it to my user. The user wasn't impressed. I asked why, and the user got into a lot more detail about HOW she worked, rather than the data she recorded. This information changed the workflow of the application to the extent that the careful schema I had written was invalid. I deleted the DDL, changed the ER diagram entirely, and started over. The point is that data models are just as variable (and just as likely to be wrong) as software. Indeed, data models ARE software. The only way to know of you get them right is to build the system and let the user use it. So, I often build behaviors without a schema as a way to understand the needed behaviors. This then allows me to create a schema that is appropriate to those behaviors. (As for why I didn't follow my own advice on this project: I was using Rails for the first time. Rails is very DB centric. The rails toolset puts a subtle pressure on you to build the schema first. I fell for it, and suffered the consequences.) -- 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 31 Jan 2007 17:42
On 2007-01-29 22:40:39 -0600, "topmind" <topmind(a)technologist.com> said: > I've asked for examples to examine before, and you recommended your > book. Your only semi-realistic biz example, payroll, does not > demonstrate simplicity by any stretch. If you embraced the DB instead > of spend all your code wrapping it, the app would be noticably simpler. > The DB already exists, it easily provides joins and noun > classifications such that we shouldn't have to repeat such in the code. I don't know which version of the book you read. If it was the 2001 edition with Java and C++ examples ("Agile Software Development, Principles, Patterns, and Practices"), then there was no database in the example, only the interfaces that might be implemented by a database. If, instead, you read the 2005 edition in C#, ("Agile Principles, Patterns, and Practices in C#") then there WAS a database implementation. It was added long after the rest of the application was working. -- 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� � � � � � � � ��| |