Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: topmind on 9 Feb 2007 01:33 Patrick May wrote: > frebe73(a)gmail.com writes: > > You can start with this one: > > "The database schema and the application logic change for different > > reasons. Decoupling the two minimizes the impact of those changes." I lost the context to this. It does sound like Martin's writing, however. It is clearly false in my experience. They quite often change for the same reasons. Thus, if you separate them, you often have 2 places (named units) to change instead of one, costing you and the company time and money. -T-
From: frebe73 on 9 Feb 2007 07:27 > >> >> If you can't prove it, retract it and stop making such claims. > > >> > Don't you realize that you and RCM had made a number of claims in > >> > this thread, without proving them? > > >> You be sure to point them out and I'll address any I made, > >> right after you provide some solid support for your claim that > >> relations are the only data structure that should ever be used. > > > You can start with this one: > > "The database schema and the application logic change for different > > reasons. Decoupling the two minimizes the impact of those changes." > > 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. " 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 already showed you some benefits with relations as data structures compared to common low-level structures (lists and maps). You didn't oppose the argumentation, but complained about the fact that I didn't compared every possible data structure with relations. I don't have the time to compare relations to every other possible data structure, but if you feel that you want me to compare some more data structure, feel free ask me. /Fredrik http://mybase.sf.net
From: topmind on 9 Feb 2007 16:46 Thomas Gagne wrote: > topmind wrote: > > Patrick May wrote: > > > >> frebe73(a)gmail.com writes: > >> > > > > > >>> You can start with this one: > >>> "The database schema and the application logic change for different > >>> reasons. Decoupling the two minimizes the impact of those changes." > >>> > > > > I lost the context to this. It does sound like Martin's writing, > > however. It is clearly false in my experience. > > We'll never know, though, if the report of your experience is true or > adjusted to fit your argument. If true, we won't know if perhaps it > isn't precisely because your code and schema are too tightly coupled. In my apps they are indeed often tightly coupled because I use almost as much of the DB's power and features as I can. My goal is to let the DB slave away so that I don't have to. Wanting it otherwise is like saying "I don't want my code tightly coupled to the programming language because all coupling is bad". Databases and tables can be in integral and helpful part of the app, not just a remove service. Treating it as a remote surface just puts RED TAPE in the way. Martin's code is rather red-tapish in my opinion. (Maybe you need that with a room full of stupid programmers who need walls and gates for every "hello world" they do. This is kind of a Paul Graham veiw of OO.) > > I've already given examples in other threads on how loosely-coupled > designs have allowed non-trivial DB changes without affecting code. > It's difficult to determine if your experience is out of necessity (the > solution won't permit it) or a design flaw (the design doesn't allow it). If somebody wanted to compare scientificially, either they should do a survey of change frequencies of some sort, or at least state their assumptions/givens up front and admit they are anecdotal. Martin could have said, "I my experence, the DB schemas and the application change for different reasons" instead of word it as a fact. The problem is that authors get into the habit of doing this because nobody of any authority has challenged them so far. I once talked with an author who was planning on doing a book about OOP criticism, but after seeing all the flak that came from a small artical on the subject, he pulled out. He realized criticising OO was like "cussing in church" to barrow a phrase. There is subtle censorship going on. Many people have a vested interest in OO living as long as possible and they fiercely protect the kingdom. > > -- > Visit <http://blogs.instreamfinancial.com/anything.php> > to read my rants on technology and the finance industry. -T-
From: Patrick May on 10 Feb 2007 13:17 "topmind" <topmind(a)technologist.com> writes: >> frebe73(a)gmail.com writes: >> > You can start with this one: "The database schema and the >> > application logic change for different reasons. Decoupling the >> > two minimizes the impact of those changes." > > I lost the context to this. It does sound like Martin's writing, > however. Thanks! It's mine, actually, but I appreciate the compliment. > It is clearly false in my experience. They quite often change for > the same reasons. That suggests that your experience is quite limited. 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. 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. 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 10 Feb 2007 14:25
Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > >> frebe73(a)gmail.com writes: > >> > You can start with this one: "The database schema and the > >> > application logic change for different reasons. Decoupling the > >> > two minimizes the impact of those changes." > > > > I lost the context to this. It does sound like Martin's writing, > > however. > > Thanks! It's mine, actually, but I appreciate the compliment. > > > 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". (I don't like meetings and personell management and like programming, so I'll do my best to stay.) > 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. Even with that, complete schema reworkings only happen about once a decade (and smarter vendors use views to keep as much the "schema interface" the same as possible), but busy-work from dealing with DB wrappers nearly every time you change the app, which could be monthly, weekly, or even daily. Thus, you are trading a hit every 3000 days versus once every 10 or so days. Remember, as much as roughly 80% or more of the biz logic can be done via nothing but queries in some systems (even to a degree higher than I recommend for an aging language such as SQL). SQL is just shy of Turing Complete. The queries *are* the app in such cases. 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. > > 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. Indirection is not free. Indirection is a tool to be used wisely and if not used wisely can create red-tape bloated software that takes 8 pages to do Hello World. > > Sincerely, > > Patrick > > ------------------------------------------------------------------------ > S P Engineering, Inc. | Large scale, mission-critical, distributed OO -T- |