Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: topmind on 22 Jan 2007 17:04 lilburne wrote: > topmind wrote: > > lilburne wrote: > >> Robert Martin wrote: > >> > >>> On 2007-01-13 17:00:24 -0600, JXStern <JXSternChangeX2R(a)gte.net> said: > >>> > >>>> Page 351, second paragraph: "Instead of starting with the data of the > >>>> system, let's start by considering the behavior of the system. After > >>>> all, it is the system's behavior that we are being paid to create." > >>>> > >>>> Says who? > >>> > >>> Says me! ;-) The problem being discussed is Payroll. If we are > >>> writing a payroll application we are being paid to create payroll > >>> behaviors. > >>> > >> > >> Hasn't Payroll been solved? I thought getting paid was one of the first > >> things that Software Engineers and Consultants, irrespective of > >> methodology, had got bug free. > > > > I think the rules and laws keep changing and are often State-specific. > > Anyhow, such is used as a training example regardless of whether there > > are off-the-shelf versions of it. > > > > Hmmm! But shouldn't a Agile practitioner advocate buying in? An interesting question. If buying off-the-shelf is the simplest solution, perhaps they would. However, how do you know if the product fits if you don't *yet* have the requirements? Requirements gathering up-front generally is not considered agile. I would suggest asking an Agile movement proponent. -T-
From: Robert Martin on 23 Jan 2007 10:22 On 2007-01-21 13:59:25 -0600, "topmind" <topmind(a)technologist.com> said: > Isolation creates duplication of concepts and can make it more > difficult to use the existing power and abilities of RDBMS. Most of the > code in your book is WASTED on translating back and forth between two > medium-to-high-level concepts: OO and relational. It is like spending > effort translating between Japanese and Spanish and back rather than > get anything real done. The payroll system in the book is partitioned into code that knows about the DB schema, and code that does not. The dividing line is a set of interfaces that translate high level concepts like "GetEmployee" into appropriate SQL. To the left of the interfaces the code deals with Employees. To the right the code deals with SQL, tables, rows, and columns. In any application, OO or not, this translation must take place. All we have done with the code in the book is to assign a place for that translation. There is no duplication. There is no waste. There is simply a separation of concerns. Those concerns would exist regardless of whether they were separated or not. -- 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 23 Jan 2007 10:26 On 2007-01-21 12:04:10 -0600, frebe73(a)gmail.com said: > Payroll behavior is producing a payment file to the bank, using data > supplied by employees and adminstrators. The data is the important > thing. Behavior is only the method of transforming data. Like many > other business applications, it is all about providing information or > data to different actors. The behavior of the application is low-level > stuff that is not important on higher abstractation levels. I suggest you test your hypothesis by creating a personnel database for IBM and then writing the paychecks by hand. You will be allowed to type SQL commands at the terminal to access the database. You will also have the tax code for all the states and the federal government, as well as all the insurance codes, union contracts, etc. You should be able to write the paychecks easily with all that information since there is not much behavior in the system. -- 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: frebe73 on 23 Jan 2007 11:04 > > Payroll behavior is producing a payment file to the bank, using data > > supplied by employees and adminstrators. The data is the important > > thing. Behavior is only the method of transforming data. Like many > > other business applications, it is all about providing information or > > data to different actors. The behavior of the application is low-level > > stuff that is not important on higher abstractation levels. > > I suggest you test your hypothesis by creating a personnel database for > IBM and then writing the paychecks by hand. You will be allowed to > type SQL commands at the terminal to access the database. You will > also have the tax code for all the states and the federal government, > as well as all the insurance codes, union contracts, etc. You should > be able to write the paychecks easily with all that information since > there is not much behavior in the system. The paychecks are a data structure. How they are produced and how they are communicated to the receiver is just a low-level issue. As you describe above, a payroll system may be implemented without use of computers. On a very hight abstractation level we can describe the requirements of the system by defining the data model for the input data and the output data, and data derivation rules. If we choose to use computer software to implement it, is an implementation issue. Fredrik Bertilsson http://mybase.sf.net
From: topmind on 23 Jan 2007 12:30
Robert Martin wrote: > On 2007-01-21 13:59:25 -0600, "topmind" <topmind(a)technologist.com> said: > > > Isolation creates duplication of concepts and can make it more > > difficult to use the existing power and abilities of RDBMS. Most of the > > code in your book is WASTED on translating back and forth between two > > medium-to-high-level concepts: OO and relational. It is like spending > > effort translating between Japanese and Spanish and back rather than > > get anything real done. > > The payroll system in the book is partitioned into code that knows > about the DB schema, and code that does not. The dividing line is a > set of interfaces that translate high level concepts like "GetEmployee" > into appropriate SQL. To the left of the interfaces the code deals > with Employees. To the right the code deals with SQL, tables, rows, > and columns. > > In any application, OO or not, this translation must take place. All > we have done with the code in the book is to assign a place for that > translation. First off, this could be done without OOP. We could have functions that wrap the SQL. Thus, it is not really an OO-specific thing. > > There is no duplication. There is no waste. There is simply a > separation of concerns. Those concerns would exist regardless of > whether they were separated or not. It is additional code and likely additional work. The more beurocracy you put between the RDBMS and the app code, the more places you will often have to change. For example, if a new attribute or table is needed for a given calculation, then likely there will be two 2 units that need changing: the SQL along with the SQL wrapper's interface, and the app code that uses it. However, if the SQL was together, then only one unit needs changing. Thus, wrapping is more effort: one has to make 2 hops instead of one. These kinds of changes can and do happen quite often. Swapping DB vendors is fairly rare. Thus, you are paying a nearly GUARENTEED indirection tax of about 25% on on-going code maintanence in order to prevent a roughly once-per-10-year event, and such effort is only about a 10-day effort on medium projects (if you combine the testing with general new-version testing). Thus, over a 10-year period, the heavy wrapping may cost at least 3 hours a week, adding up to more than 1,000 hours in 10 years. This to prevent an 80-hour DB swap effort?[1] One would have to swap vendors roughly every 18 months to break even! The economic calculatioins are just plain against this in most custom application shops. It just does not add up. My version of your app would be roughly 1/2 to 1/4 the same amount of code. Shorter code in general is usually easier to learn, modify, test, understand, read, and debug. Your code is full of "red tape". It is mostly martialing stuff back and forth between instantiations and interfaces istead of doing domain-related calculations. It smells of a programmer jobs program better than any spend-happy liberal could ever pull off. (I shouldn't mind from my perspective, but one does get bored dealing with bloated red-tape code. I like to spend my time on real work, not red tape.) I also would like to see your comments on taxonomy issues. (The SQL-wrapping issue has been beaten to death on comp.object anyhow.) Excerpt from my critique: (begin quote) Page 352 and 353: Figure 26-1 and Figure 26-2 Martin commits a common OO mistake of making a hierarchy of "employee types", or at least "payment types" (hourly, commissioned, and salaried). "Types" are often a poor modeling decision in business applications because they cannot handle orthogonal traits very well. Martin gives tons of lip service about making applications easier to change without lots of code overhaul. However, hierarchical OO classes are expensive to de-hierarchy. In fact, I've witnessed first-hand an actual scenario that busts Martin's hierarchy. I've worked at a place where it was decided that any employee can receive sales bonus. If they sold the company's products to their neighbors or friends, they qualified for commissions. We live in a heavily sells-oriented capitalist society, so preparing for such a situation should be a no-brainer. If you look at my schema below, you will notice that there is nothing that forces a mutually-exclusive choice of "payment types". The equivalent of Martin's 3 classes is driven mostly by the "empRates" table. If they are an hourly employee, then they have a corresponding hourly rate row in the table. If they are salaried, then they have a monthly rate (per specifications on page 350). If they get a sales commission(s), then the commission rate(s) are also there. We are making the design assumption that they are not necessarily mutually exclusive. You may ask what keeps somebody from being both an hourly and a salaried (monthly) employee. If such combinations are not allowed, then it can be prevented via data entry validation and/or database triggers. The point is that we are not hard-wiring the allowed or disallowed combinations into our basic design to give us feature flexibility. Validating such combinations is treated also as mere data configuration issue, and not a large-scale code feature. (End Quote -- yuk, I need to rework some of my writing on that website.) [1] If one uses features that are very vendor-specifc, then DB vendor swapping can take much longer. However, finding new-vendor ways to do things the prior way is still going to be needed regardless of wether you wrap or not. It is not effort wrappers save. Swapping in general won't be free even under wrapping, so I may have understated my point by not "charging" the wrapped version for swap hours. > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -t- |