Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: frebe73 on 26 Jan 2007 16:12 > > You claim that it is possible to only have a few number of > > getEmployeeBySomeCriteria methods with optimized SQL statements for > > every different way you might need to fetch employee data? That should > > only be possible for rather small applications. > > Can you give an example of an application that would have an excessive > number of getemployeBySomeCriteria() methods that doesn't encroach on > becoming a report writer? A HR application need data about employees in many different ways. RCM already gave you one example of a very specific criteria for finding employees. When a company needs to reduce the staff, it would be nice if the HR application had a feature to find employees eligible for early retirement, wouldn't it? It is easy to imagine other examples of very specific ways of finding employees. Lets say we want to send every manager an email containing the employees having 30-, 40-, 50-year birthday next month. Lets say we have a function sending information to insurance company about changes in salaries, we need a way to find employees with changed salary. How could you possible solve this only a few functions for finding employees? > All our reports have been implemented as > stored procedures and have been meticulously crafted to perform well and > balance to other reports. There are many similarly-named reports but > the user doesn't really see that because they navigate through the data > starting at the top-level and drilling-down. Are there any significant difference between producing data on a paper, displaying it on a computer screen or using it in a thread sending e-mails? I have seen systems like you describe above. The only way to access a lot of the information was to print it, or get it as a large PDF-file. It so 60's. > If there really was a requirement for ad-hoc getEmployee() methods What's ad-hoc about set theory and predicate logic? Fredrik Bertilsson http://mybase.sf.net
From: topmind on 26 Jan 2007 16:13 On Jan 26, 12:59 pm, Robert Martin <uncle...(a)objectmentor.com> wrote: > On 2007-01-25 22:23:23 -0600, JXStern <JXSternChange...(a)gte.net> said: > > > On Tue, 23 Jan 2007 15:43:12 -0600, Robert Martin > > <uncle...(a)objectmentor.com> wrote: > > >>> I deny any such claim even makes sense, other than making Agile a > >>> wrapper you can throw anything at all into. > > >> My point was that "Agile" makes no judgements on whether a parcticular > >> tool is "good" or "bad" (i.e. pro/con). Rather it makes judgements > >> about how and when tools should be used. > > > I deny that it makes even a little bit of sense to say that Agile > > offers any judgement on when and whether to use RDBMS. You're > > overloading the term "Agile" to link unrelated advice in random > > directions. > > Not at all. 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.) > > We used this advice in the development of FitNesse (www.fitnesse.org). > Early on we were pretty sure we'd need some kind of database; but since > the early features of the system didn't require persitence, we didn't > select or implement a database. > > Later in the development we started needing the ability for simple > queries, but we still didn't need persistence. Since the queries were > simple (just name lookups) we created a data lookup interface and > implemented it with a hashmap. > > Still later we started needing longer term persistence, but nothing > very elaborate, so we reimplemented the data lookup interface with a > flat file system. > > We've never needed anything more than that. We didn't know this when > we started. We thought we'd need an RDBMS back end; but that just > never turned out to be the case. It sounds like FitNesse could have still used a database, or at least it is close to the borderline. Making logs, reports, and querying is almost always helpful even if not absolutely necessary. When you scale, you will almost certainly start needing DB-like freatures, such as multi-user concurrency and the above. > > I have also written other applications in which the decision to go to > an RDBMS was made very early, because the features clearly required it. > Not features for the future, but features for right now. > > So, Agile DOES provide guidance about when and where to use tools like RDMBSs. > > -- > Robert C. Martin (Uncle Bob) | email: uncle...(a)objectmentor.com -T-
From: Robert Martin on 26 Jan 2007 16:39 On 2007-01-26 12:44:12 -0600, Thomas Gagne <tgagne(a)wide-open-west.com> said: > The biggest difference between Martin's and my approaches in this area > is my belief the system starts with the data model and his starts with > an behavioral model. Mind you, that's not a trivial difference... Indeed not. We should debate that one day. ;-) -- 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 26 Jan 2007 16:43 On 2007-01-25 23:06:28 -0600, "topmind" <topmind(a)technologist.com> said: > I have looked at Fowler's works, and found a lot of suspicous designs. > He hates RDBMS almost as much as you. If you found a sure-shot example, > please bring it up. Neither Martin nor I hate RDBMSs. Martin's book on Patterns of Enterprise Architecture is largely about techniques for using RDBMSs in web based systems written in Java and .NET. As for "suspicious designs", I think you should point them out rather than broad brush the man's work with your incorrect assumption of his hatreds. -- 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 26 Jan 2007 16:44
On 2007-01-25 23:06:28 -0600, "topmind" <topmind(a)technologist.com> said: > Being popular is not the same as being good. Neither is being unpopular. But this conversation has left the arena of substance. -- 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� � � � � � � � ��| |