Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: topmind on 23 Jan 2007 12:39 Robert Martin wrote: > 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. This is a straw-man argument. SQL-only is not what is being compared. I *have* seen people do an awful lot of processing with just SQL. However, I don't recommend such a heavy use, though. SQL in its current form is not good enough for that (although a better relational language could be). But the amount one can use SQL (or a query language) is like a sliding scale. Nobody is recommending 100% SQL. Some UNDER-use the query language and some OVER-use the query language. OO proponents typically under-use it, preferring to use OOP programming instead. As far as where to use queries and where to use imperative code (app code), I already gave some rules-of-thumb in a nearby reply. > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: frebe73 on 23 Jan 2007 14:25 > > 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. How many getEmployeeBySomeCriteria methods do you think you will end up with in a normal payroll application? Why do you want to hide predicate logic and set operations behind a procedural interface? > In any application, OO or not, this translation must take place. Absolutely not. > There is no duplication. There is no waste. If you have a table employee and a class employee, you obviously have duplication. If you have five variants of getEmployeeBySomeCriteria, you obviously have duplication. Fredrik Bertilsson http://mybase.sf.net
From: topmind on 23 Jan 2007 16:28 frebe73(a)gmail.com wrote: > > > 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. I've noticed that us tables-heads tend to view behavior as an implimentation detail and the schema and attributes as the higher-level abstraction/model, while OO'ers tend to do the reverse. Data-centric programming tends to design domain-specific "languages" inside of tables; and procedures "carry out" the orders or logic spefied by the tables. The tables are kind of a "decision grid", and the procedures simply implement those decisions dictacted by the grid. The procedures are just an interpreter of our logic tables more or less. The categories of employees or employee roles is in the tables. The calculation sequences are in the tables (or at least can be). The mapping of the employee role categories to calculation sequences is in the tables. The code to combine all these is just carrying out the commands or logic as dictated by the tables. JOINs and predicate logic do most of the grunt work of selecting and combining these. We don't create noun taxonomies of employees nor calculations in app code. OO does the reverse. Wether one approach is inharently better or not, I cannot say with certainty. I just know that the data-centric version favors my brain because normalization is better documented and understood for tables than for programming code; and because one can use query languages, report writers, CRUD generators etc. to sift, sort, search, and view the "logic tables" just about any damned way one pleases, and thus are not at the mercy of your favorite view, Bill Gates' favorite view, etc. but MY OWN view or more importantly, a *situational* need. Programming code is not nearly as flexible, and requires reinventing a (navigational) database to get such features. All roads lead to Rome, guys. Charles Bachman would be proud of your "object browsers". I am a Frank Sanatra developer: I want to see it MY WAY! OO ain't no gimme 'dat. > Fredrik Bertilsson > http://mybase.sf.net -t-
From: Robert Martin on 23 Jan 2007 16:43 On 2007-01-22 10:29:38 -0600, JXStern <JXSternChangeX2R(a)gte.net> said: > On Sun, 21 Jan 2007 09:37:46 -0600, Robert Martin > <unclebob(a)objectmentor.com> wrote: > >> On 2007-01-14 10:49:40 -0600, JXStern <JXSternChangeX2R(a)gte.net> said: >> >>> OK, I looked up the book, it's 2002. I probably glanced at it at some >>> point. "Agile" goes back to iterative methods first popularized and >>> formalized in the late 1970s. >> >> Iterative methods have been around since the late 50s. The term Agile >> refers to a suite of practices that include iterative development. >> Other practices in the Agile suite include Test Driven Develoment, >> Refactoring, Simple Design, Pair Programming, Continuous Integration, >> etc, etc. > > I mean the important principles go back - as far as you care to trace > them, then. > > You mean, the term Agile was coined in the last few years to wrap up > these old principles and some newer ones. Yes, and surround them with an ideological framework. > >>> "Agile" has nothing to say about using >>> one tool or another, or about RDBMS, pro or con. >> >> The principles of Agile design have implications for how to treat the >> different components of systems architecture, including DBs. The term >> "pro or con" has no meaning here. > > 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. -- 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 17:38
On 2007-01-23 11:30:27 -0600, "topmind" <topmind(a)technologist.com> said: > Robert Martin wrote: >> >> 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. I quite agree. OO is just one of many potential technologies for separating concerns. It happens to be one that is both popular an effective. >> 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. Very little "additional" code. Indeed, it might even be less code since all the SQL is concentrated in one place rather than spread out and duplicated. We can argue about whether the net work is greater or less. From my point of view it is significantly less since I can forget about the SQL and Schema while dealing with the business rules and interface. > The more beurocracy > you put between the RDBMS and the app code, the more places you will > often have to change. So let's not have bureaucracy. Let's have a well defined interface that acts as a partition rather than a mediator. The partitioning of the code in the Payroll example is just that, a partitioning. There is no vast bulk of "extra code". The database code in the example is primarily concerned with generating and executing SQL. That code would have to be SOMEWHERE in the application irrespective of whether you use OO or not. > 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. Let me translate this into procedural-speak. If a new attribute or table is needed for a given calculation, then likely there will be two places in the code that need changing. The SQL, along with the code that moves the query results into convenient variables, and the app code that uses those variables. We can make sure that only one unit is changed by cramming all our code into a single unit. Clearly that's not ideal. We have to have some kind of partitioning scheme. The scheme I chose in the book was to separate code that knows about database implementation details from business rules. > Thus, wrapping is more effort: one has to make > 2 hops instead of one. Wrapping is not more effort because it always needs to be done one way or another. Either we pull the data out of queries an into objects, or we pull the data into convenient variables. > Swapping DB vendors is fairly rare. Swapping DB vendors is a TEST, not a goal. You know you have isolated the business rules from the DB implementation details if you can swap the DB. We can argue about whether or not it is wise to separate business rules from the DB implementation. In many applications this might not be the right choice. For many applications it is. There are many reasons why such a separation might be beneficial. 1. Unit tests don't need the DB. This is actually a very big deal for some applications. 2. DB code makes business rule code hard to read. This may or may not be true depending on the language and platform you are using. 3. Changes to the database and schema need to be isolated from the business rules. For example, the business rule code need not be affected by a change from embedded SQL to stored procedures. 4. Different Expertise. The folks doing dataase queries may not be the same folks who are writing the business rules. It would be nice if they could play in different sandboxes. 5. Database tools sometimes require preprocessing or postprocessing of the code. It would be nice if the business rule code were not involved in such machinations. etc. etc. > I like to spend my time on real work, not red tape. I agree. If maintaining the separation between Business Rules and Database turns into a lot of red tape, then it should be eliminated. I have certainly seen such red-tape implementations, and have gotten rid of them for that reason. Most of the time that red-tape has more to do with convoluted layering schemes and "clever" code generation techniques, than with simple partitioning. The amount of red-tape in a simple partitioning model is very limited. > I also would like to see your comments on taxonomy issues. I thought your comments were very intresting. There is indeed an argument to be made for allowing every employee to enjoy every payment scheme. Why shouldn't salaried employees be able to get commissions, or submit overtime hours? If that were a requirement, then some reworking of the payroll example would be in order. What would we need to do? We'd simply put a collection of PayClassification objects into each employee, and use the Composite pattern to treat them as a single PayClassification. Within the business rules themselves this would require no changes to any of the existing modules. The CompositePayClassification would need to be added. The individual transaction objects would then create and modify employees with the Composite object instead of with the individuals. This is simple, and keeps the code nicely partitioned. Changes to salary policy do not affect changes to hourly policy, etc. So, in fact, the "taxonomy" does not get in the way, and actually facilitates the new mode of operation while keeping the code nicely separated. -- 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� � � � � � � � ��| |