Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: frebe73 on 30 Jan 2007 09:34 > > 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. > Such functions are illegal and would result in prosecution. You really > do need to keep up with employment law. Which function is illegal in which country? What is your point? Are you trying to say that it is illegal to find employees in many different ways? Do you want more examples? Or...? Fredrik Bertilsson http://mybase.sf.net
From: frebe73 on 30 Jan 2007 11:41 On Jan 30, 5:22 pm, lilburne <lilbu...(a)godzilla.nospam.net> wrote: > freb...(a)gmail.com wrote: > >>>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. > > >>Such functions are illegal and would result in prosecution. You really > >>do need to keep up with employment law. > > > Which function is illegal in which country? What is your point? Are > > you trying to say that it is illegal to find employees in many > > different ways? Do you want more examples? Or...? > For what legal reason would you want to select employees based on age? > Certainly not for decision making on staff reductions. Read the text above again more carefully. There are three different examples. For what reason might the manager want to know employees having 50 year birthday in the near feature? It's up to you to guess. But I don't think it will start any prosecutions anyway.... Fredrik Bertilsson http://mybase.sf.net
From: frebe73 on 30 Jan 2007 14:52 > retirableEmployees = findAllEmployeesEligibleForRetirement(); > foreach e in retireableEmployees > e.sendLetter(retirementOptions); > > ======== > > List<Employee> findAllEmployeesEligibleForRetirement() { > DataRows rows = sql("Select * from employees where DOB>1952 and > salary > 90000 and ...;"); > return rowsToEmployees(rows); > > } > > ====== > > In both cases the code is easier to understand than the following: > > DataRows rows = sql("Select * from employees where DOB>1952 and > salary > 90000 and ...;"); > List<Employee> employees = rowsToEmployees(rows) > foreach e in employees > e.sendLetter(retirementOptions); > > In this latter code some of the intent has been lost. Why ware we > sending this particular set of employees the retirement options letter? > Are they eligible, pre-eligible, overdue for retirement? What? Only if you continue to ignore the existence of views. I think this is more readable: employees = select id from EmployeesEligibleForRetirement while (hasNext(employees)) { fetch employees into employeeid e.sendLetter(employeeid) } > Did you clip the part where I said that objects were relations? Yes, I > agree that relations are the only needed data structures. I happen to > like passing them around as objects. It's so much more convenient than > passing them around as table rows, once they've been extracted from the > database. If you select the data when you need it, there are no need for passing data structures around the application. > >> An object is a relation, and it is very convenient to use. > >> From http://en.wikipedia.org/wiki/Relational_model: > > "A relation is defined as a set of n-tuples". Do you claim that "an > > object is defined as a set of n-tuples". (Or maybe you claim that an > > object is one n-tuple?) How do you apply joins, projections and > > selections to objects? Now you are trying to do the same as Lahman: > > After realizing that set operations and predicate logic are superior to > > the network model, you are trying to hijack the relational model. > > I don't do joins on objects (usually). I let the DB handle all that > work. But when you apply relational algebra to objects, how do you do? > And then I load the tuples into a nice convenient object and > pass them around to the business rules, and to the user interface, etc. You seem to like to pass data around. Fredrik Bertilsson http://mybase.sf.net
From: Patrick May on 30 Jan 2007 18:32 "topmind" <topmind(a)technologist.com> writes: > Robert Martin wrote: >> Anyway, I'm not talking about ORM necessarily. My point is that >> relational databases play very nicely with OO languages. I've seen >> this many times. There are books and articles published about the >> techniques and patterns that can be used. And virtually every >> major website on the net makes use of the two. >> >> Are there problems marrying the two? Certainly. But mostly those >> problems come from the misaprehension that there is some kind of >> overlap between their functions. When you realize that RDBs and OO >> are different tools that solve different problems, you find that >> they work quite nicely together. > > 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. That's a positive claim. Prove it. Let's see your implementation. 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: topmind on 30 Jan 2007 18:53
On Jan 30, 3:32 pm, Patrick May <p...(a)spe.com> wrote: > "topmind" <topm...(a)technologist.com> writes: > > Robert Martin wrote: > >> Anyway, I'm not talking about ORM necessarily. My point is that > >> relational databases play very nicely with OO languages. I've seen > >> this many times. There are books and articles published about the > >> techniques and patterns that can be used. And virtually every > >> major website on the net makes use of the two. > > >> Are there problems marrying the two? Certainly. But mostly those > >> problems come from the misaprehension that there is some kind of > >> overlap between their functions. When you realize that RDBs and OO > >> are different tools that solve different problems, you find that > >> they work quite nicely together. > > > 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. > > That's a positive claim. Prove it. Let's see your > implementation. First I wish to settle the wrap/don't-wrap issue, as that is somewhat orthogonal to OO versus p/r. Otherwise you will just say, "Yours is smaller because he wrapped and you didn't." > > Sincerely, > > Patrick > -T- |