Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: Patrick May on 11 Feb 2007 08:39 "topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: >> > It is clearly false in my experience. They quite often change for >> > the same reasons. >> >> That suggests that your experience is quite limited. > > Gee, and everyone keeps telling me to shift into management because > I am "too old to continue as a developer". "Some people have twenty years of experience, others have one year of experience twenty times." >> In enterprise systems the schema can change in order to support >> other applications, due to upgrades to the COTS system that owns >> it, or for the ever popular denormalization for performance, to >> name just three. > > If it is a COTS, then usually the vendor also owns the app such that > they do most of the app changes, not you. Only if the application is being used standalone and is not extensible. In mid to large systems, neither of those criteria hold. The systems are typically modified to better meet the business needs and they are used in workflows that include several such systems (e.g. an order management system that uses CRM, billing, MRP/ERP, and others that are COTS). > Even with that, complete schema reworkings only happen about once a > decade This demonstrates your lack of experience again. A "complete schema reworking" is not required to cause problems, even small changes have ripple effects if the components are not properly decoupled. Such changes are made with every minor release, often two to four times a year. > Remember, as much as roughly 80% or more of the biz logic can be done > via nothing but queries in some systems In simple CRUD systems, yes. In the context of large, distributed, mission-critical systems, you have thus far failed to support your claim. > Further 2, I am talking about custom biz apps, not COTS. COTS will > be a bit different in that regard. I won't disagree that wrapping > may pay off more when dealing with COTS. You conveniently ignored the other two examples of schema change I provided. Anyone who has built these kinds of systems can come up with others. Your rejection of the idea that the schema and application change for different reasons is unfounded. >> Application logic changes to support the needs of the >> business, which may include the addition of new functionality based >> on the same underlying data or modification of a workflow to use >> the existing functionality, among other reasons. >> >> Neither of the preceding two paragraphs provide any new >> information to anyone who has developed large, or even mid-sized, >> systems. And before you go off on yet another tangent: Yes, there >> are occasions where the schema and application logic change for the >> same reasons. The point is that such is not always the case. > > It is a matter of frequency. My observation of probability and costs > and benefits being weighed do not favor heavy wrapping for a good > many apps. Once again, on what kind of applications do you base those observations? You constantly refer to "custom biz apps" but never define exactly what you mean by that. Every indication is that your experience is limited to CRUD systems, which will certainly lead to equally limited observations. 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: Patrick May on 11 Feb 2007 09:19 frebe73(a)gmail.com writes: >> Nice, an easy one. As I said, I'll get right on it just as >> soon as you provide some solid support for your ridiculous >> assertion that relations are the only data structure that should >> ever be used. > > First I notice that you added the word "ever" to my statement. > "Relational algebra should be used for transforming data. Relations > is the only data structures that should be used. " A distinction without a difference. They are both equally absolute (and both equally unsupported). > Second my statement is a reply to: "When SQL is embedded in other > languages, OO or procedural, the code is responsible for at least > three tasks: retrieving the data from one or more tables, > transforming the data into a format suitable for the the application > logic (variables, structures, objects, result sets, etc.)," > > As you see, the context of my statement is that SQL is already used > and somebody are retriving data from a database and transforming the > data into low-level data structures. My claim is that in this > situation it is a rather bad idea to transform the data from a high- > level structure (relations) to low-level structures. I believe your attempt to equate relations with the feel good term "high level" and all other data structures with the more negatively perceived "low level" is technically called "poisoning the well". In any case, it's a rhetorical technique, not a valid argument. You appear to continue to be claiming that there is no need for data structures other than relations. Either support or retract this claim. If you choose to support it, you will need to address all possible uses of the data retrieved from a database that any application may have. Alternatively, you could just admit that your assertion is overly broad and ridiculous on its face. 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: frebe73 on 11 Feb 2007 10:35 > > First I notice that you added the word "ever" to my statement. > > "Relational algebra should be used for transforming data. Relations > > is the only data structures that should be used. " > > A distinction without a difference. They are both equally > absolute (and both equally unsupported). No , it is not. Without the word "ever", my claim( "Relations is the only data structures that should be used") is supposed to be valid for the given context. With with extra word "ever", the statement has to be valid in any context. You may continue me asking to prove something that I don't claim, but I suggest you start to motivate you own claims. > > Second my statement is a reply to: "When SQL is embedded in other > > languages, OO or procedural, the code is responsible for at least > > three tasks: retrieving the data from one or more tables, > > transforming the data into a format suitable for the the application > > logic (variables, structures, objects, result sets, etc.)," > > > As you see, the context of my statement is that SQL is already used > > and somebody are retriving data from a database and transforming the > > data into low-level data structures. My claim is that in this > > situation it is a rather bad idea to transform the data from a high- > > level structure (relations) to low-level structures. > > I believe your attempt to equate relations with the feel good > term "high level" and all other data structures with the more > negatively perceived "low level" is technically called "poisoning the > well". In any case, it's a rhetorical technique, not a valid > argument. I see that you are more interested in word games that replying to my arguments. Do you consider structures, objects and result sets as more high-level then relations? As I have tried to explained to you before, the relational model makes a distinction between logical and physical data. Logical data is relations, and physical data is supporting data structures likes files, B-trees or hash tables, that are not visible to the user of the database. I know that you consider this as an contradication, but this is the way Dr. Codd wanted application to be decoupled from the physical implementation. By using low-level structures like lists and maps, you will couple your application to low-level implementation issues. The use of pointers between objects/ records are also a very low-level approach compared to relations. One of the main purposes with the relational model was to get rid of the pointer-hell in network databases. Now, pointer-hell is introduced again in OO applications. > You appear to continue to be claiming that there is no need for > data structures other than relations. It depends on the context. I think I have explained my statement in detail in previous posts. There are no need for transforming relational data to some other data structure that would "fit" your application better. > Either support or retract this claim. I already supported it, but you didn't seem to care to read it. You either have to object my arguments or accept them. I am still waiting for the supporting arguments or you claims... But if suspect that will continue with this word game as a silly attempt to not having support your claims. > If you choose to support it, you will need to address all > possible uses of the data retrieved from a database that any > application may have. I think this apply to the motivation of your claims too... I suggest you study som relational algebra and SQL, and you will find out that these languages are capable of much more than you could imagine. Anyway I think we could start with agree that relations could do the same thing as lists and maps. Object graphs or trees are no problem either. Why don't you use some proof by condration to prove me wrong. But I already know your answer: "You just try to put the burden of proof on me, you have to prove everything you said (spiced up by some extra words from me) before I care to support anything of what I said". > Alternatively, you could just admit that your assertion is overly > broad and ridiculous on its face. Alternatively you could just object to my arguments and start to support you own claims. PS. I noticed that you didn't object to my motivation why the rule of decoupling all SQL would cause more bloated code. Did this mean you accepted the motivation? Or does it just mean that you are much more interested in playing word games than debating the real issues? Maybe you should start asking RCM to support his claims too? After all, we are discussing his unsupporting claims in this thread. /Fredrik http://mybase.sf.net
From: topmind on 11 Feb 2007 16:06 frebe73(a)gmail.com wrote: > > I see that you are more interested in word games that replying to my > arguments. Yip, that's his game. He should have been a lawyer instead of technologist because word manipulation goes further with people than with machines, which don't understand English. -T-
From: Patrick May on 13 Feb 2007 07:51
frebe73(a)gmail.com writes: >> > Second my statement is a reply to: "When SQL is embedded in other >> > languages, OO or procedural, the code is responsible for at least >> > three tasks: retrieving the data from one or more tables, >> > transforming the data into a format suitable for the the >> > application logic (variables, structures, objects, result sets, >> > etc.)," >> >> > As you see, the context of my statement is that SQL is already >> > used and somebody are retriving data from a database and >> > transforming the data into low-level data structures. My claim is >> > that in this situation it is a rather bad idea to transform the >> > data from a high- level structure (relations) to low-level >> > structures. >> >> I believe your attempt to equate relations with the feel good >> term "high level" and all other data structures with the more >> negatively perceived "low level" is technically called "poisoning >> the well". In any case, it's a rhetorical technique, not a valid >> argument. > > I see that you are more interested in word games that replying to my > arguments. You should stand a little further from Bryce Jacobs, his tendency for projection seems to have rubbed off on you. I am merely pointing out your word games, not playing any of my own. > Do you consider structures, objects and result sets as more > high-level then relations? Do you consider a wrench to be higher level than a hammer? Your use of the terms "high-level" and "low-level" in this context is merely emotive. It doesn't reflect any meaningful concept with respect to writing quality software. Sometimes the solution calls for a structure, sometimes an object, sometimes a set of tuples, sometimes a directed graph, and sometimes other structures. Your claim that only relations should be used is ridiculous on its face. > As I have tried to explained to you before, the relational model > makes a distinction between logical and physical data. Logical data > is relations, and physical data is supporting data structures likes > files, B-trees or hash tables, that are not visible to the user of > the database. What you have failed to explain is why you think that only relations should be used. Are RDBMSs so much more complex than other software that only they require other data structures? > I know that you consider this as an contradication It's not that I consider it a contradiction, it _is_ a contradiction. You claim that only relations should be used and then immediately add "except to implement databases." By your own admission, relations are not always sufficient. 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) |