Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: AndyW on 1 Feb 2007 03:23 On 31 Jan 2007 23:05:14 -0800, "topmind" <topmind(a)technologist.com> wrote: > >Robert Martin wrote: >> On 2007-01-29 22:54:20 -0600, "topmind" <topmind(a)technologist.com> said: >> >> > 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.) >> >> Consider this: >> >> sql = "select * from commands order by cmd_sequence >> where empID =" . empID; >> rs = query(sql); >> while (cmd = nextCommand(rs)) { // row represents a command object >> cmd.execute(); >> } //end-while > > >Viola, what I call a Control Table! > >However, in practice they are usually not regular enough to do it that >way. The actual IF statements tend have some interweaving. It does not >buy us much putting it in tables in most cases. More on this below. > >"nextCommand"? That does not seem necessary. We could use the same >"nextRow" function. > That bit of code would be a lot simpler and execute much faster if it was written in COBOL. Andy
From: topmind on 1 Feb 2007 12:12 Robert Martin wrote: > On 2007-01-29 23:46:40 -0600, "topmind" <topmind(a)technologist.com> said: > > > > > Robert Martin wrote: > >> On 2007-01-28 11:41:50 -0600, frebe73(a)gmail.com said: > >> > >>> OO people claim that OO can be used for everything. So why don't you > >>> use a OODBMS? What are the benefits with SQL databases that makes you > >>> to use them instead? > >> > >> I think that time has shown that OODBMS has been a dead end. The > >> arguments you relational guys have been making about RA have proven > >> correct, and the industry has almost completely sided with you. Oh I > >> know a few OODBMS hold-outs; but not many. The technology may make a > >> comeback one day when RAM storage becomes cheaper than disk. We'll see. > > > > Why would that change anything? One can make the RAM/Disk difference > > transparent. In fact, caching and virtual memory does this even now. > > (Cheap RAM can benefit RDBMS also, I would note.) > > It would make a big difference to many application if the data they > held in ram did not have to be saved on disk. Even back in the 386 days, if a Clipper/FoxPro/dBase table fit into RAM, it's access speed was nearly as fast as a dedicated RAM-only structure. The caching would only go to disk if the cache manager could not make use of RAM caching of the tables. At least they had the ability to use disk *if* RAM was not large enough. If you had large RAM, then disk would rarely be touched. Why would you want it any other way? Now I agree that existing RDBMS are optimize for the "small RAM" days such that they are compromise-tuned between RAM and Disk. However, as time goes on and RAM becomes cheaper, they are working on RAM-friendly solutions. However, databases tend to get bigger also as they can, so disk is still an issue. Plus, RDBMS are generally pretty fast if you have clean schemas and index properly. I don't have a reason to complain. It is many-row sequential searches that are the usual bottleneck, and that will be the case no matter what you are using. > > > OODMS are dead because they had most of the same problems that > > navigational DB's had in the 60's (which motivated Dr. Codd to clean up > > the scene.) > > No, I think they dead ended because most of them were big horrible slow > nasty behemoths (not all of them!) and because Oracle (in particular) > did a great job of marketing, and convincing the industry that RDBs > were the power that drives the internet. Oracle was indeed a good marketer, but IBM was the Microsoft of the day and Oracle couldn't kick their butt if they did not have a better product. Navigational databases were only slow if you queried against their grain, which is one of the *fundimental* faults of navigational structures: they tend to fit the shape of specific usage patterns. > > In the end, I think OODBs were a bad idea. I think the data decoupling > of the relational model is a good thing, and would not like to see data > stored as network in the general case. There are some instances where > the network strucdture is beneficial, but the general case belongs to > RDBs. > > >> Most people who use relational databases use them as the back end to an > >> OO middle and front end? > > > > Most? Like I keep saying, OO gets more lip service than actual usage in > > practice. Many OO proponents have agreed with me on this. (They say it > > is because people don't yet "get OO" or are allegedly too lazy to "do > > it right", not because OO is flawed.) > > I could make the same argument about RA. Most people don't do it > particularly well. True, but I'll take F'd up relational over F'd up OO. > But that's not relevant to the argument at hand. > Most systems are, as I said, OO programs with RDB back ends. I have to disagree. I've worked on several fairly large projects for well-known companies that didn't have an OO bone in their body. (Although it is true that if they were a heavy OO shop, they wouldn't hire/rent me.) > The OO > program may be messy, and the RDBs may be nastily tangled, but the fact > remains. > > > > >> Business rules (other than searching and > >> corelating) are done in the middle layers by OO programs. > > > > I've seen a lot of "business rules" being handled by SQL. Lots. (Even > > over-using SQL beyond its comfort zone.) A good portion of biz rules > > can be reduced to sets and attributes if organized properly. > > Sure. And ALL of them *could* be done outside the DB entirely. So > what. The reality is that most BRs are done in OO layers and only a > few, having to do with searching and correlating, are generally done in > SQL. Well, I have to disagree. > > > >> Presentation > >> is done by OO programs at the front end. > > > > Not always. A lot is strait HTML+JavaScript these days (for good or bad). > > Granted. Javascript is a nice little OO language. But, again, most > web based systems are built with Java, I don't think this is true. There is a lot of Perl, PHP, and ColdFusion, languages whose following are usually not OO fanatics. Most OO fanatics lean toward Java. Java takes a lot of developers because it is difficult, verbose, and bloated; so you see it mentioned a lot. Thus, staff size does not nec equate to application quantity. I would estimate that only 60% of new apps use OO lightly and only 30% use it heavily. Popularity does not necessarily equate with betterment anyhow. OO is pushed into the heads of new students, so they use it uncritically because they know nothing else. > with C# following behind by a > factor of 2-3. Rails is getting more and more popular. All of these > are OO. Rails is still too new to take up much existing market share. It is growing fast (so far), but that does not mean it is common yet. > > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: topmind on 1 Feb 2007 12:17 AndyW wrote: > That bit of code would be a lot simpler and execute much faster if it > was written in COBOL. I am not sure if this was meant as a joke or not. > > Andy -T-
From: topmind on 1 Feb 2007 12:53 Thomas Gagne wrote: > topmind wrote: > > <snip> > > Is speed really such an issue that you would *abandon flexibility* to > > acheive it? > > > You're making the assumption that network databases are inflexible. > They are not. They just aren't as flexible as relational databases. > But consider too that depending on how loosely coupled the application > is from the database that flexibility in the latter has implications for > the former. The more separated an app is from the DB, the more it has to reinvent stuff on its own. That is not "reuse". Indepedence can result in duplication of effort or design. It is not a free lunch. You guys talk about "decoupling" as if more is *always* good. Software engineering is about weighing trade-offs. There is no free lunch or magic bullet: you have to coordinate the peices and chunkify things to make it easier for humans to grok, but not too much such that each chunk has to reinvent the same wheels. > > An application with embedded SQL would be no less impacted by RDB-model > changes than it would network model changes. > RDB's flexibility comes > mostly before applications are wired to it--when it has the fewest > dependents. Once it has model and structure-dependent systems much of > that flexibility is lost. When that point is reached, the advantages an > RDB has over other database systems is greatly minimized to the point of > being moot. We would probably have to explore some scenarios. But, I don't like using navigational structures. Predicates and set theory come together nicely in relational. (I agree that implementations could use improvements, though, such as dynamic typing, dynamic column creation options, user-side views, column views, standardized data dictionaries, template-based validation, to- app validation integration, column set meta commands, etc.) It's mathematical influence seems to have paid off in this case. Navigational to me is the data structure equivalent of Go To's: inconsistent, chaotic shanty town pointer hell. I think they still live on to some extent because they better fit a physical view of things where you walk around in a little Tinkertoy-like-stick-figure model where the sticks are pointers and the connector nodes objects or maps. This I won't dispute. But a 3D world can also be very limiting, as any diety will tell you. ************************************************** In short, I would rather model with a flexible fake world than a limited real one. ************************************************** > > -- > Visit <http://blogs.instreamfinancial.com/anything.php> > to read my rants on technology and the finance industry. -T-
From: topmind on 1 Feb 2007 13:12
Robert Martin wrote: > On 2007-01-31 12:51:26 -0600, "topmind" <topmind(a)technologist.com> said: > > > Is speed really such an issue that you would *abandon flexibility* to > > acheive it? > > Sometimes. Yes. About 90% of performence issues I've seen in my industry are due to poor schema and/or application design. Throwing a messy navigational DB at a problem to get improvements over a messy relational design is not going to change the *real* cause. > > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T- |