Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: frebe73 on 27 Jan 2007 01:39 > >> 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? > 2. Both sides can be tested independently of the other. I don't understand why OO people insits testing their application without the database. Most business applications are a rather thin layer babysitting a database. Testing that layer without the database is rather useless. > 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. > > 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? > 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. Fredrik Bertilsson http://mybase.sf.net
From: Dmitry A. Kazakov on 27 Jan 2007 04:05 On 26 Jan 2007 17:01:55 -0800, Daniel Parker wrote: > On Jan 26, 4:37 pm, Robert Martin <uncle...(a)objectmentor.com> wrote: >> On 2007-01-26 11:42:52 -0600, freb...(a)gmail.com said: >>> 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. An object is a relation, and it >> is very convenient to use. >> > "an object is a relation" ??? A relation in relational theory, > consisting of a set of tuples, is roughly analogous to the idea of a > table, consisting of a list of rows. Relation is an operation over objects in a model which would implement RA. But also a relation can be an object in some higher-level model. Even SQL has that level, consider CREATE TABLE as an operation over relations as object. The advantage of OO is that you can mix models more freely. For that matter RA is much more limiting framework. Just consider expressing arithmetic, image processing, or for that matter CREATE TABLE in terms of RA! I cannot tell if OO [~ subtyping relation and dispatch] could be represented in RA. (The reverse is clearly possible) Which would make Robert's argument *formally* correct. But in spirit it is, being old known: "we all are Turing-complete, guys." -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Patrick May on 27 Jan 2007 09:43 frebe73(a)gmail.com writes: >> >> 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? Experience. Treating the SQL code and stored procedures as services used by the non-relational (OO, procedural, functional, or what have you) code makes both simpler in terms of the number of concepts being managed, shorter, and therefore more readable relative to the alternative. When SQL is mixed with non-relational code, anyone reading the code has to change context repeatedly from database access to translation to application logic. This is less readable. >> 2. Both sides can be tested independently of the other. > > I don't understand why OO people insits testing their application > without the database. 1. It's faster, which means more tests get run, which means higher quality. 2. The database schema and the application logic change for different reasons. Decoupling the two minimizes the impact of those changes. 3. The database isn't always available to application developers, particularly when working remotely or off the network. (While it is possible to install a subset of the database on a laptop, it's much easier to simply mock it out.) > Most business applications are a rather thin layer babysitting a > database. Do you have something to back this up? ;-) Seriously, you seem to be using "business application" as a synonym for CRUD application. This makes sense if you agree with Bryce's recent claim that Eclipse is "systems software", but it doesn't reflect what I consider business applications. Do you consider telco OSS/BSS systems to be business applications? Trading systems? Order management systems? I've worked on all of these relatively recently, they all make use of an RDBMS, but by no means are they a thin layer babysitting it. >> 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. It is absolutely essential in large, or even medium-sized systems, both in development and deployment. Maintainability and extensibility are core non-functional requirements. The financial impact and risk to the business of "Shut down everything and reinstall." is not a viable mechanism for meeting those NFRs. Regards, 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: Patrick May on 27 Jan 2007 10:46 "topmind" <topmind(a)technologist.com> writes: > Robert Martin wrote: >> Tsk tsk. More disparagement, and even a bit of elitism! ("You >> OO'ers." As if there were some kind of unholy alliance or shadowy >> cabal!) > > What term would you prefer? I suggest "developers who understand and have experience with multiple paradigms and who therefore can make the appropriate engineering trade-offs to achieve their customers' goals and provide the maximum business value given the specific problem domain and context." You could shorten that to "well-rounded programmers" if you like. I don't know anyone who understands object-orientation who also insists that it is the one true and only approach to use in all situations. That "one trick pony" attitude seems to be prevalent only among those who know only one trick. >> We OO'ers live in a world where we need to deploy systems in pieces >> and on different schedules. > > That is why us p/r-ers split things up into "task" modules where > each task is mostly connected only via the tables. This approach is not unique to nor was it invented by procedural or relational programmers. It is a standard design technique used in a variety of paradigms. See message-oriented middleware, SOA (Jini in particular), and even CORBA for examples. 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: Daniel Parker on 27 Jan 2007 11:55
On Jan 27, 4:05 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > Relation is an operation over objects in a model which would implement RA. I don't know what that means. In RA, a relation is defined as a set, whose members are tuples. Operations (restriction, join, projection etc.) can be applied to relations, which produce other relations. Daniel |