Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: topmind on 31 Jan 2007 19:30 On Jan 31, 2:38 pm, Robert Martin <uncle...(a)objectmentor.com> wrote: > On 2007-01-29 18:34:26 -0600, "topmind" <topm...(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. But schema design is not singificantly different than class design. I let the schema *be* the "domain classes" more or less rather than do it in code. I don't see how skipping schemas would quicken prototyping RAD. Besides, the DB does a lot of stuff *still* needed for the demo, like joins and searches that you would otherwise have to write by hand or reinvent/install a little OODBMS. I don't see why it would be less work to skip the DB. Again again again, *if* you *only* use the DB as a dumb filing system, then what you say makes sense. I tend to use as much of the DB as possible to handle as much of the app issues as possible. (Actually, i've met people who could do 90% of an app in SQL, but it was stretching the limits of SQL's comfort zone. I tend around 70%. Better relational languages and tools would probably push it to 85%) Incidently, perhaps consider prototyping it in MS-Access or Visual Basic, and then webifying it when done. Desktop GUI designers are usually better at interface-centric demo RAD. Web stuff has yet to catch up to desktop GUI RAD in my opinion. (Make it clear to the user that there are more limits on web-based interfaces than desktop ones. But at least you have an idea to work from.) > > (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: uncle...(a)objectmentor.com -T-
From: topmind on 31 Jan 2007 19:42 On Jan 31, 2:42 pm, Robert Martin <uncle...(a)objectmentor.com> wrote: > On 2007-01-29 22:40:39 -0600, "topmind" <topm...(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. It was the C# version (as stated in the very first link). Anyhow, we seem to be talking past each other. My reply to this would be something I've already said multiple times. I don't think N + 1 repeats will change anything. It is like debating over the location of the chair when we have a very different concept of what a "chair" is. > > -- > Robert C. Martin (Uncle Bob) | email: uncle...(a)objectmentor.com -T-
From: Patrick May on 31 Jan 2007 20:07 frebe73(a)gmail.com writes: >> > The most common data structures used in current programming >> > languages are lists and maps, so I think we can limit ourself to >> > these structures. >> >> I think we can use that statement as evidence that you don't know >> what you're talking about. Lists and maps may be the most commonly >> used, but they by no means define the full set of data structures >> used in production software. > > Did I claim that? You said "we can limit ourself to these structures." That is simply not the case. > You may pick any data structure and show the benefits compared to > relational algebra. Nice try, but you made the claim that "Relations is the only data structures that should be used." The burden of proof is on you. Of course, you've already contradicted yourself by admitting that other data structures are required to implement, for example, a relational database. >> I've been in the industry for close to twenty years and started out >> working on a CASE tool that supported all the common relational >> modeling techniques at the time. Nice try with the condescension, >> though. It's easier than actually defending your ridiculously >> broad claims, isn't it? > > What is your point? CASE tools are flawed? The relational model is > flawed? My point is that your attempt to use snide comments to deflect from your own inability to defend your claims has failed. >> More pronouncements from on high. You admit that there are >> performance benefits to non-relational data structures, > > Yes. > >> but assert without basis that they should nonetheless never be >> used. > > No, read above. Yes, that's exactly what you said. Now, if you're saying that other data structures should be used, I agree. That refutes (again) your original claim that "Relations is the only data structures that should be used." 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: Patrick May on 31 Jan 2007 20:10 "topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: >> 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. Actually, you did. Your exact words were: "If you embraced the DB instead of spend all your code wrapping it, the app would be noticably simpler." That's a positive claim about an objective measurement. > It just won't be objectively worse. That's another positive claim. Prove it. 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: Robert Martin on 31 Jan 2007 21:12
On 2007-01-29 22:54:20 -0600, "topmind" <topmind(a)technologist.com> said: > I disagree. If you use the DB for such, then there would be little or > no need for polymorphism, and if you don't use polymorphism and don't > use inheritence, then OO is not going to give much. The procedural > code to process the DSL would look something like: > > total = 0; // initialize > sql = "select * from commands order by cmd_sequence > where empID =" . empID; > rs = query(sql); > while (row = nextRow(rs)) { // row is a map array > switch on row.cmd { > case "add" {....} > case "subtract" {....} > case "multiply" {....} > etc... > } // end-switch > } //end-while > > > Poly does not contribute if there is only *one* case list with such > items. (I avoided C-style stupid archiac "break" syntax.) Consider this: sql = "select * from commands order by cmd_sequence where empID =" . empID; rs = query(sql); while (cmd = nextCommand(rs)) { // row represents a command object cmd.execute(); } //end-while ==================== sql = "select * from commands order by cmd_sequence where empID =" . empID; rs = query(sql); while (cmd = nextCommand(rs)) { // row represents a command object cmd.print(); } //end-while ===================== These two functions are immutable when new commands added, or existing commands are changed or deleted. Being able to isolate functions from certain kinds of change is one of the major goals of software engineering. OO gives you more tools to do that with. -- 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� � � � � � � � ��| |