Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: Robert Martin on 23 Jan 2007 20:34 On 2007-01-23 15:28:32 -0600, "topmind" <topmind(a)technologist.com> said: > OO does the reverse. Wether one approach is inharently better or not, I > cannot say with certainty. That is the most mature statement I've seen you make. In many ways OO is the reverse of procedural programming. In procedural code dependencies flow in the direction of control. In OO code dependencies flow against the direction of control. In procedural code functions can be added to existing data structures without changing the data structures. In OO code data structures can be added to existing functions without changing the functions. People who are used to working with tables and data often build DSLs out of the data and write programs using those higher level data concepts. People who are used to OO often write DSLs out of objects and write programs using those higher level object concepts. One way is not better than the other; but BOTH ways are better than just one. -- 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 20:36 On 2007-01-22 09:45:54 -0600, "Daniel Parker" <danielaparker(a)gmail.com> said: > > lilburne wrote: >> Robert Martin wrote: >> >> Hasn't Payroll been solved? > > I think so. I think you buy them these days. I don't know of any > companies that would write their own payroll system anymore. Remarkably, a lot do. Ironically, COTS software is sometimes more painful to adapt to your needs than writing the whole applciation from scratch. -- 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: topmind on 24 Jan 2007 00:04 On Jan 23, 5:34 pm, Robert Martin <uncle...(a)objectmentor.com> wrote: > On 2007-01-23 15:28:32 -0600, "topmind" <topm...(a)technologist.com> said: > > > OO does the reverse. Wether one approach is inharently better or not, I > > cannot say with certainty. > >That is the most mature statement I've seen you make. > > In many ways OO is the reverse of procedural programming. > > In procedural code dependencies flow in the direction of control. > In OO code dependencies flow against the direction of control. > > In procedural code functions can be added to existing data structures > without changing the data structures. > > In OO code data structures can be added to existing functions without > changing the functions. > > People who are used to working with tables and data often build DSLs > out of the data and write programs using those higher level data > concepts. I assume that DSL stands for "domain-specific language". Note that one can also write DSL with functions also. Thus, one is not limited to just DSL's using tables. > > People who are used to OO often write DSLs out of objects and write > programs using those higher level object concepts. > > One way is not better than the other; but BOTH ways are better than just one. But there are no clear, consensus criteria for when to use one over the other. People's selection seems to be a personal preference. I am afraid that the rules of thumb you suggest cannot be considered in isolation such that one is weighing many factors, and I tend to disagree with the weights you assign to some factors. > -- > Robert C. Martin (Uncle Bob) | email: uncle...(a)objectmentor.com -T-
From: frebe73 on 24 Jan 2007 02:35 > > How many getEmployeeBySomeCriteria methods do you think you will end up > > with in a normal payroll application? > >I imagine it will be quite a few, Only a few ways of fetching employees? By name, by employment no, by SSN, by department, by city.... But I guess that you will do it the OO way, fetching all employees and select the instances you really want, by traversing them and call a matcher/filter function. Performance is a secondary issue. > though fewer than the number of > embedded SQL statements that would exist if I did not put them behind > an interface. What is the purpose with putting a statement like "select salary from employee where SSN=?" behind an interface? You are substituting one one-liner with another one-liner that needs an additional implementation. > > Why do you want to hide predicate > > logic and set operations behind a procedural interface? > > I don't. I want to give the operations meaningful names. For example: > > findEmployeesEligibleForRetirement This is neither predicate logic nor a set operation. You have given an example of a function, which indeed is very useful (also together with predicates). > is more evocative than a long SQL statement that doesn't mention > retirement at all. Think of the functions as compilable comments that > describe what the SQL beneath them is intended to do. A much better idea would be to create a view EmployeesEligibleForRetirement. Views are much more flexible than functions, because they can be combined together in other set operations and logic statements. You might for example join this view with the SalarayPayment relation. If you embedd the statement inside a function, you don't have that kind of flexibility. > This has the additional benefit that when the eligibility rules change, > the callers of findEmployeeEligibleForRetirement() will be unaffected. The same benefit exists if you create a view. > >> In any application, OO or not, this translation must take place. > > > Absolutely not. > > The data is on the disk. This is a common statement from people that lacks education about modern databases. They think that the SQL statement "select mycol from mytable", will cause the database to read something from disk. In a well-tuned database, the data will most likely already be in RAM. > It must be translated into some kind of > TableRow structure or similar. Then it must be unpacked from that > structure into something convenient for the application to use. > > Now it is entirely possible that the application will simply index into > the TableRow structure every time it wants to access the data; but even > that is an *implicit* translation into a more convenient form. You don't need a TableRow instance, just use select/fetch into. And if you still prefer a result set, this class is generic. You don't have to write it yourself. > > If you have a table employee and a class employee, you obviously have > > duplication. >You have the same "duplication" if you have a table "employee", and a > set of convenient variables used to hold parts of one of the rows from > time to time. You even have it if you have a TableRow structure that > holds the employee row. TableRow is a generic class, employee is not. > > If you have five variants of getEmployeeBySomeCriteria, > > you obviously have duplication. >I don't see that at all. The five functions may simply call a more > general function passing in specific parameters. Why do you want the five functions in the first place? If you have general function, why not use that one from the beginning? Fredrik Bertilsson http://mybase.sf.net
From: frebe73 on 24 Jan 2007 07:10
> > 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. > > That particular implementation issue contains an entire engineering > discipline and science. One could also say that more than 90% of the employees in the world are still getting paid by the manual system you described above. I am not saying that behavior is not needed, I am only opposing your statement that "we are being paid to create payroll behaviors". We are getting paid to produce payroll data (paychecks). The customer doesn't care so much about how (behavior) it is done. The most stupid thing about OO is data hiding. Why should we hide the stuff that are most important of all? Fredrik Bertilsson http://mybase.sf.net |