Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: Robert Martin on 26 Jan 2007 17:01 On 2007-01-25 23:12:11 -0600, "topmind" <topmind(a)technologist.com> said: > > Robert Martin wrote: >> On 2007-01-24 06:10:30 -0600, frebe73(a)gmail.com said: > >> >> (sigh). *information* hiding means hiding the *implementation* of data >> and behavior. BTW, I think "information hiding" was coined by Dave >> Parnas in 1971 long before OO was popular. >> (http://www.acm.org/classics/may96/) > > Again again again, a RDMBS is *not* an "implementation" anymore than > Java or C# is. Java and C# are implementation languages. The dichotomy between implementation and abstraction is recursive. One layer's abstraction becomes the next layers implementation, ad infinitum. You are correct that at one level an RDMBS is not an implementation -- that it is the abstraction. An the next level up, there are abstractions that supercede it, and it has become the implementation. For example the function: findAllEmployeesEligibleForRetirement() is an abstraction that can be implemented with a suitable SQL statement. Yet that SQL statement is, itself, and abstraction that is implemented by the database engine, which is itself an abstraction implemente dy lower level drivers, which are themselves abstractions implemented by... > You OO'ers keep claiming that RDBMS are "only low-level > persistence", but it is simply not the case. Maybe to OO programs they > are because OO programs want to take structure-handling work away from > the database and reinvent it themselves (in an inconsistent and 60's > zombie navigational pointer-like way.) 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!) We OO'ers are not trying to take anything away from SQL or DBs or anything else. We OO'ers live in a world where it is impractical to write whole enterprise applications in SQL (or any other 4GL). We OO'ers live in a world where we need to deploy systems in pieces and on different schedules. So we use languages (like Java, C#, Ruby, etc.) that support those abilities. We want to make the best use of RDBs that we can, but we also have to bind the RDBs to our world and treat them as components rather than as application lanuages. -- 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: topmind on 26 Jan 2007 19:28 Robert Martin wrote: > On 2007-01-25 23:12:11 -0600, "topmind" <topmind(a)technologist.com> said: > > > > > Robert Martin wrote: > >> On 2007-01-24 06:10:30 -0600, frebe73(a)gmail.com said: > > > >> > >> (sigh). *information* hiding means hiding the *implementation* of data > >> and behavior. BTW, I think "information hiding" was coined by Dave > >> Parnas in 1971 long before OO was popular. > >> (http://www.acm.org/classics/may96/) > > > > Again again again, a RDMBS is *not* an "implementation" anymore than > > Java or C# is. > > Java and C# are implementation languages. > > The dichotomy between implementation and abstraction is recursive. One > layer's abstraction becomes the next layers implementation, ad > infinitum. > > You are correct that at one level an RDMBS is not an implementation -- > that it is the abstraction. An the next level up, there are > abstractions that supercede it, and it has become the implementation. > > For example the function: findAllEmployeesEligibleForRetirement() is > an abstraction that can be implemented with a suitable SQL statement. > Yet that SQL statement is, itself, and abstraction that is implemented > by the database engine, which is itself an abstraction implemente dy > lower level drivers, which are themselves abstractions implemented by... Well, the appropriate level at which to wrap is taken up in a nearby reply. > > > You OO'ers keep claiming that RDBMS are "only low-level > > persistence", but it is simply not the case. Maybe to OO programs they > > are because OO programs want to take structure-handling work away from > > the database and reinvent it themselves (in an inconsistent and 60's > > zombie navigational pointer-like way.) > > 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? "OOP Proponents" takes too long to type. OO'ers is just a shortcut for that. > > We OO'ers are not trying to take anything away from SQL or DBs or > anything else. We OO'ers live in a world where it is impractical to > write whole enterprise applications in SQL (or any other 4GL). But often a good portion of it *can* be, especially with good schemas. > 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. (Nimble table tools made such even easier, but those fell out of favor when OO hype killed their sells.) In fact, this allows people to use different languages for the same application. (I don't recommend it, but p/r makes it easier than OO does.) A big soup of schemas is easier for most to grok than a big soup of OO-classes (at least they are for me). This is because schemas are more compact, more meta-able and query-able, verbs are not mixed with nouns, and there are more consensus guidence rules for rdbms. > So we use languages (like Java, C#, Ruby, etc.) > that support those abilities. We want to make the best use of RDBs > that we can, but we also have to bind the RDBs to our world and treat > them as components rather than as application lanuages. No, you don't "have to". You choose to because you seem afraid of RDBs. (I agree that there are cases where the DBA is stingy or stupid, but that is mostly a political or product design issue.) If you embrace relational and "surf" on it, life is smoother than handling it thru HAZMAT suits. > > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: Daniel Parker on 26 Jan 2007 20:01 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: > Anyone who would rather read a whole table into memory and then do a > linear search through it rather than use a select statement is either > working in a very constrained or highly specialized environment, or > there is something wrong with them. Hmmm ... whatever happened to your idea of using arrays of interconnected data structures in 100 gigs or so of non volatile RAM, in preference to RDBMS? > I am quite happy to use SQL to fetch my data, and I don't mind making > heavy use of the set algebra and relational calculus that SQL affords. > However, I want to separate that part of the application from other > parts of the application (such as presentation, and business rules) > using OO technology. Agreed. > > > You claim that it is possible to only have a few number of > > getEmployeeBySomeCriteria methods with optimized SQL statements for > > every different way you might need to fetch employee data? That should > > only be possible for rather small applications.If you look up at the top of this post you will see that I wrote "quite > a few". That's a colloquialism that means: "very many". > Agreed (in the context of a Java or C# style application) > > > 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. That sounds like you are equating object approaches with Topmind's table approaches :-) Best regards, Daniel Parker http://servingxml.sourceforge.net/
From: topmind on 26 Jan 2007 22:28 Robert Martin wrote: > On 2007-01-25 22:42:58 -0600, "topmind" <topmind(a)technologist.com> said: > > > At least I entertain the possibility that tables are a subjective > > preference. > > Then you should also entertain the possibility that objects and RDBs > can be used synergistically. I am not saying it can't happen, only that nobody has *shown* it happening. OO and RDB's seem to overlap too much. They are different approaches to fairly similar needs. I also entertain the possibility of alien saucers. However, until one lands on the whitehouse lawn in front of CNN, I remain skeptical. > > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: AndyW on 27 Jan 2007 00:08
On 25 Jan 2007 20:42:58 -0800, "topmind" <topmind(a)technologist.com> wrote: > >Robert Martin wrote: >> On 2007-01-23 18:11:25 -0600, "topmind" <topmind(a)technologist.com> said: >> >> >> We can argue about whether the net work is greater or >> >> less. From my point of view it is significantly less since I can >> >> forget about the SQL and Schema while dealing with the business rules >> >> and interface. >> > >> > SQL = biz logic. >> >> Here's a simple business problem for you to code in SQL: >> http://bossavit.com/cgi-bin/dojo.pl?HarryPotterKata > >It looks like one of those programming contest puzzles, kind of like >Towers of Hanoi. I'll perhaps consider it, but after we finish with >payroll stuff. > >> >> > ...repetition of claim does not make it true... >> >> I'm glad you finally agree. >> >> > Those who know how to use SQL and RDBMS effective can >> > shorten and simplify code because OO is crappy and inconsistent at >> > collection handling and meta-tizing attribute management. >> >> Those who know software engineering know how to use SQL and RDBMS and >> OO together to create the best systems. > >Those who know software engineering either admit something is a >subjective personal preference when it is, OR offer CLEAR evidence of >why OO makes it better and don't just use the single change scenario >favored by OO. There are two examples I like to use, one applies to SQL/Procedural and the other applies more to OODB/OO. The scenario works best if one imagines one is developing a solution for a medium sized mobile telco with a subscriber base of about 80 million connections. I would suggest the FindCustomer architecture pattern is ideal for the SQL environment because it is in effect a batch operation (as compared to the next example) of structured data. The second is that of a real time rating and billing solution for mobile calls (from CDR generation to the application of plans, subscriptions, specials etc) and I think this example is more suitable to an Object Oriented environment (including DB) because apart from being in real time, works mainly with a non-structured data environment. Andy |