Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: Robert Martin on 31 Jan 2007 22:00 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. -- 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: Daniel Parker on 1 Feb 2007 00:58 On Jan 31, 9:25 pm, Robert Martin <uncle...(a)objectmentor.com> wrote: > > 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. > No. In this example, the relation consists of two parts: the header {man, woman}, and the body, which is a list of all the tuples, here only one {Bob, Ann Marie} Look it up, e.g. in Date's article http://www.dbazine.com/ofinterest/oi-articles/date1. I think it was you who said "write about what you know, not about what you think." :-) Best regards, Daniel
From: topmind on 1 Feb 2007 01:49 Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > Patrick May wrote: > >> Second, you haven't shown that a solution that "embraced the DB" > >> would be shorter, more understandable, more maintainable, more > >> extensible, more easily testable, or "simpler" by any other metric. > > > > I don't claim I can show it objectively better. > > Actually, you did. Your exact words were: "If you embraced the > DB instead of spend all your code wrapping it, the app would be > noticably simpler." That's a positive claim about an objective > measurement. I was talking about Martin's payroll example. In that case I am pretty sure my version would be noticably simpler. However, I doubt many OO fans will agree that Martin's code is the best or simplest OO can be. > > > It just won't be objectively worse. > > That's another positive claim. Prove it. Let me reword it: Nobody can/will prove it objectively worse. > > Sincerely, > > Patrick -T-
From: topmind on 1 Feb 2007 02:05 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. > > ==================== > > sql = "select * from commands order by cmd_sequence > where empID =" . empID; > rs = query(sql); > while (cmd = nextCommand(rs)) { // row represents a command object > cmd.print(); > } //end-while > ===================== > > These two functions are immutable when new commands added, or existing > commands are changed or deleted. Being able to isolate functions from > certain kinds of change is one of the major goals of software > engineering. OO gives you more tools to do that with. I didn't find significant use for such when I had nimble table tools. Thus, I don't think the OO equivalent would add anything significant over a tablized version, let alone the if/case version. Some talk about accidentally "bumping" case cell N+1 when editing case cell N, but in practice that has not been a problem for me. Plus, studying nearby case blocks sometimes makes it easier to see commonalities to factor out. If they are in separate classes it may be hard to see the commonality. Tables at least give us the ability to sort and print them any way we please, something not built-in to OO. "Together" is relative under tables. Code hard-wires proximity, and is thus "stiff". (And OO IDE's are navigational DB browsers.) Tables are more naturally meta-anabled than classes. > > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: topmind on 1 Feb 2007 02:21
Robert Martin wrote: > 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. Yes they do. They are navigational structures. Just because they are small does not mean they don't share navigational characteristics. > (And BTW, Network > databases are not demon spawn. It's just some narrow individuals who > think they are. They have their uses.) Very rarely in my domain. > > > 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. One can put simple wrapper functions around relational schema to get "next", "previous", "go_north", etc. But then again, I talk about the domain of custom biz apps. If navig'l is wonderful for electro zappy stuff, fine diddly doo. Just don't over-extrapolate into biz apps. Don't leak. > > > 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. Yes, but it is hard to identify clear starts and stops. > 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. Dependency is relative to what you are comparing. You just focus on the traditional things that OO claims to improve, ignoring others because OO books don't point them out. > > > 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. Yes it does. The clearer the boundaries between tasks, the less OO it is. Sure, you can use classes as verbose procedural modules, but that does not count as OO in my book. It is only nominal OO. > > > 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. So are relational tables. I thought you said they don't fight over territory. > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T- |