Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: Robert Martin on 31 Jan 2007 21:20 On 2007-01-30 10:22:14 -0600, lilburne <lilburne(a)godzilla.nospam.net> said: > frebe73(a)gmail.com wrote: > >>>> A HR application need data about employees in many different ways. RCM >>>> already gave you one example of a very specific criteria for finding >>>> employees. When a company needs to reduce the staff, it would be nice >>>> if the HR application had a feature to find employees eligible for >>>> early retirement, wouldn't it? It is easy to imagine other examples of >>>> very specific ways of finding employees. Lets say we want to send every >>>> manager an email containing the employees having 30-, 40-, 50-year >>>> birthday next month. >>> >>> Such functions are illegal and would result in prosecution. You really >>> do need to keep up with employment law. >> >> >> Which function is illegal in which country? What is your point? Are you >> trying to say that it is illegal to find employees in many different >> ways? Do you want more examples? Or...? >> > > For what legal reason would you want to select employees based on age? > Certainly not for decision making on staff reductions. To send them birthday cards. ;-) -- 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: Robert Martin on 31 Jan 2007 21:25 On 2007-01-30 02:39:37 -0600, AndyW <a(a)b.no.email> said: > On Mon, 29 Jan 2007 21:46:13 -0600, Robert Martin > <unclebob(a)objectmentor.com> wrote: > >> >>>> "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. >> >> An object is an instance of a relation. The relation itself is >> described by the class of the object. > > Sorry, I cant agree with that last sentence. Could you explain what > you mean by that statement in case my understanding is wrong. > > I've always understood a relation to be an abstract thing. > Andy A "relation" as I understand it, is the definition of a tuple. Marriage(man, woman) is a relation. Marriage(Bob, Ann Marie) is an instance of that relation. -- 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: Robert Martin on 31 Jan 2007 21:39 On 2007-01-30 00:03:36 -0600, "topmind" <topmind(a)technologist.com> said: > Transient small network databases? Does that separate them > significantly from the those that are "demon spawn"? They are transient structures that facilitate certain calculations. They have nothing to do with network databases. (And BTW, Network databases are not demon spawn. It's just some narrow individuals who think they are. They have their uses.) > If they are small and trivial, then procedural would be simplier. The OO vs Procedural axis is not the simple vs. complex axis. OO and Procedural differ by the kinds of things they make easy, and the kinds of things they make hard. > If they are large and complex, then they more resemble the "demon > spawn" mentioned. As I said, network structures have their uses. Walking a circuit diagram, for example, is much easier with a network database than with a relational database. > And OO has not found a clean way to manage all that transientivity. You mean "transience"? I'm not at all clear what you mean. I think you suffer from the misaprehension that OO programs are assemblages of free running objects popping in and out and doing things without any control. Not so. OO programs have a thread of control. Generally they are synchronous in the same way that most procedural programs are synchronous. The big difference is that at certain strategic places in the code the flow of control flows *against* the direction of source code dependencies, creating dependency breaks. > In procedural you focus on one task at a time, saving any "state" to > the DB when done, and clearing out just about everything. Lots of OO programs are written that way too. This style of programming has nothing to do with the difference between OO and procedural. > It has cleaner boundaries because each task is nearly a clean slate. Again, this has nothing to do with the difference between OO and p/r. > Objects float around until they catch syphillus or the like. Cute, but silly. Objects do not float around. They are just data structures operated on by functions. > (And event-driven programming has reduced the app-side complexity of > the procedural "master loop".) I'm not sure I know what you are saying there. In general GUI and Web based programs are even driven in that the OS or platform calls into the application when certain events occurr. This has nothing to do with the difference between OO and procedural programs. -- 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: Robert Martin on 31 Jan 2007 21:57 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. > 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. 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. But that's not relevant to the argument at hand. Most systems are, as I said, OO programs with RDB back ends. 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. > >> 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, with C# following behind by a factor of 2-3. Rails is getting more and more popular. All of these are OO. -- 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: Robert Martin on 31 Jan 2007 22:00
On 2007-01-31 08:16:33 -0600, Thomas Gagne <tgagne(a)wide-open-west.com> said: > You're correct, but does that mean we should stop there? Let's say > RDBs are great for prototyping and production. Their flexible > structure makes them great for trying things out, proving them correct, > and even shipping to production. Once the /model/ has been proven > correct is there any reason it can't be hard-wired into a network > database and made even faster and more compact? Is it possible the RDB > is the scripting-language prototype language for DBs and that network > databases might be there compiled form? > > I remember doing some testing (I admit it's a bit outdated) between > network and relational databases--same model, different implementation, > same tasks, and found the network model to be /significantly/ faster > than relational. I haven't the time (or the network database) to do > the same comparison now, but the thought has been brewing now for a > while... For some applications I think this is appropriate, and even necessary. CAD systems, for example, invested heavily in OODBs because the RDB model was ponderous for the deeply networked data structures of CAD/CAM systems. In general, though, I think RDBs are the mainstay, and should be. The data decoupling afforded by the Relational model is just too good to pass up in most cases. -- 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� � � � � � � � ��| |