Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: topmind on 29 Jan 2007 19:34 Robert Martin wrote: > 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 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. The schema educates you. Plus, it gives you some name suggestions so that you avoid reinventing a lot of attribute and entity naming. You will have less mismatches. And can save work by not having to write aliasing code. (I suppose you will anyhow if you do a lot of those annoying beurocratic set/gets rather than let the record set attribs name themselves from the query, which is better repetition factoring IMO.) > 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. If you don't know the schema, then you probably don't know the business rules enough to make worth-while code-able psuedocode. If somebody has to tell you info that is *already* in the schema, you look like a newbie or a contractor billing-hours padder. > > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: Robert Martin on 29 Jan 2007 19:49 On 2007-01-29 17:54:34 -0600, "topmind" <topmind(a)technologist.com> said: > >> 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. Agreed! Creating DSLs in often a good approach to the problem of complexity. Using an RDB to store the DSL can also be beneficial. To pull this off you need an engine that interprets the DSL. That engine will be written in a programming language. OO is particularly well suited to manage the complexity of such an engine. > Polymorphism is a smell of hardwiring going on. Silly boy. Polymorhism is the smell of dependencies breaking. -- 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: Daniel Parker on 29 Jan 2007 21:35 On Jan 29, 6:27 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On 28 Jan 2007 16:04:30 -0800, Daniel Parker wrote: > > > > A relation is a value, a relation is a > > set of tuples, every value is a value of some type, the type of a > > relation is parametrized on the type of its member tuples. And??? > Then the tuple (T, r) is a relation object. Here T is the type of the > relation r and r is the value of, i.e. the relation itself. A relation object. Is that what you meant when you said " An object is a relation, and it is very convenient to use"? I suppose (double type, double value) is a double object. Does this mean I can say "An object is a double and it is very convenient to use"? > > >> RA is about specialized containers and thus deserves no any special > >> treatment. > > > RA is about a formal logical system about relations,OK, if you take a mathematical definition of algebra. > But in the context of this thread, RA refers to its application for software developing and > design. RA doesn't mean that in any context. > > > and a small > > number of operations that map relations into relations. What is the > > special treatment?It is an attempt to encapsulate it into a physically separate component > interfaced though its own language. That thing is called RDBMS, which is > responsible for implementation of RA. RDBMS demonstrates the benefits of basing software on a formal logical system. OODBMS demonstrates the problems of not doing so. Venture capitalists appreciate the difference, even if their command of set theory is a little rusty. > > Because this design is obviously flawed, proponents of RDBMS try to argue > that RA is capable to describe everything in the best possible way. > On the contrary, it is you that is claiming that OO is capable of describing everything in the best possible way. Really. Daniel
From: Daniel Parker on 29 Jan 2007 21:51 On Jan 29, 9:35 pm, "Daniel Parker" <danielapar...(a)gmail.com> wrote: > On Jan 29, 6:27 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > > "An object is a relation, and it is very convenient to use"? Dimitry, my apologies, I attributed that quote to you, but it was actually by Robert Martin, further up the thread. Although you did respond saying it was "formally correct" :-) Daniel
From: Robert Martin on 29 Jan 2007 22:46
>> "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. -- 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� � � � � � � � ��| |