Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: AndyW on 29 Jan 2007 23:29 On Sun, 28 Jan 2007 10:45:00 +0100, "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote: >On 27 Jan 2007 19:20:41 -0800, Daniel Parker wrote: > >> On Jan 27, 4:20 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> >> wrote: >>> On 27 Jan 2007 08:55:12 -0800, Daniel Parker wrote: >>> >>>> Operations (restriction, join, projection etc.) can be applied to relations, which produce other relations. >> >>> Which is an even better example than mine, that relations can be values (and thus objects). >>> >> A relation is a value. >> >> But are you saying that an object _is_ a value? That would be a mistake I think. One would still have a piece of data not an object. As far as I am concerned there is a specific set of criteria that one has to meet in order to define an object in the programming sense and conceptualising data as objects to me isnt one of them. Just because one has a number or a couple of letters from an alphabet or a bit of binary data that has had some human abstraction applied to it in order to give it a meaning, in my book, does not constitute object orientation. Andy
From: topmind on 29 Jan 2007 23:54 Robert Martin wrote: > On 2007-01-29 17:54:34 -0600, "topmind" <topmind(a)technologist.com> said: > > > > >> They are different approaches to very different needs. RDBs > >> store, organize, search, fetch, and process data. OO languages help to > >> organize complex software systems. > > > > Those are not necessarily mutually-exclusive. One way to manage > > "complex software" is to meta-tize much of it such the tables become a > > kind of domain-specific language such that one is "programming in the > > tables" so that one is not dealing directly with programming languages. > > Agreed! Creating DSLs in often a good approach to the problem of > complexity. Finally, we agree on something. > Using an RDB to store the DSL can also be beneficial. To > pull this off you need an engine that interprets the DSL. That engine > will be written in a programming language. OO is particularly well > suited to manage the complexity of such an engine. I disagree. If you use the DB for such, then there would be little or no need for polymorphism, and if you don't use polymorphism and don't use inheritence, then OO is not going to give much. The procedural code to process the DSL would look something like: total = 0; // initialize sql = "select * from commands order by cmd_sequence where empID =" . empID; rs = query(sql); while (row = nextRow(rs)) { // row is a map array switch on row.cmd { case "add" {....} case "subtract" {....} case "multiply" {....} etc... } // end-switch } //end-while Poly does not contribute if there is only *one* case list with such items. (I avoided C-style stupid archiac "break" syntax.) > > > Polymorphism is a smell of hardwiring going on. > > Silly boy. Polymorhism is the smell of dependencies breaking. A non-commital buzzword based on your personal interpretation of likely change patterns. We've been over that already. You offered no objective measure of dependency. > > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: Daniel Parker on 29 Jan 2007 23:58 On Jan 29, 11:29 pm, AndyW <a...(a)b.no.email> wrote: > >On 27 Jan 2007 19:20:41 -0800, Daniel Parker wrote: > > >> But are you saying that an object _is_ a value? > That would be a mistake I think. One would still have a piece of data > not an object. As far as I am concerned there is a specific set of > criteria that one has to meet in order to define an object in the > programming sense and conceptualising data as objects to me isnt one > of them. Do you think that these criteria can be formalized, say, along the lines of Abadi and Cardelli "A Theory of Objects"? My reading of Abadi and Cardelli suggests that it omits a number of criteria that some consider features of OO. For example, the term behavior doesn't appear, the word "dependency" is mentioned only in relation to the order in which the chapters should be read, and getter and setter methods are used in examples (it's hard to see how to distinguish formally between, on the one hand, getters and setters, and on the other, any other kind of accessors and mutators, so why not?) Daniel
From: Robert Martin on 30 Jan 2007 00:03 On 2007-01-27 00:39:50 -0600, frebe73(a)gmail.com said: >>>> Then I would hide that SQL statement behind an interface so that the >>>> rest of my application was unaware of it. >>> And the benifits are? > >> 1. Separation of concerns makes both sides more readable. > > Do you have something to back this up? I think it's self evident: 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? > >> 2. Both sides can be tested independently of the other. > > I don't understand why OO people insits testing their application > without the database. Because it's faster. Because we can control the data more easily. Because the tests can be kept independent (no accumulation of data from one test to the next.) Because we can run the tests on our local laptops without a database. Because we can run the tests before we have chosen a database. Because we can simulate *any* kind of malfunction. I could go on... > Most business applications are a rather thin > layer babysitting a database. Testing that layer without the database > is rather useless. That may be true for some tiny little applications. It is certainly not true for small, moderate, or large systems. > >> 3. Either side can be deployed independently of the other (meaning at >> differen times) allowing me to fix bugs, or add features, to one side >> without redeploying the other. >> etc. > > Views (and stored procedures) are deployeable indepentently of the > application. But I not sure I understand why deploying different parts > of the application indepently is so very important. 1. I can fix a bug in one component without having to redeploy the whole system. 2. I can sell different components of the system to different customers. 3. I can create different configurations of the system by mixing and matching different components. > >>> There is no need for passing data structures around the application. >>> Relations are the only needed data structures. (Sometings performance >>> issues might force you to use low-level collection classes likes arrays >>> and hastables, but this is normally not the fact for business >>> applications.) The application should ask the database for the needed >>> data, using set theory and predicates, when the data is needed, not >>> before. >> I agree with everything you say there. > > Ok, so you finally agree that using classes as data structures is a bad > idea? Isn't "finally" a wonderful word. Isn't it great to be able to throw that word into an argument just to make is seem like you've made a point. Isn't it great that you've finally stopped beating your wife. 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. > >> An object is a relation, and it is very convenient to use. Oh! There it is! > >> 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. 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. -- 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 30 Jan 2007 00:07
On 2007-01-27 11:05:57 -0600, frebe73(a)gmail.com said: > Are really test performance a factor that should have impact on how to > design software? Absolutely! Test performance is critical to software design. If tests are slow, they simply don't get run often enough. If tests are fast, they can be run every few minutes. When tests can be run every few minutes, bugs simply don't accumulate. Inadvertent breakage becomes non-existent. And the code becomes remarkably flexible (because you aren't afraid to change it). Oh yes; the tests must be fast! And the design of the system must support fast tests. Oh yes! -- 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� � � � � � � � ��| |