Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
topmind
Patterns, and Practices" on my blog:
http://www.geocities.com/tablizer/martin1.htm
Comments welcome. At least nice ones are :-)
-T-
Thomas Gagne
> I have put a draft critique of Robert C. Martin's "Agile Principles,
> Patterns, and Practices" on my blog:
>
database design is not an implementation detail, nor is it irrelevant.
I suspect Mr. Martin and I are at opposite ends of this debate. For the
past two weeks I've been promoting the belief the database is the
biggest and perhaps most important 'object' in the system and your
blog's excerpts from his book suggest he believes the opposite.
I suspect he and Martin Fowler (it is reported) both share the opinion
that if memory was both infinite and infallible that databases would be
unnecessary. Well, perhaps they would be if you never needed to share,
duplicate, or transport them.
--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.
topmind
> topmind wrote:
> > I have put a draft critique of Robert C. Martin's "Agile Principles,
> > Patterns, and Practices" on my blog:
> >
> I haven't read the entire book (or your entire critique) but I agree
> database design is not an implementation detail, nor is it irrelevant.
> I suspect Mr. Martin and I are at opposite ends of this debate. For the
> past two weeks I've been promoting the belief the database is the
> biggest and perhaps most important 'object' in the system and your
> blog's excerpts from his book suggest he believes the opposite.
>
> I suspect he and Martin Fowler (it is reported) both share the opinion
> that if memory was both infinite and infallible that databases would be
> unnecessary. Well, perhaps they would be if you never needed to share,
> duplicate, or transport them.
This is perhaps related:
http://c2.com/cgi/wiki?ProgrammingWithoutRamDiskDichotomy
Unlimited non-volitile RAM for their style of OO would still basically
be a navigational database not much different than the contraptions
that motivated Dr. Codd to "clean up the town". Adding "function
pointers" (methods) into the mix or putting behavorial wrappers around
them does not change their fundimental problems.
No matter what new names or packaging they put around navigational
DB's, they still have the same issues. Navigational structures are like
the Vietnam War: every generation has to reinvent and relive it and
suffer all over again. Only the place names and faces change.
>
> --
-T-
Neo
> be a navigational database not much different than the contraptions
> that motivated Dr. Codd to "clean up the town". Adding "function
> pointers" (methods) into the mix or putting behavorial wrappers around
> them does not change their fundimental problems.
>
> No matter what new names or packaging they put around navigational
> DB's, they still have the same issues. Navigational structures are like
> the Vietnam War: every generation has to reinvent and relive it and
> suffer all over again. Only the place names and faces change.
Suppose Adam(age 30) has children named John(tall), Mary(short),
Bob(fat), Sue(short/thin), Adam(age 5). Body builds tall/short and
fat/thin are opposites. And we want to find the following, without
explicitly referring to John's parent (Adam) or John's build (tall)
directly:
1) John's siblings.
2) John's fat siblings.
3) John's siblings of opposite build.
4) Persons with builds with whom Bob's build has same relationship as
John's build's relationship with Mary's build (without explicitly
referring to that relationship in the query).
Below is a solution based on a network/OO-ish metholdolgy. Could you
show how Codd's solution would be cleaner / less navigational
especially as new data requirements are added later?
(new 'tall 'build)
(new 'athletic 'build)
(new 'petite 'build)
(new 'short 'build)
(new 'thin 'build)
(new 'fat 'build)
(new 'opposite)
(set tall opposite short)
(set short opposite tall)
(set fat opposite thin)
(set thin opposite fat)
(new 'john 'person)
(set john build tall)
(new 'mary 'person)
(set mary build short)
(new 'bob 'person)
(set bob build fat)
(new 'sue 'person)
(set sue build short)
(set sue build thin)
(new 'age)
(new 'adam 'person)
(set+ adam age '10)
(new 'adam 'person)
(set+ (it) age '30)
(set (it) child john)
(set (it) child mary)
(set (it) child bob)
(set (it) child sue)
(set (it) child (and (get * name 'adam)
(get * age 10)))
(; Get john's siblings
by getting persons
who are children of john's parent
and are not himself)
(; Gets mary, bob, sue, little adam)
(!= (and (get person instance *)
(get (get * child john) child *))
john)
(; Get john's fat siblings
by getting persons
whose build is fat
and are children of john's parent
and are not himself)
(; Gets bob)
(!= (and (get person instance *)
(get * build fat)
(get (get * child john) child *))
john)
(; Get john's siblings of opposite build
by getting persons
whose build is opposite of john's build
and are children of john's parent
and are not himself)
(; Gets mary and sue)
(!= (and (get person instance *)
(get * build (get (get john build *) opposite *))
(get (get * child john) child *))
john)
(; Get persons with builds with whom bob's build relationship is the
same asjohn's build relationship to mary's build)
(; Gets sue)
(get * build (get (get bob build *)
(get (get john build *) * (get mary build *))
*))
topmind
> > Unlimited non-volitile RAM for their style of OO would still basically
> > be a navigational database not much different than the contraptions
> > that motivated Dr. Codd to "clean up the town". Adding "function
> > pointers" (methods) into the mix or putting behavorial wrappers around
> > them does not change their fundimental problems.
> >
> > No matter what new names or packaging they put around navigational
> > DB's, they still have the same issues. Navigational structures are like
> > the Vietnam War: every generation has to reinvent and relive it and
> > suffer all over again. Only the place names and faces change.
>
> Suppose Adam(age 30) has children named John(tall), Mary(short),
> Bob(fat), Sue(short/thin), Adam(age 5). Body builds tall/short and
> fat/thin are opposites. And we want to find the following, without
> explicitly referring to John's parent (Adam) or John's build (tall)
> directly:
We've been over these kinds of things already. I'll let somebody else
try this time. I remember at least 2 cases where the relational
equivalent was about the same as your nav version (although we had to
use vendor-specific SQL in one case, but SQL is not on trial,
relational is).
I don't necessarily claim that all navigational queries will be longer
than relational equivalents. The hard part about navigational is *lack
of consistency* in the structures. Two different people who never met
each other would generally come up with similar relational schemas.
There are variations, but generally the possible normalized variations
will be small, rarely more than 2 or 3 solutions at the most (in a
grand sense).
But, there are *no consistent rules* for navigational structures. This
makes it take longer to get your head around the structures *and* work
up the queries. Tables provide structure, but navigational has no
guarenteed structure: they are just graphs. Some graphs may have some
amount of treeness to them, but this is not guarenteed in any way. And,
treeness may not make them flexible or clean anyhow even if in there.
Also, it may create integrity problems. What prevents one from
producing a recursive navigational query, for example?
Even a good many OO fans seem to agree that relational is better at
ad-hoc queries (even if not better for app-specific modeling). Unless
it is a majority OO opinion, perhaps the "database theory" topic would
be more appropriate for a claim that navigational is better for ad-hoc
queries. Other than a handful of XML database pushers, I don't see that
as a popular opinion.
The lack of consistency probably makes it possible to tweak a structure
to better fit a given nav query anyhow. This wiggle room gives you an
edge. An analogy: The most compact procedural program for a set of
requirments will probably use GOTO's instead of nested blocks. However,
I would hate to have to maintain it as a human.
Neo
> > > be a navigational database not much different than the contraptions
> > > that motivated Dr. Codd to "clean up the town".
> > Below is a solution based on a network/OO-ish metholdolgy. Could you
> > show how Codd's solution would be cleaner / less navigational
> > especially as new data requirements are added later?
> We've been over these kinds of things already. I'll let somebody else
> try this time. I remember at least 2 cases where the relational
> equivalent was about the same as your nav version (although we had to
> use vendor-specific SQL in one case, but SQL is not on trial,
> relational is).
The underlying data structure in the prior examples could be managed
systematically in RM. The "Sibling of Opposite Build" cannot.
topmind
IIRC, I showed how to represent opposites in schemas about 2 weeks ago.
The relational model can represent any graph. Perhaps you are arguing
that it is "uglier" in RM?
Again, you failed to prove your point on 2 prior query-size challenges.
Why should I take you up on a 3rd one? Navigational queries are kind of
off-topic anyhow. Plus, you seem to keep focusing on the size issue
instead of the consistency issue. Try again in six months, maybe I'll
feel like joining another query-size battle then :-)
-T-
Neo
> > systematically in RM. The "Sibling of Opposite Build" cannot.
>
> IIRC, I showed how to represent opposites in schemas about 2 weeks ago.
Neither of the two relational schemas offered were systematic or
resilient solutions; no data was entered and no queries were shown.
Quote "I will leave the query work to somebody else".
> The relational model can represent any graph.
True. The data structure underlying the "Sibling of Opposite Build"
example isn't a graph. Its a network. The difference should become
clearer when one try to formulate the last query.
topmind
> > > The underlying data structure in the prior examples could be managed
> > > systematically in RM. The "Sibling of Opposite Build" cannot.
> >
> > IIRC, I showed how to represent opposites in schemas about 2 weeks ago.
>
> Neither of the two relational schemas offered were systematic or
> resilient solutions; no data was entered and no queries were shown.
> Quote "I will leave the query work to somebody else".
I am not referring to that one. One is the one that would have been
shortened via "natural joins" if the vendor's SQL supported it. (You
supplied the original SQL, I would note.) In other words, SQL tends to
have bloated JOIN's, but that is technically solvable. I don't remember
you challenging that when I brought it up. I would note that you got to
make up your own query language so are not bound by existing
implementations. That is fine by me as long as *both sides* are allowed
such. (I have proposed a new relational language called SMEQL, by the
way. It would be easier for a DBA or programmer to extend than SQL
because it has simpler "atoms".)
And the 2nd example one was the "kitchen and fridge" one from roughly a
year ago IIRC. I don't remember the details, but the relational query
was reworked and comparable in size to your navigational query.
>
> > The relational model can represent any graph.
>
> True. The data structure underlying the "Sibling of Opposite Build"
> example isn't a graph. Its a network. The difference should become
> clearer when one try to formulate the last query.
Well, maybe, but not today. 2 is enough for now. From my perspective,
your quota for calling Wolf is spent for a while.
-T-
Neo
> > resilient solutions; no data was entered and no queries were shown.
> > Quote "I will leave the query work to somebody else".
>
> I am not referring to that one. One is the one that would have been
> shortened via "natural joins" if the vendor's SQL supported it. (You
> supplied the original SQL, I would note.) In other words, SQL tends to
> have bloated JOIN's, but that is technically solvable. I don't remember
> you challenging that when I brought it up
There was no reason to challenge there because RM can systematically
manage the "Find Siblings" example. The "original SQL" was provided by
a cdt member in response to that example. Below are the approx
equivalent queries based on approx equivalent underlying data
structures.
(!= (and (get person instance *)
(get (get * child john) child *))
john)
SELECT P2.*
FROM ((person INNER JOIN link ON person.ID = link.childID)
INNER JOIN link AS link2 ON link.parentID = link2.parentID)
INNER JOIN person AS P2 ON link2.childID = P2.ID
WHERE (((P2.name)<>"John")
AND ((person.name)="John")
The above comparision was provided in response to your comment
"Navigational query languages were proposed. They were ugly because
navigational is ugly."
> And the 2nd example one was the "kitchen and fridge" one from roughly a
> year ago IIRC. I don't remember the details, but the relational query
> was reworked and comparable in size to your navigational query.
Below is a link to that thread starting near message 291.
http://groups.google.com/group/comp.object/browse_frm/thread/4bd174aa28832f6c/78e7ae20bcfb4288?lnk=gst&q=Neo+Topmind+fridge&rnum=1#78e7ae20bcfb4288
While that example can also be handled systematically in RM and the two
queries appear similar, the queries are based on substantially
different underlying structures. In the network/OO-ish implementation,
not only can items in the house form an infinite depth hierarchy (ie
house\floor\kitchen\fridge\2ndShelf\eggCarton\egg\yolk etc), each item
can contain things of various types and each item can 0 to many
classifications, attributes and values; where as the RM solution is
based on a simpler and fixed hierarchy (ie T_House, T_Room and
T_Funiture) where each level can only contain things of one type. By
specifying additional data, I can show that the original OO/Network-ish
solution/query is more general and resilient compared to the RM
solution/query.
(& (get single-family instance *)
(get * has (& (get bedroom instance *)
(get * has (& (get carpet instance *)
(get * color purple)))))
(get * has (& (get kitchen instance *)
(get * has (& (get fridge instance *)
(get * mfg sears))))))
SELECT * FROM houses
WHERE houseType="single family"
AND houseID in
(SELECT houseID FROM rooms WHERE carpetColor="purple")
AND houseID in (SELECT houseID FROM furniture
WHERE furnitureType="fridge" AND brand="Sears")
Would you be willing expand on this example? Lets start with something
simple. For example, if we add a room with carpet of multiple colors,
the original OO/Network-ish query is unaffected. How can one handle
this situation in the RM solution?
topmind
I made some subsequent comments about "natural joins" and similar
techniques to simplify the joining code (default joins don't have to be
explicitly stated), key-words versus symbols when counting "size", and
excess parenthesis. My comments still stand.
-T-
JXStern
wrote:
Page 351, second paragraph: "Instead of starting with the data of the
system, let's start by considering the behavior of the system. After
all, it is the system's behavior that we are being paid to create."
Says who?
I've moved from conventional 3G app development to about 98% database
work over the last decade, and let me tell you, there are no end of
systems whose purpose is the gathering and provision of data, where
the processing is minimal. And it is quite easy to generalize, so
that a standard accounting/MRP system of order entry, AR, AP, GL,
inventory, shipping, is seen as a DATA MODEL, with several different
surfaces, and the "behaviors" are generally nonprocedural data
constraints and transactions.
The value of the relational concept is the normalized data model. Now,
on close inspection there are problems here, but it is a worthy goal
and substantially useful in most cases. It is the cannonical nature
of the concept that is valuable, and I'm sure you could build a dual
of the relational model with networks and pointers, if you were so
inclined. It's not the technology, it's the concept.
Finally, I'd like to say that the design of GUIs seems a lost art.
One can come up with cannonical rules for GUI design, which would
generate better designs and implementations than 99% of the crap that
I see done today, mostly on the web but also in bespoke rich-clients.
I haven't read (or seen) RCM's book, I'm sure it's amusing, and I hope
it has some better sections than this.
J.
topmind
JXStern wrote:
> On 30 Dec 2006 23:55:10 -0800, "topmind" <top...@technologist.com>
> wrote:
>
> >I have put a draft critique of Robert C. Martin's "Agile Principles,
> >Patterns, and Practices" on my blog:
> >
> >http://www.geocities.com/tablizer/martin1.htm
> >
> >Comments welcome. At least nice ones are :-)
[...]
> Finally, I'd like to say that the design of GUIs seems a lost art.
> One can come up with cannonical rules for GUI design, which would
> generate better designs and implementations than 99% of the crap that
> I see done today, mostly on the web but also in bespoke rich-clients.
The old event-driven model found in VB and Delphi, perhaps with some DB
awareness like Powerbuilder was pretty good at GUI's. If they
open-sourced the GUI engine, meta-tized it more, and added flexible
scaling screen concepts, it would be quite usable today. Hopefully Ajax
or the like will get back to that.
>
> I haven't read (or seen) RCM's book, I'm sure it's amusing, and I hope
> it has some better sections than this.
RCM definitely appears to not be a RDBMS fan and is happier the more he
wraps it away.
>
> J.
Cheers, -t-
JXStern
wrote:
>> Finally, I'd like to say that the design of GUIs seems a lost art.
>> One can come up with cannonical rules for GUI design, which would
>> generate better designs and implementations than 99% of the crap that
>> I see done today, mostly on the web but also in bespoke rich-clients.
>
>The old event-driven model found in VB and Delphi, perhaps with some DB
>awareness like Powerbuilder was pretty good at GUI's. If they
>open-sourced the GUI engine, meta-tized it more, and added flexible
>scaling screen concepts, it would be quite usable today. Hopefully Ajax
>or the like will get back to that.
It's an issue of what is done with the tools. The tools are fine.
OK, static HTML with common controls limits what you can do, but
here's a very BASIC thing that bugs me: everyone uses pull-downs, both
for huge lists and for small lists, when it would often improve a GUI
dramatically to use listboxes (scrolling list showing many at a time)
instead.
>> I haven't read (or seen) RCM's book, I'm sure it's amusing, and I hope
>> it has some better sections than this.
>
>RCM definitely appears to not be a RDBMS fan and is happier the more he
>wraps it away.
OK, I looked up the book, it's 2002. I probably glanced at it at some
point. "Agile" goes back to iterative methods first popularized and
formalized in the late 1970s. "Agile" has nothing to say about using
one tool or another, or about RDBMS, pro or con.
RCM and lots of guys are playing with ideas and publishing books for
fun and profit, RCM in particular ought to know better, ... but you
KNOW how OOP seems to blind people to what is known and what is
standard with RDBMS.
J.
topmind
JXStern wrote:
> On 13 Jan 2007 19:08:35 -0800, "topmind" <top...@technologist.com>
> wrote:
> >> Finally, I'd like to say that the design of GUIs seems a lost art.
> >> One can come up with cannonical rules for GUI design, which would
> >> generate better designs and implementations than 99% of the crap that
> >> I see done today, mostly on the web but also in bespoke rich-clients.
> >
> >The old event-driven model found in VB and Delphi, perhaps with some DB
> >awareness like Powerbuilder was pretty good at GUI's. If they
> >open-sourced the GUI engine, meta-tized it more, and added flexible
> >scaling screen concepts, it would be quite usable today. Hopefully Ajax
> >or the like will get back to that.
>
> It's an issue of what is done with the tools. The tools are fine.
> OK, static HTML with common controls limits what you can do, but
> here's a very BASIC thing that bugs me: everyone uses pull-downs, both
> for huge lists and for small lists, when it would often improve a GUI
> dramatically to use listboxes (scrolling list showing many at a time)
> instead.
Sound like that is a case where one would want to use a two-column
table grid with the first column being a check-box and the second a
description. However, if there are thousands, then going to a "pop-up"
modal selection screen where one uses QBE etc. to pick them and then it
puts the picks back at the original screen. But this is tricky and
time-consuming to pull off with web browsers.
-T-
JXStern
wrote:
>> It's an issue of what is done with the tools. The tools are fine.
>> OK, static HTML with common controls limits what you can do, but
>> here's a very BASIC thing that bugs me: everyone uses pull-downs, both
>> for huge lists and for small lists, when it would often improve a GUI
>> dramatically to use listboxes (scrolling list showing many at a time)
>> instead.
>
>Sound like that is a case where one would want to use a two-column
>table grid with the first column being a check-box and the second a
>description. However, if there are thousands, then going to a "pop-up"
>modal selection screen where one uses QBE etc. to pick them and then it
>puts the picks back at the original screen. But this is tricky and
>time-consuming to pull off with web browsers.
Sure, fancy grids are a great way to go, but aren't supported in
standard form across current browsers (hint, hint). And pop-ups to
present a modal choice from complex data are a basic mechanism for
rich-clients, don't believe they're enforceable with standard browser
features, at some cost you can morph the current window into a modal
choice one, but yeah it's work.
But anyway it's so frequent to see the basic mistake made, the current
timekeeping system I'm using is a prime example.
Getting back to the main topic, it's just the case that a
well-educated developer doesn't see it as encapsulating function in a
component, so much as utilizing the available components.
J.
topmind
This may be related:
http://www.c2.com/cgi/wiki?HelpersInsteadOfWrappers
As far as "list boxes", do you mean the kind that you have to press
something like Ctrl-Shift to select an item? Those are goofy
keystrokes. The browser makers should have used checkboxes next to the
descriptions (IOW, tables :-)
>
> J.
-T-
Robert Martin
> I suspect he and Martin Fowler (it is reported) both share the opinion
> that if memory was both infinite and infallible that databases would be
> unnecessary. Well, perhaps they would be if you never needed to share,
> duplicate, or transport them.
Database engines are powerful tools that are very useful for many
different kinds of applications. In some cases whole applications can
(and should) be written using nothing but the tool.
I am in the mist of writing a two simple applications for small
businesses at the moment. Both use a database back end. Both are web
driven. Both have interesting business rules. One is written in Java,
the other in Rails.
My philosophy of programming guides me to ignore the database in the
early portions of these designs. I was quite able to do that in the
Java application, with very good results. But Rails is more tightly
coupled to the database; and my inexperience with the framework caused
me to aquiesce to this coupling. In short, I allowed the business
rules and the database to become coupled.
The Java applications worked out quite nicely. The business rule layer
is indendent of the database layer and the GUI layer. They all work
nicely together and the implementation was simple and fast.
The Rails application has led to complications. There are forms I want
to display that don't seem to corespond to any particlar database
table, and yet the framework is tuned to the idea of
one-form-one-table. I fell into this trap, and now I have to dig my
way out.
BTW, this is not a blast on Rails. I think if I had had a bit more
experience with Rails I would have sidestepped this trap pretty easily,
and simply separated the business rules from the database.
To sum up. Though I agree that database engineers are powerful and
necessary tools, and though I understand that they are often critical
to the success of many project, from a design perspective they are
details that need to be decoupled from the business and presentation
rules of most applications.
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716 |
Robert Martin
> Page 351, second paragraph: "Instead of starting with the data of the
> system, let's start by considering the behavior of the system. After
> all, it is the system's behavior that we are being paid to create."
>
> Says who?
Says me! ;-) The problem being discussed is Payroll. If we are
writing a payroll application we are being paid to create payroll
behaviors.
I am quite happy to agree that there are applications that are more
about data storage and provisioning, than any actual processing. But
that was not the case under study.
Robert Martin
> RCM definitely appears to not be a RDBMS fan and is happier the more he
> wraps it away.
It has nothing to do with fan-dom. I consider RDBMSs to be valuable
and important components of many systems. Like any component, it
should be isolated from the others. This is just good software
practice. (see Information Hiding).
Robert Martin
> OK, I looked up the book, it's 2002. I probably glanced at it at some
> point. "Agile" goes back to iterative methods first popularized and
> formalized in the late 1970s.
Iterative methods have been around since the late 50s. The term Agile
refers to a suite of practices that include iterative development.
Other practices in the Agile suite include Test Driven Develoment,
Refactoring, Simple Design, Pair Programming, Continuous Integration,
etc, etc.
> "Agile" has nothing to say about using
> one tool or another, or about RDBMS, pro or con.
The principles of Agile design have implications for how to treat the
different components of systems architecture, including DBs. The term
"pro or con" has no meaning here.
> RCM and lots of guys are playing with ideas and publishing books for
> fun and profit, RCM in particular ought to know better, ... but you
> KNOW how OOP seems to blind people to what is known and what is
> standard with RDBMS.
One day you may write a book. Then we can talk about fun and profit. ;-)
In any case, I'm not quite sure what "know better" is supposed to mean
here. Let me give you some advice though. Before you criticize an
author for not knowing better, you might want to read what he wrote.
Reading what someone else wrote about what the author wrote is less
than reliable.
fre...@gmail.com
> writing a payroll application we are being paid to create payroll
> behaviors.
Payroll behavior is producing a payment file to the bank, using data
supplied by employees and adminstrators. The data is the important
thing. Behavior is only the method of transforming data. Like many
other business applications, it is all about providing information or
data to different actors. The behavior of the application is low-level
stuff that is not important on higher abstractation levels.
Fredrik Bertilsson
http://mybase.sf.net
topmind
> On 2007-01-13 21:08:35 -0600, "topmind" <top...@technologist.com> said:
>
> > RCM definitely appears to not be a RDBMS fan and is happier the more he
> > wraps it away.
>
> It has nothing to do with fan-dom. I consider RDBMSs to be valuable
> and important components of many systems. Like any component, it
> should be isolated from the others. This is just good software
> practice. (see Information Hiding).
Isolation creates duplication of concepts and can make it more
difficult to use the existing power and abilities of RDBMS. Most of the
code in your book is WASTED on translating back and forth between two
medium-to-high-level concepts: OO and relational. It is like spending
effort translating between Japanese and Spanish and back rather than
get anything real done.
The isolation is costing you complexity and code volume. I don't see
how you are claiming it better. You don't describe your scoring
mechanism that goes on in your head.
In case you swap DB vendors? That happens like once every 20 years, and
there are non-OO ways to do it also. Please focus on REAL problems, not
meteor insurance.
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
> Object Mentor Inc. | blog: www.butunclebob.com
> The Agile Transition Experts | web: www.objectmentor.com
> 800-338-6716 |
-T-
lilburne
> On 2007-01-13 17:00:24 -0600, JXStern <JXSternC...@gte.net> said:
>
>> Page 351, second paragraph: "Instead of starting with the data of the
>> system, let's start by considering the behavior of the system. After
>> all, it is the system's behavior that we are being paid to create."
>>
>> Says who?
>
>
> Says me! ;-) The problem being discussed is Payroll. If we are
> writing a payroll application we are being paid to create payroll
> behaviors.
>
Hasn't Payroll been solved? I thought getting paid was one of the first
things that Software Engineers and Consultants, irrespective of
methodology, had got bug free.
Daniel Parker
lilburne wrote:
> Robert Martin wrote:
>
> Hasn't Payroll been solved?
I think so. I think you buy them these days. I don't know of any
companies that would write their own payroll system anymore.
Daniel
JXStern
wrote:
>This may be related:
>
>http://www.c2.com/cgi/wiki?HelpersInsteadOfWrappers
>
>As far as "list boxes", do you mean the kind that you have to press
>something like Ctrl-Shift to select an item? Those are goofy
>keystrokes. The browser makers should have used checkboxes next to the
>descriptions (IOW, tables :-)
On a standard list box, you chose one with a click, you may have to
press Ctrl if you want to multi-select. Other list boxes toggle all
rows with clicks, letting you multi-select perhaps more simply.
Isn't it a sign of the apocalypse that I have to explain this?
J.
JXStern
<lilb...@godzilla.nospam.net> wrote:
>> Says me! ;-) The problem being discussed is Payroll. If we are
>> writing a payroll application we are being paid to create payroll
>> behaviors.
>
>Hasn't Payroll been solved? I thought getting paid was one of the first
>things that Software Engineers and Consultants, irrespective of
>methodology, had got bug free.
I'm not sure about bug-free, it sometimes runs slower than spec, and
all the errors seem to be on the low side.
J.
topmind
We are talking in terms of web browser conventions, not GUI's in
general. Web browsers are limiting and many of us miss the simplicity
and flexibility of "fat client" GUI's. A web-browser's multi-select is
implemented stupidly. The user should not have to press Ctrl. They
should have used checkboxes or something similar.
>
> J.
-T-
JXStern
Well said.
But it's a difficult conceptual point. One gets into terms like
behaviorism and verificationism and RCM would find a lot of support
there, but note that those doctrines have fallen rather badly out of
favor since about 1970, and it's unclear that what replaced them in
psychology or philosophy works in computer science.
My point being that one is not at all forced to use behavior as a
criteria, there are other frameworks. And I see nothing in iterative
or the portmanteau as RCM would have it of Agile, that necessitates
behavior as a key.
J.
JXStern
<uncl...@objectmentor.com> wrote:
>On 2007-01-14 10:49:40 -0600, JXStern <JXSternC...@gte.net> said:
>
>> OK, I looked up the book, it's 2002. I probably glanced at it at some
>> point. "Agile" goes back to iterative methods first popularized and
>> formalized in the late 1970s.
>
>Iterative methods have been around since the late 50s. The term Agile
>refers to a suite of practices that include iterative development.
>Other practices in the Agile suite include Test Driven Develoment,
>Refactoring, Simple Design, Pair Programming, Continuous Integration,
>etc, etc.
I mean the important principles go back - as far as you care to trace
them, then.
You mean, the term Agile was coined in the last few years to wrap up
these old principles and some newer ones.
>> "Agile" has nothing to say about using
>> one tool or another, or about RDBMS, pro or con.
>
>The principles of Agile design have implications for how to treat the
>different components of systems architecture, including DBs. The term
>"pro or con" has no meaning here.
I deny any such claim even makes sense, other than making Agile a
wrapper you can throw anything at all into.
>> RCM and lots of guys are playing with ideas and publishing books for
>> fun and profit, RCM in particular ought to know better, ... but you
>> KNOW how OOP seems to blind people to what is known and what is
>> standard with RDBMS.
>
>One day you may write a book. Then we can talk about fun and profit. ;-)
I know already, have long been struggling with a book in a somewhat
different area, and have researched the meager monetary compensation
involved, but there must be some motivating factor that gets
satisfied!
>In any case, I'm not quite sure what "know better" is supposed to mean
>here. Let me give you some advice though. Before you criticize an
>author for not knowing better, you might want to read what he wrote.
>Reading what someone else wrote about what the author wrote is less
>than reliable.
Fair enough, but I followed a year or two of your evolution thru the
XP world, and the paragraph seemed consistent with that history and at
least some of the claims of topmind.
J.
topmind
I think the rules and laws keep changing and are often State-specific.
Anyhow, such is used as a training example regardless of whether there
are off-the-shelf versions of it. There are a lot of real-world details
left out of Robert's example anyhow to keep it digestable to the
reader. He does put such a disclaimer in his book.
One of the problems with biz examples, or any examples for that matter,
is that if you pick something familiar to the reader, it is probably
already "packaged", and if you pick something too esoteric to be
packaged, nobody will relate and you spend half the book explaining the
domain.
-T-
topmind
> On 2007-01-13 17:00:24 -0600, JXStern <JXSternC...@gte.net> said:
>
> > Page 351, second paragraph: "Instead of starting with the data of the
> > system, let's start by considering the behavior of the system. After
> > all, it is the system's behavior that we are being paid to create."
> >
> > Says who?
>
> Says me! ;-) The problem being discussed is Payroll. If we are
> writing a payroll application we are being paid to create payroll
> behaviors.
>
> I am quite happy to agree that there are applications that are more
> about data storage and provisioning, than any actual processing. But
> that was not the case under study.
The problem is that data and behavior are mostly interchangable. For
example, to the interpreter/compiler, a program *is* data. Actually,
table-oriented techniques tend to build a kind of domain-specific
interpreter, so the analogy does have some legs in app design.
In light of this, it is hard to say what is *inharently* data-centric
and what is behavior-centric. I find it a matter of human convenience.
Some parts of the apps are easier to deal with as code-centric
expressions and others as lists/tables of attributes. Code makes for
crappy attribute managers and noun modeling, IMO, such that I tend to
shift those to the table side of things. But nitty-gritty
non-repetitious IF statements and Boolean formulas are easier for me to
deal with as programming code. Such could be tablized if one wanted,
but from my brain's perspective it is best kept those in code. Your
brain may be different and you like more in code. Such people tend to
be linguistic thinkers as opposed to visual thinkers in my observation.
I am generally a visual thinker and thus shift more to tables than a
liguistical thinker would. OO tends to favor linquistic thinkers and
scares off visual people. Software engineering is largely about
psychology, for good or bad, not math nor science.
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
lilburne
> lilburne wrote:
>> Robert Martin wrote:
>>
>>> On 2007-01-13 17:00:24 -0600, JXStern <JXSternC...@gte.net> said:
>>>
>>>> Page 351, second paragraph: "Instead of starting with the data of the
>>>> system, let's start by considering the behavior of the system. After
>>>> all, it is the system's behavior that we are being paid to create."
>>>>
>>>> Says who?
>>>
>>> Says me! ;-) The problem being discussed is Payroll. If we are
>>> writing a payroll application we are being paid to create payroll
>>> behaviors.
>>>
>>
>> Hasn't Payroll been solved? I thought getting paid was one of the first
>> things that Software Engineers and Consultants, irrespective of
>> methodology, had got bug free.
>
> I think the rules and laws keep changing and are often State-specific.
> Anyhow, such is used as a training example regardless of whether there
> are off-the-shelf versions of it.
>
Hmmm! But shouldn't a Agile practitioner advocate buying in?
topmind
An interesting question. If buying off-the-shelf is the simplest
solution, perhaps they would. However, how do you know if the product
fits if you don't *yet* have the requirements? Requirements gathering
up-front generally is not considered agile. I would suggest asking an
Agile movement proponent.
-T-
Robert Martin
> Isolation creates duplication of concepts and can make it more
> difficult to use the existing power and abilities of RDBMS. Most of the
> code in your book is WASTED on translating back and forth between two
> medium-to-high-level concepts: OO and relational. It is like spending
> effort translating between Japanese and Spanish and back rather than
> get anything real done.
The payroll system in the book is partitioned into code that knows
about the DB schema, and code that does not. The dividing line is a
set of interfaces that translate high level concepts like "GetEmployee"
into appropriate SQL. To the left of the interfaces the code deals
with Employees. To the right the code deals with SQL, tables, rows,
and columns.
In any application, OO or not, this translation must take place. All
we have done with the code in the book is to assign a place for that
translation.
There is no duplication. There is no waste. There is simply a
separation of concerns. Those concerns would exist regardless of
whether they were separated or not.
Robert Martin
> Payroll behavior is producing a payment file to the bank, using data
> supplied by employees and adminstrators. The data is the important
> thing. Behavior is only the method of transforming data. Like many
> other business applications, it is all about providing information or
> data to different actors. The behavior of the application is low-level
> stuff that is not important on higher abstractation levels.
I suggest you test your hypothesis by creating a personnel database for
IBM and then writing the paychecks by hand. You will be allowed to
type SQL commands at the terminal to access the database. You will
also have the tax code for all the states and the federal government,
as well as all the insurance codes, union contracts, etc. You should
be able to write the paychecks easily with all that information since
there is not much behavior in the system.
fre...@gmail.com
> > supplied by employees and adminstrators. The data is the important
> > thing. Behavior is only the method of transforming data. Like many
> > other business applications, it is all about providing information or
> > data to different actors. The behavior of the application is low-level
> > stuff that is not important on higher abstractation levels.
>
> I suggest you test your hypothesis by creating a personnel database for
> IBM and then writing the paychecks by hand. You will be allowed to
> type SQL commands at the terminal to access the database. You will
> also have the tax code for all the states and the federal government,
> as well as all the insurance codes, union contracts, etc. You should
> be able to write the paychecks easily with all that information since
> there is not much behavior in the system.
The paychecks are a data structure. How they are produced and how they
are communicated to the receiver is just a low-level issue. As you
describe above, a payroll system may be implemented without use of
computers.
On a very hight abstractation level we can describe the requirements of
the system by defining the data model for the input data and the output
data, and data derivation rules. If we choose to use computer software
to implement it, is an implementation issue.
Fredrik Bertilsson
http://mybase.sf.net
topmind
> On 2007-01-21 13:59:25 -0600, "topmind" <top...@technologist.com> said:
>
> > Isolation creates duplication of concepts and can make it more
> > difficult to use the existing power and abilities of RDBMS. Most of the
> > code in your book is WASTED on translating back and forth between two
> > medium-to-high-level concepts: OO and relational. It is like spending
> > effort translating between Japanese and Spanish and back rather than
> > get anything real done.
>
> The payroll system in the book is partitioned into code that knows
> about the DB schema, and code that does not. The dividing line is a
> set of interfaces that translate high level concepts like "GetEmployee"
> into appropriate SQL. To the left of the interfaces the code deals
> with Employees. To the right the code deals with SQL, tables, rows,
> and columns.
>
> In any application, OO or not, this translation must take place. All
> we have done with the code in the book is to assign a place for that
> translation.
First off, this could be done without OOP. We could have functions that
wrap the SQL. Thus, it is not really an OO-specific thing.
>
> There is no duplication. There is no waste. There is simply a
> separation of concerns. Those concerns would exist regardless of
> whether they were separated or not.
It is additional code and likely additional work. The more beurocracy
you put between the RDBMS and the app code, the more places you will
often have to change. For example, if a new attribute or table is
needed for a given calculation, then likely there will be two 2 units
that need changing: the SQL along with the SQL wrapper's interface, and
the app code that uses it. However, if the SQL was together, then only
one unit needs changing. Thus, wrapping is more effort: one has to make
2 hops instead of one. These kinds of changes can and do happen quite
often. Swapping DB vendors is fairly rare. Thus, you are paying a
nearly GUARENTEED indirection tax of about 25% on on-going code
maintanence in order to prevent a roughly once-per-10-year event, and
such effort is only about a 10-day effort on medium projects (if you
combine the testing with general new-version testing). Thus, over a
10-year period, the heavy wrapping may cost at least 3 hours a week,
adding up to more than 1,000 hours in 10 years. This to prevent an
80-hour DB swap effort?[1] One would have to swap vendors roughly every
18 months to break even!
The economic calculatioins are just plain against this in most custom
application shops. It just does not add up. My version of your app
would be roughly 1/2 to 1/4 the same amount of code. Shorter code in
general is usually easier to learn, modify, test, understand, read, and
debug. Your code is full of "red tape". It is mostly martialing stuff
back and forth between instantiations and interfaces istead of doing
domain-related calculations. It smells of a programmer jobs program
better than any spend-happy liberal could ever pull off. (I shouldn't
mind from my perspective, but one does get bored dealing with bloated
red-tape code. I like to spend my time on real work, not red tape.)
I also would like to see your comments on taxonomy issues. (The
SQL-wrapping issue has been beaten to death on comp.object anyhow.)
Excerpt from my critique:
(begin quote)
Page 352 and 353: Figure 26-1 and Figure 26-2
Martin commits a common OO mistake of making a hierarchy of "employee
types", or at least "payment types" (hourly, commissioned, and
salaried). "Types" are often a poor modeling decision in business
applications because they cannot handle orthogonal traits very well.
Martin gives tons of lip service about making applications easier to
change without lots of code overhaul. However, hierarchical OO classes
are expensive to de-hierarchy.
In fact, I've witnessed first-hand an actual scenario that busts
Martin's hierarchy. I've worked at a place where it was decided that
any employee can receive sales bonus. If they sold the company's
products to their neighbors or friends, they qualified for commissions.
We live in a heavily sells-oriented capitalist society, so preparing
for such a situation should be a no-brainer.
If you look at my schema below, you will notice that there is nothing
that forces a mutually-exclusive choice of "payment types". The
equivalent of Martin's 3 classes is driven mostly by the "empRates"
table. If they are an hourly employee, then they have a corresponding
hourly rate row in the table. If they are salaried, then they have a
monthly rate (per specifications on page 350). If they get a sales
commission(s), then the commission rate(s) are also there. We are
making the design assumption that they are not necessarily mutually
exclusive.
You may ask what keeps somebody from being both an hourly and a
salaried (monthly) employee. If such combinations are not allowed, then
it can be prevented via data entry validation and/or database triggers.
The point is that we are not hard-wiring the allowed or disallowed
combinations into our basic design to give us feature flexibility.
Validating such combinations is treated also as mere data configuration
issue, and not a large-scale code feature.
(End Quote -- yuk, I need to rework some of my writing on that
website.)
[1] If one uses features that are very vendor-specifc, then DB vendor
swapping can take much longer. However, finding new-vendor ways to do
things the prior way is still going to be needed regardless of wether
you wrap or not. It is not effort wrappers save. Swapping in general
won't be free even under wrapping, so I may have understated my point
by not "charging" the wrapped version for swap hours.
>
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-t-
topmind
> On 2007-01-21 12:04:10 -0600, fre...@gmail.com said:
>
> > Payroll behavior is producing a payment file to the bank, using data
> > supplied by employees and adminstrators. The data is the important
> > thing. Behavior is only the method of transforming data. Like many
> > other business applications, it is all about providing information or
> > data to different actors. The behavior of the application is low-level
> > stuff that is not important on higher abstractation levels.
>
> I suggest you test your hypothesis by creating a personnel database for
> IBM and then writing the paychecks by hand. You will be allowed to
> type SQL commands at the terminal to access the database. You will
> also have the tax code for all the states and the federal government,
> as well as all the insurance codes, union contracts, etc. You should
> be able to write the paychecks easily with all that information since
> there is not much behavior in the system.
This is a straw-man argument. SQL-only is not what is being compared. I
*have* seen people do an awful lot of processing with just SQL.
However, I don't recommend such a heavy use, though. SQL in its current
form is not good enough for that (although a better relational language
could be). But the amount one can use SQL (or a query language) is like
a sliding scale. Nobody is recommending 100% SQL. Some UNDER-use the
query language and some OVER-use the query language. OO proponents
typically under-use it, preferring to use OOP programming instead.
As far as where to use queries and where to use imperative code (app
code), I already gave some rules-of-thumb in a nearby reply.
>
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
fre...@gmail.com
> > difficult to use the existing power and abilities of RDBMS. Most of the
> > code in your book is WASTED on translating back and forth between two
> > medium-to-high-level concepts: OO and relational. It is like spending
> > effort translating between Japanese and Spanish and back rather than
> > get anything real done.
>
> The payroll system in the book is partitioned into code that knows
> about the DB schema, and code that does not. The dividing line is a
> set of interfaces that translate high level concepts like "GetEmployee"
> into appropriate SQL. To the left of the interfaces the code deals
> with Employees. To the right the code deals with SQL, tables, rows,
> and columns.
How many getEmployeeBySomeCriteria methods do you think you will end up
with in a normal payroll application? Why do you want to hide predicate
logic and set operations behind a procedural interface?
> In any application, OO or not, this translation must take place.
Absolutely not.
> There is no duplication. There is no waste.
If you have a table employee and a class employee, you obviously have
duplication. If you have five variants of getEmployeeBySomeCriteria,
you obviously have duplication.
Fredrik Bertilsson
http://mybase.sf.net
topmind
> > > Payroll behavior is producing a payment file to the bank, using data
> > > supplied by employees and adminstrators. The data is the important
> > > thing. Behavior is only the method of transforming data. Like many
> > > other business applications, it is all about providing information or
> > > data to different actors. The behavior of the application is low-level
> > > stuff that is not important on higher abstractation levels.
> >
> > I suggest you test your hypothesis by creating a personnel database for
> > IBM and then writing the paychecks by hand. You will be allowed to
> > type SQL commands at the terminal to access the database. You will
> > also have the tax code for all the states and the federal government,
> > as well as all the insurance codes, union contracts, etc. You should
> > be able to write the paychecks easily with all that information since
> > there is not much behavior in the system.
>
> The paychecks are a data structure. How they are produced and how they
> are communicated to the receiver is just a low-level issue.
I've noticed that us tables-heads tend to view behavior as an
implimentation detail and the schema and attributes as the higher-level
abstraction/model, while OO'ers tend to do the reverse. Data-centric
programming tends to design domain-specific "languages" inside of
tables; and procedures "carry out" the orders or logic spefied by the
tables. The tables are kind of a "decision grid", and the procedures
simply implement those decisions dictacted by the grid. The procedures
are just an interpreter of our logic tables more or less.
The categories of employees or employee roles is in the tables. The
calculation sequences are in the tables (or at least can be). The
mapping of the employee role categories to calculation sequences is in
the tables. The code to combine all these is just carrying out the
commands or logic as dictated by the tables. JOINs and predicate logic
do most of the grunt work of selecting and combining these. We don't
create noun taxonomies of employees nor calculations in app code.
OO does the reverse. Wether one approach is inharently better or not, I
cannot say with certainty. I just know that the data-centric version
favors my brain because normalization is better documented and
understood for tables than for programming code; and because one can
use query languages, report writers, CRUD generators etc. to sift,
sort, search, and view the "logic tables" just about any damned way one
pleases, and thus are not at the mercy of your favorite view, Bill
Gates' favorite view, etc. but MY OWN view or more importantly, a
*situational* need. Programming code is not nearly as flexible, and
requires reinventing a (navigational) database to get such features.
All roads lead to Rome, guys. Charles Bachman would be proud of your
"object browsers".
I am a Frank Sanatra developer: I want to see it MY WAY! OO ain't no
gimme 'dat.
> Fredrik Bertilsson
> http://mybase.sf.net
-t-
Robert Martin
> On Sun, 21 Jan 2007 09:37:46 -0600, Robert Martin
> <uncl...@objectmentor.com> wrote:
>
>> On 2007-01-14 10:49:40 -0600, JXStern <JXSternC...@gte.net> said:
>>
>>> OK, I looked up the book, it's 2002. I probably glanced at it at some
>>> point. "Agile" goes back to iterative methods first popularized and
>>> formalized in the late 1970s.
>>
>> Iterative methods have been around since the late 50s. The term Agile
>> refers to a suite of practices that include iterative development.
>> Other practices in the Agile suite include Test Driven Develoment,
>> Refactoring, Simple Design, Pair Programming, Continuous Integration,
>> etc, etc.
>
> I mean the important principles go back - as far as you care to trace
> them, then.
>
> You mean, the term Agile was coined in the last few years to wrap up
> these old principles and some newer ones.
Yes, and surround them with an ideological framework.
>
>>> "Agile" has nothing to say about using
>>> one tool or another, or about RDBMS, pro or con.
>>
>> The principles of Agile design have implications for how to treat the
>> different components of systems architecture, including DBs. The term
>> "pro or con" has no meaning here.
>
> I deny any such claim even makes sense, other than making Agile a
> wrapper you can throw anything at all into.
My point was that "Agile" makes no judgements on whether a parcticular
tool is "good" or "bad" (i.e. pro/con). Rather it makes judgements
about how and when tools should be used.
Robert Martin
> Robert Martin wrote:
>>
>> In any application, OO or not, this translation must take place. All
>> we have done with the code in the book is to assign a place for that
>> translation.
>
> First off, this could be done without OOP. We could have functions that
> wrap the SQL. Thus, it is not really an OO-specific thing.
I quite agree. OO is just one of many potential technologies for
separating concerns. It happens to be one that is both popular an
effective.
>> There is no duplication. There is no waste. There is simply a
>> separation of concerns. Those concerns would exist regardless of
>> whether they were separated or not.
>
> It is additional code and likely additional work.
Very little "additional" code. Indeed, it might even be less code
since all the SQL is concentrated in one place rather than spread out
and duplicated. 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.
> The more beurocracy
> you put between the RDBMS and the app code, the more places you will
> often have to change.
So let's not have bureaucracy. Let's have a well defined interface
that acts as a partition rather than a mediator.
The partitioning of the code in the Payroll example is just that, a
partitioning. There is no vast bulk of "extra code". The database
code in the example is primarily concerned with generating and
executing SQL. That code would have to be SOMEWHERE in the application
irrespective of whether you use OO or not.
> For example, if a new attribute or table is
> needed for a given calculation, then likely there will be two 2 units
> that need changing: the SQL along with the SQL wrapper's interface, and
> the app code that uses it. However, if the SQL was together, then only
> one unit needs changing.
Let me translate this into procedural-speak. If a new attribute or
table is needed for a given calculation, then likely there will be two
places in the code that need changing. The SQL, along with the code
that moves the query results into convenient variables, and the app
code that uses those variables.
We can make sure that only one unit is changed by cramming all our code
into a single unit. Clearly that's not ideal. We have to have some
kind of partitioning scheme. The scheme I chose in the book was to
separate code that knows about database implementation details from
business rules.
> Thus, wrapping is more effort: one has to make
> 2 hops instead of one.
Wrapping is not more effort because it always needs to be done one way
or another. Either we pull the data out of queries an into objects, or
we pull the data into convenient variables.
> Swapping DB vendors is fairly rare.
Swapping DB vendors is a TEST, not a goal. You know you have isolated
the business rules from the DB implementation details if you can swap
the DB.
We can argue about whether or not it is wise to separate business rules
from the DB implementation. In many applications this might not be the
right choice. For many applications it is. There are many reasons why
such a separation might be beneficial.
1. Unit tests don't need the DB. This is actually a very big deal for
some applications.
2. DB code makes business rule code hard to read. This may or may not
be true depending on the language and platform you are using.
3. Changes to the database and schema need to be isolated from the
business rules. For example, the business rule code need not be
affected by a change from embedded SQL to stored procedures.
4. Different Expertise. The folks doing dataase queries may not be the
same folks who are writing the business rules. It would be nice if
they could play in different sandboxes.
5. Database tools sometimes require preprocessing or postprocessing of
the code. It would be nice if the business rule code were not involved
in such machinations.
etc. etc.
> I like to spend my time on real work, not red tape.
I agree. If maintaining the separation between Business Rules and
Database turns into a lot of red tape, then it should be eliminated. I
have certainly seen such red-tape implementations, and have gotten rid
of them for that reason. Most of the time that red-tape has more to do
with convoluted layering schemes and "clever" code generation
techniques, than with simple partitioning. The amount of red-tape in a
simple partitioning model is very limited.
> I also would like to see your comments on taxonomy issues.
I thought your comments were very intresting. There is indeed an
argument to be made for allowing every employee to enjoy every payment
scheme. Why shouldn't salaried employees be able to get commissions,
or submit overtime hours? If that were a requirement, then some
reworking of the payroll example would be in order.
What would we need to do? We'd simply put a collection of
PayClassification objects into each employee, and use the Composite
pattern to treat them as a single PayClassification. Within the
business rules themselves this would require no changes to any of the
existing modules. The CompositePayClassification would need to be
added. The individual transaction objects would then create and modify
employees with the Composite object instead of with the individuals.
This is simple, and keeps the code nicely partitioned. Changes to
salary policy do not affect changes to hourly policy, etc.
So, in fact, the "taxonomy" does not get in the way, and actually
facilitates the new mode of operation while keeping the code nicely
separated.
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Robert Martin
>>
>> The payroll system in the book is partitioned into code that knows
>> about the DB schema, and code that does not. The dividing line is a
>> set of interfaces that translate high level concepts like "GetEmployee"
>> into appropriate SQL. To the left of the interfaces the code deals
>> with Employees. To the right the code deals with SQL, tables, rows,
>> and columns.
>
> How many getEmployeeBySomeCriteria methods do you think you will end up
> with in a normal payroll application?
I imagine it will be quite a few, though fewer than the number of
embedded SQL statements that would exist if I did not put them behind
an interface.
> Why do you want to hide predicate
> logic and set operations behind a procedural interface?
I don't. I want to give the operations meaningful names. For example:
findEmployeesEligibleForRetirement()
is more evocative than a long SQL statement that doesn't mention
retirement at all. Think of the functions as compilable comments that
describe what the SQL beneath them is intended to do.
This has the additional benefit that when the eligibility rules change,
the callers of findEmployeeEligibleForRetirement() will be unaffected.
>
>> In any application, OO or not, this translation must take place.
>
> Absolutely not.
The data is on the disk. It must be translated into some kind of
TableRow structure or similar. Then it must be unpacked from that
structure into something convenient for the application to use.
Now it is entirely possible that the application will simply index into
the TableRow structure every time it wants to access the data; but even
that is an *implicit* translation into a more convenient form.
>> There is no duplication. There is no waste.
>
> If you have a table employee and a class employee, you obviously have
> duplication.
You have the same "duplication" if you have a table "employee", and a
set of convenient variables used to hold parts of one of the rows from
time to time. You even have it if you have a TableRow structure that
holds the employee row.
> If you have five variants of getEmployeeBySomeCriteria,
> you obviously have duplication.
I don't see that at all. The five functions may simply call a more
general function passing in specific parameters.
topmind
On Jan 23, 2:38 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2007-01-23 11:30:27 -0600, "topmind" <topm...@technologist.com> said:
>
> > Robert Martin wrote:
>
> >> In any application, OO or not, this translation must take place. All
> >> we have done with the code in the book is to assign a place for that
> >> translation.
>
> > First off, this could be done without OOP. We could have functions that
> > wrap the SQL. Thus, it is not really an OO-specific thing.I quite agree. OO is just one of many potential technologies for
> separating concerns. It happens to be one that is both popular an
> effective.
I have not seen actual example code of "effective".
>
> >> There is no duplication. There is no waste. There is simply a
> >> separation of concerns. Those concerns would exist regardless of
> >> whether they were separated or not.
>
> > It is additional code and likely additional work.Very little "additional" code. Indeed, it might even be less code
> since all the SQL is concentrated in one place rather than spread out
> and duplicated.
Where have I proposed duplicating SQL? One can put it into shared
functions, or perhaps use DB views. I still claim a p/r version would
be significantly less code. I suppose I'll have to code it up to prove
it to you.
> 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.
That request is like me asking to wrap the OO so that I can forget
about the OO and deal with the "business logic". You can claim that SQL
and RDBMS are "low level" all you want. But repetition of claim does
not make it true. 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.
>
> > The more beurocracy
> > you put between the RDBMS and the app code, the more places you will
> > often have to change.So let's not have bureaucracy. Let's have a well defined interface
> that acts as a partition rather than a mediator.
Its a Bloatiator in my book.
>
> The partitioning of the code in the Payroll example is just that, a
> partitioning. There is no vast bulk of "extra code". The database
> code in the example is primarily concerned with generating and
> executing SQL. That code would have to be SOMEWHERE in the application
> irrespective of whether you use OO or not.
Yes, but you create *unnecessary* extra cubbie holes for it, which
creates cubbie hole maintenance busy-work.
Plus, your instantiation adds code. Even if we did wrap the SQL,
procedural would be shorter in most cases.
// procedural
doSomething(foo);
// OOP
somethingDoer sd = new SomethingDoer()
sd.do(foo)
These add up to a fair amount of code in your app. It is anti-KISS. (It
could potentially be blamed partly on the spefic OO language.)
>
> > For example, if a new attribute or table is
> > needed for a given calculation, then likely there will be two 2 units
> > that need changing: the SQL along with the SQL wrapper's interface, and
> > the app code that uses it. However, if the SQL was together, then only
> > one unit needs changing.Let me translate this into procedural-speak. If a new attribute or
> table is needed for a given calculation, then likely there will be two
> places in the code that need changing. The SQL, along with the code
> that moves the query results into convenient variables, and the app
> code that uses those variables.
Please clearify. What kind of change are you thinking about?
>
> We can make sure that only one unit is changed by cramming all our code
> into a single unit. Clearly that's not ideal.
As a general rule of thumb, units should be divided mostly to avoid
repetition, not for the sake of dividing stuff because each choppage
results in interface overhead (parameter lists, etc.). It wastes time
and code on martialling stuff thru and back to and from the interfaces.
Some languages have nice features to reduce these, such as nested
functions. But that is another issue.
> We have to have some
> kind of partitioning scheme. The scheme I chose in the book was to
> separate code that knows about database implementation details from
> business rules.
>
> > Thus, wrapping is more effort: one has to make
> > 2 hops instead of one.
>
> Wrapping is not more effort because it always needs to be done one way
> or another. Either we pull the data out of queries an into objects, or
> we pull the data into convenient variables.
>
> > Swapping DB vendors is fairly rare.
>
> Swapping DB vendors is a TEST, not a goal. You know you have isolated
> the business rules from the DB implementation details if you can swap
> the DB.
One can test the module that calls the query.
>
> We can argue about whether or not it is wise to separate business rules
> from the DB implementation. In many applications this might not be the
> right choice. For many applications it is. There are many reasons why
> such a separation might be beneficial.
You have not showed your economic decision-making process. What are
your assumptions? What are your assumed frequencies of given change
scenarios, etc? I am not dismissing your factors, only saying they have
small weights compared to others in most cases.
>
> 1. Unit tests don't need the DB. This is actually a very big deal for
> some applications.
>
> 2. DB code makes business rule code hard to read. This may or may not
> be true depending on the language and platform you are using.
It does? This may be a subjective issue. It can make it easier to read
in my opinion.
>
> 3. Changes to the database and schema need to be isolated from the
> business rules. For example, the business rule code need not be
> affected by a change from embedded SQL to stored procedures.
Only if the cost-benefit weighings favor it. It depends on a lot of
issues.
>
> 4. Different Expertise. The folks doing dataase queries may not be the
> same folks who are writing the business rules. It would be nice if
> they could play in different sandboxes.
If more time was spent learning SQL and relational *instead* of OOP and
GOF patterns, then one perhaps would not need such a split. SQL can
express business logic quite concise at times.
>
> 5. Database tools sometimes require preprocessing or postprocessing of
> the code. It would be nice if the business rule code were not involved
> in such machinations.
>
> etc. etc.
Most of the time such *is* related to biz rules. I suppose we would
have to explore a scenario.
>
> > I like to spend my time on real work, not red tape.
>
> I agree. If maintaining the separation between Business Rules and
> Database turns into a lot of red tape, then it should be eliminated. I
> have certainly seen such red-tape implementations, and have gotten rid
> of them for that reason. Most of the time that red-tape has more to do
> with convoluted layering schemes and "clever" code generation
> techniques, than with simple partitioning. The amount of red-tape in a
> simple partitioning model is very limited.
>
> > I also would like to see your comments on taxonomy issues.
>
> I thought your comments were very intresting. There is indeed an
> argument to be made for allowing every employee to enjoy every payment
> scheme. Why shouldn't salaried employees be able to get commissions,
> or submit overtime hours? If that were a requirement, then some
> reworking of the payroll example would be in order.
My point is that removal of mutually-exclusive choices is a fairly
common change pattern. Polymorphism makes such more difficult than p/r.
>
> What would we need to do? We'd simply put a collection of
> PayClassification objects into each employee,
"Collection of"? Bit by bit you turn your app into a roll-your-own
database. And when auditors want a print-out of a given employee's
classifications? Do you reinvent report writers? Or you want to search
all employees with such and such conditions? Do you reinvent a little
query language for your classification collection? Sorting? Searching?
Printing?
OO tends to result in repetition of concepts like this:
class A {
method add;
method change;
method delete;
method search;
method sort;
method find;
method collectionVerbEtc;
}
class B {
method add;
method change;
method delete;
method search;
method sort;
method find;
method collectionVerbEtc;
}
class C {
method add;
method change;
method delete;
method search;
method sort;
method find;
method collectionVerbEtc;
}
class D {
method add;
method change;
method delete;
method search;
method sort;
method find;
method collectionVerbEtc;
}
> and use the Composite
> pattern to treat them as a single PayClassification. Within the
> business rules themselves this would require no changes to any of the
> existing modules. The CompositePayClassification would need to be
> added. The individual transaction objects would then create and modify
> employees with the Composite object instead of with the individuals.
>
> This is simple, and keeps the code nicely partitioned. Changes to
> salary policy do not affect changes to hourly policy, etc.
>
> So, in fact, the "taxonomy" does not get in the way, and actually
> facilitates the new mode of operation while keeping the code nicely
> separated.
>
> --
> Robert C. Martin (Uncle Bob) | email: uncle...@objectmentor.com
(Note: Google recently added some bugs to their message browser, and it
sometimes messes up the quote nesting and jams text together.)
-t-
Robert Martin
> Hasn't Payroll been solved? I thought getting paid was one of the first
> things that Software Engineers and Consultants, irrespective of
> methodology, had got bug free.
Spoken like someone who has never run a business.
Question: How do you get paid when the company you provided services
to goes out of business without warning?
You might think the risk of this is low, especially when the companies
are well-estabblished and well-known. Alas, that would be a
misaprehension.
--
Robert Martin
> My point being that one is not at all forced to use behavior as a
> criteria, there are other frameworks. And I see nothing in iterative
> or the portmanteau as RCM would have it of Agile, that necessitates
> behavior as a key.
The coat-rack of Agile doesn't care about the dichotomy of
behavior/data. The bifold-trunk of Agile is about very short
iterations, collaboration and teamwork, incremental testing, and many
other behaviors and techniques. The catmandu of Agile should really be
left out of this particular argument.
A computer is a device that turns data into behavior. Programs are
data that describe the behaviors that the computer will perform.
Software is about behavior.
This doesn't mean that data is unimportant or irrelevant; clearly data
is very important. Indeed, there are whole programs written to provide
behaviors that keep data safe and provide access to data (they are
called databases).
However, despite the deep importance of data, programs are still
descriptions of behavior.
Robert Martin
>>> Payroll behavior is producing a payment file to the bank, using data
>>> supplied by employees and adminstrators. The data is the important
>>> thing. Behavior is only the method of transforming data. Like many
>>> other business applications, it is all about providing information or
>>> data to different actors. The behavior of the application is low-level
>>> stuff that is not important on higher abstractation levels.
>>
>> I suggest you test your hypothesis by creating a personnel database for
>> IBM and then writing the paychecks by hand. You will be allowed to
>> type SQL commands at the terminal to access the database. You will
>> also have the tax code for all the states and the federal government,
>> as well as all the insurance codes, union contracts, etc. You should
>> be able to write the paychecks easily with all that information since
>> there is not much behavior in the system.
>
> The paychecks are a data structure. How they are produced and how they
> are communicated to the receiver is just a low-level issue.
Known as a program.
> As you
> describe above, a payroll system may be implemented without use of
> computers.
If we choose to use a computer, then we will need a program.
> On a very hight abstractation level we can describe the requirements of
> the system by defining the data model for the input data and the output
> data, and data derivation rules. If we choose to use computer software
> to implement it, is an implementation issue.
That particular implementation issue contains an entire engineering
discipline and science.
Robert Martin
> OO does the reverse. Wether one approach is inharently better or not, I
> cannot say with certainty.
That is the most mature statement I've seen you make.
In many ways OO is the reverse of procedural programming.
In procedural code dependencies flow in the direction of control.
In OO code dependencies flow against the direction of control.
In procedural code functions can be added to existing data structures
without changing the data structures.
In OO code data structures can be added to existing functions without
changing the functions.
People who are used to working with tables and data often build DSLs
out of the data and write programs using those higher level data
concepts.
People who are used to OO often write DSLs out of objects and write
programs using those higher level object concepts.
One way is not better than the other; but BOTH ways are better than just one.
Robert Martin
>
> lilburne wrote:
>> Robert Martin wrote:
>>
>> Hasn't Payroll been solved?
>
> I think so. I think you buy them these days. I don't know of any
> companies that would write their own payroll system anymore.
Remarkably, a lot do. Ironically, COTS software is sometimes more
painful to adapt to your needs than writing the whole applciation from
scratch.
Robert Martin
> The problem is that data and behavior are mostly interchangable.
The relationship is asymetric. All programs are data, but not all data
are programs.
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
topmind
> On 2007-01-23 15:28:32 -0600, "topmind" <topm...@technologist.com> said:
>
> > OO does the reverse. Wether one approach is inharently better or not, I
> > cannot say with certainty.
>
>That is the most mature statement I've seen you make.
>
> In many ways OO is the reverse of procedural programming.
>
> In procedural code dependencies flow in the direction of control.
> In OO code dependencies flow against the direction of control.
>
> In procedural code functions can be added to existing data structures
> without changing the data structures.
>
> In OO code data structures can be added to existing functions without
> changing the functions.
>
> People who are used to working with tables and data often build DSLs
> out of the data and write programs using those higher level data
> concepts.
I assume that DSL stands for "domain-specific language". Note that one
can also write DSL with functions also. Thus, one is not limited to
just DSL's using tables.
>
> People who are used to OO often write DSLs out of objects and write
> programs using those higher level object concepts.
>
> One way is not better than the other; but BOTH ways are better than just one.
But there are no clear, consensus criteria for when to use one over the
other. People's selection seems to be a personal preference. I am
afraid that the rules of thumb you suggest cannot be considered in
isolation such that one is weighing many factors, and I tend to
disagree with the weights you assign to some factors.
> --
> Robert C. Martin (Uncle Bob) | email: uncle...@objectmentor.com
-T-
Daniel Parker
> The problem is that data and behavior are mostly interchangable. For
> example, to the interpreter/compiler, a program *is* data. Actually,
> table-oriented techniques tend to build a kind of domain-specific
> interpreter, so the analogy does have some legs in app design.
>
department/employee records), semi-structured data (e.g. a document
broken down into paragraphs, sections, chapters), and unstructured
data. The first is well suited to relational representation, the
others not so.
Daniel Parker
http://servingxml.sourceforge.net/
topmind
I don't know if I agree with that regarding the document example. I do
agree the existing implementations are not very well geared for such,
but it is an implementation barrier, not a theoretical one. (Encoding a
document is a bit tricky no matter what data structure you use.)
>
> Daniel Parkerhttp://servingxml.sourceforge.net/
-T-
fre...@gmail.com
> > with in a normal payroll application?
>
>I imagine it will be quite a few,
Only a few ways of fetching employees? By name, by employment no, by
SSN, by department, by city.... But I guess that you will do it the OO
way, fetching all employees and select the instances you really want,
by traversing them and call a matcher/filter function. Performance is a
secondary issue.
> though fewer than the number of
> embedded SQL statements that would exist if I did not put them behind
> an interface.
What is the purpose with putting a statement like "select salary from
employee where SSN=?" behind an interface? You are substituting one
one-liner with another one-liner that needs an additional
implementation.
> > Why do you want to hide predicate
> > logic and set operations behind a procedural interface?
>
> I don't. I want to give the operations meaningful names. For example:
>
> findEmployeesEligibleForRetirement
This is neither predicate logic nor a set operation. You have given an
example of a function, which indeed is very useful (also together with
predicates).
> is more evocative than a long SQL statement that doesn't mention
> retirement at all. Think of the functions as compilable comments that
> describe what the SQL beneath them is intended to do.
A much better idea would be to create a view
EmployeesEligibleForRetirement. Views are much more flexible than
functions, because they can be combined together in other set
operations and logic statements. You might for example join this view
with the SalarayPayment relation. If you embedd the statement inside a
function, you don't have that kind of flexibility.
> This has the additional benefit that when the eligibility rules change,
> the callers of findEmployeeEligibleForRetirement() will be unaffected.
The same benefit exists if you create a view.
> >> In any application, OO or not, this translation must take place.
>
> > Absolutely not.
>
> The data is on the disk.
This is a common statement from people that lacks education about
modern databases. They think that the SQL statement
"select mycol from mytable", will cause the database to read something
from disk. In a well-tuned database, the data will most likely already
be in RAM.
> It must be translated into some kind of
> TableRow structure or similar. Then it must be unpacked from that
> structure into something convenient for the application to use.
>
> Now it is entirely possible that the application will simply index into
> the TableRow structure every time it wants to access the data; but even
> that is an *implicit* translation into a more convenient form.
You don't need a TableRow instance, just use select/fetch into. And if
you still prefer a result set, this class is generic. You don't have to
write it yourself.
> > If you have a table employee and a class employee, you obviously have
> > duplication.
>You have the same "duplication" if you have a table "employee", and a
> set of convenient variables used to hold parts of one of the rows from
> time to time. You even have it if you have a TableRow structure that
> holds the employee row.
TableRow is a generic class, employee is not.
> > If you have five variants of getEmployeeBySomeCriteria,
> > you obviously have duplication.
>I don't see that at all. The five functions may simply call a more
> general function passing in specific parameters.
Why do you want the five functions in the first place? If you have
general function, why not use that one from the beginning?
Fredrik Bertilsson
http://mybase.sf.net
fre...@gmail.com
> > the system by defining the data model for the input data and the output
> > data, and data derivation rules. If we choose to use computer software
> > to implement it, is an implementation issue.
>
> That particular implementation issue contains an entire engineering
> discipline and science.
One could also say that more than 90% of the employees in the world are
still getting paid by the manual system you described above. I am not
saying that behavior is not needed, I am only opposing your statement
that "we are being paid to create payroll behaviors". We are getting
paid to produce payroll data (paychecks). The customer doesn't care so
much about how (behavior) it is done.
The most stupid thing about OO is data hiding. Why should we hide the
stuff that are most important of all?
Fredrik Bertilsson
http://mybase.sf.net
Robert Martin
>> 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
> ...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.
--
Robert Martin
>>> How many getEmployeeBySomeCriteria methods do you think you will end up
>>> with in a normal payroll application?
>>
>> I imagine it will be quite a few,
>
> Only a few ways of fetching employees? By name, by employment no, by
> SSN, by department, by city.... But I guess that you will do it the OO
> way, fetching all employees and select the instances you really want,
> by traversing them and call a matcher/filter function. Performance is a
> secondary issue.
Who would do a dumb-ass thing like that? Sorry for the vulgarity but...
No, of course I would use the database to fetch the data I want. I'd
make sure that a well structure SQL statement was used against a
well-normalized database. Who wouldn't?
Then I would hide that SQL statement behind an interface so that the
rest of my application was unaware of it.
>
>> though fewer than the number of
>> embedded SQL statements that would exist if I did not put them behind
>> an interface.
>
> What is the purpose with putting a statement like "select salary from
> employee where SSN=?" behind an interface? You are substituting one
> one-liner with another one-liner that needs an additional
> implementation.
Consider this:
Select employee_number from employee where date_of_birth < 1952 and sex
= F and employment_type = EXEMPT OR emloyment_type = SPECIAL and salary
> 90000;
I'd like to hide this behind:
find_all_employees_eligible_for_early_retirement();
Firstly, it makes the program easier to understand. Secondly, it
isolates the policy from the implementation. I can change the
implementaiton of the SQL statement without affecting the functions
that call find_all_employees...
>> is more evocative than a long SQL statement that doesn't mention
>> retirement at all. Think of the functions as compilable comments that
>> describe what the SQL beneath them is intended to do.
>
> A much better idea would be to create a view
> EmployeesEligibleForRetirement. Views are much more flexible than
> functions, because they can be combined together in other set
> operations and logic statements. You might for example join this view
> with the SalarayPayment relation. If you embedd the statement inside a
> function, you don't have that kind of flexibility.
Agreed. However, it is not a "much better idea" it is a better way of
*implementing* the original idea. My aplication still needs the
function. You've just provided a better way to implement it.
>>>> In any application, OO or not, [a] translation must take place.
>>
>>> Absolutely not.
>>
>> The data is on the disk.
>
> This is a common statement from people that lacks education about
> modern databases. They think that the SQL statement
> "select mycol from mytable", will cause the database to read something
> from disk. In a well-tuned database, the data will most likely already
> be in RAM.
<eye roll>
Really? Gosh! I didn't know that!
</eye roll>
>
>> It must be translated into some kind of
>> TableRow structure or similar.
> You don't need a TableRow instance, just use select/fetch into. And if
> you still prefer a result set, this class is generic. You don't have to
> write it yourself.
Great! Then I can pass the convenient data structure around my
application just like an object. How convenient!
>>> If you have five variants of getEmployeeBySomeCriteria,
>>> you obviously have duplication.
>> I don't see that at all. The five functions may simply call a more
>> general function passing in specific parameters.
>
> Why do you want the five functions in the first place?
So I can give them meaningful names.
Robert Martin
>> One way is not better than the other; but BOTH ways are better than just one.
>
> But there are no clear, consensus criteria for when to use one over the
> other.
You don't use one OVER the other, you use the two to complement each other.
> People's selection seems to be a personal preference.
Actually, there is a rather large body of knowledge published about how
to use the two together. Consider, for example, Fowler's "Patterns of
Enterprise Application Architecture" for starters.
You may be vocal, Bryce, but you are in a profoundly parochial minority.
--
Robert Martin
> I am not
> saying that behavior is not needed, I am only opposing your statement
> that "we are being paid to create payroll behaviors". We are getting
> paid to produce payroll data (paychecks).
Interesting point of view.
Now back to reality. We are being paid to transform data in one form,
into data in another form. The fact that the end result is data is
certainly the end goal of our user. We are being paid, however, to
produce the data the enables the transformation. (i.e. the program).
> The most stupid thing about OO is data hiding. Why should we hide the
> stuff that are most important of all?
(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/)
JXStern
<uncl...@objectmentor.com> wrote:
>> I deny any such claim even makes sense, other than making Agile a
>> wrapper you can throw anything at all into.
>
>My point was that "Agile" makes no judgements on whether a parcticular
>tool is "good" or "bad" (i.e. pro/con). Rather it makes judgements
>about how and when tools should be used.
I deny that it makes even a little bit of sense to say that Agile
offers any judgement on when and whether to use RDBMS. You're
overloading the term "Agile" to link unrelated advice in random
directions.
J.
topmind
Robert Martin wrote:
> On 2007-01-23 18:11:25 -0600, "topmind" <top...@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.
At least I entertain the possibility that tables are a subjective
preference.
>
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
topmind
> Consider this:
>
> Select employee_number from employee where date_of_birth < 1952 and sex
> = F and employment_type = EXEMPT OR emloyment_type = SPECIAL and salary
> > 90000;
>
> I'd like to hide this behind:
>
> find_all_employees_eligible_for_early_retirement();
>
> Firstly, it makes the program easier to understand.
Do you think that those who disagree WANT hard-to-understand programs?
Hell, if I WANTED hard-to-understand programs, I would happily use OO
and have a GOF party. Perhaps SQL trips you up, but you have to be
careful which psychology of yours you extrapolate to other human
beings. I find Perl a tangled mess of non-neumonic symbols and weird
rules, but some love Perl and are incredably productive with it.
> Secondly, it
> isolates the policy from the implementation. I can change the
> implementaiton of the SQL statement without affecting the functions
> that call find_all_employees...
But you fail to consider simplicity. If such a statement is only used
*once*, then wrapping it in a function/method creates more code and
more red tape. That creates confusion and slower productivity in
itself. It is not a free lunch.
I agree that if it is used several times, then it makes sense to put it
into a shared function. But you seem to want to wrap ever last one.
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
topmind
On Jan 25, 4:49 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2007-01-23 23:04:15 -0600, "topmind" <topm...@technologist.com> said:
>
> >> One way is not better than the other; but BOTH ways are better than just one.
>
> > But there are no clear, consensus criteria for when to use one over the
> > other.
>
> You don't use one OVER the other, you use the two to complement each other.
OO does not compliment relational. Trivial OO is simpler redone as
procedural instead, and complex OO is best moved to tables to manage
the interelationships of structures and ideas and domain noun
classification systems.
>
> > People's selection seems to be a personal preference.
>
> Actually, there is a rather large body of knowledge published about how
> to use the two together. Consider, for example, Fowler's "Patterns of
> Enterprise Application Architecture" for starters.
I have looked at Fowler's works, and found a lot of suspicous designs.
He hates RDBMS almost as much as you. If you found a sure-shot example,
please bring it up.
>
> You may be vocal [....] but you are in a profoundly parochial minority.
1. Being popular is not the same as being good. Examples bound (cough
M1crosoft cough). Another example: Hard-core OO fans tend to prefer
Smalltalk over Java and Python, but popularity does not agree.
2. OO gets a lot more LIP SERVICE than actual use. A good many OO
proponents complain that a lot of production Java code is "procedural
cross-dressing as OO". OO is kind of like vegatibles: the doctors keep
saying they are good for you and one will claim to eat them, but most
ignore them in practice. (The analogy ends there: unlike OO, vegitables
are good for you.)
>
> --
> Robert C. Martin (Uncle Bob) | email: uncle...@objectmentor.com
-T-
topmind
>
> (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. 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.)
>
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
Patrick May
> On Jan 23, 2:38 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>> Very little "additional" code. Indeed, it might even be less code
>> since all the SQL is concentrated in one place rather than spread
>> out and duplicated.
>
> Where have I proposed duplicating SQL? One can put it into shared
> functions, or perhaps use DB views. I still claim a p/r version
> would be significantly less code. I suppose I'll have to code it up
> to prove it to you.
I, for one, would be very interested in seeing this. It would
clarify a lot of the discussion points. If you do provide such code,
please recognize that using Open Source or otherwise readily available
languages and RDBMSs will be much more useful than implementing in a
proprietary environment.
I look forward to seeing your implementation.
Sincerely,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
p...@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
fre...@gmail.com
> >>> with in a normal payroll application?
>
> >> I imagine it will be quite a few,
>
> > Only a few ways of fetching employees? By name, by employment no, by
> > SSN, by department, by city.... But I guess that you will do it the OO
> > way, fetching all employees and select the instances you really want,
> > by traversing them and call a matcher/filter function. Performance is a
> > secondary issue.
>
> Who would do a dumb-ass thing like that? Sorry for the vulgarity but...
When I encounter this type of implementations, the main reason is
because they want to limit the number of getEmployeeBySomeCriteria
methods. Another reason is because they want to work with an objects
graphs instead of relational calculus.
> No, of course I would use the database to fetch the data I want. I'd
> make sure that a well structure SQL statement was used against a
> well-normalized database. Who wouldn't?
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.
> Then I would hide that SQL statement behind an interface so that the
> rest of my application was unaware of it.
And the benifits are?
> > What is the purpose with putting a statement like "select salary from
> > employee where SSN=?" behind an interface? You are substituting one
> > one-liner with another one-liner that needs an additional
> > implementation.Consider this:
>
> Select employee_number from employee where date_of_birth < 1952 and sex
> = F and employment_type = EXEMPT OR emloyment_type = SPECIAL and salary > 90000;
> I'd like to hide this behind:
>
> find_all_employees_eligible_for_early_retirement();
This should obviously be a view. After creating that view you might use
it in other queries.
select date, amount from payment p join
employee_eligible_for_early_retirement e on p.id=e.id
Your solution would cause extra roundtrips to the database for fetching
the same data.
> Firstly, it makes the program easier to understand. Secondly, it
> isolates the policy from the implementation. I can change the
> implementaiton of the SQL statement without affecting the functions
> that call find_all_employees...
A view would have the same benefits.
> >> is more evocative than a long SQL statement that doesn't mention
> >> retirement at all. Think of the functions as compilable comments that
> >> describe what the SQL beneath them is intended to do.
Why do you ignore the existance of views?
> > A much better idea would be to create a view
> > EmployeesEligibleForRetirement. Views are much more flexible than
> > functions, because they can be combined together in other set
> > operations and logic statements. You might for example join this view
> > with the SalarayPayment relation. If you embedd the statement inside a
> > function, you don't have that kind of flexibility.
> Agreed. However, it is not a "much better idea" it is a better way of
> *implementing* the original idea. My aplication still needs the
> function.
Your application does not need the function. Just call
select * from employee_eligible_for_early_retirement
> >> It must be translated into some kind of
> >> TableRow structure or similar.
> > You don't need a TableRow instance, just use select/fetch into. And if
> > you still prefer a result set, this class is generic. You don't have to
> > write it yourself.
> Great! Then I can pass the convenient data structure around my
> application just like an object. How convenient!
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.
Fredrik Bertilsson
http://mybase.sf.net
Thomas Gagne
> <snip>
>
>> No, of course I would use the database to fetch the data I want. I'd
>> make sure that a well structure SQL statement was used against a
>> well-normalized database. Who wouldn't?
>>
>
> 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.
>
>
number of getemployeBySomeCriteria() methods that doesn't encroach on
becoming a report writer? All our reports have been implemented as
stored procedures and have been meticulously crafted to perform well and
balance to other reports. There are many similarly-named reports but
the user doesn't really see that because they navigate through the data
starting at the top-level and drilling-down.
If there really was a requirement for ad-hoc getEmployee() methods than
an ad-hoc or report-writing tool is needed--and that's a different kind
of application than a business application like accounting, mortgages,
finance, statements, etc... don't you think?
>> Then I would hide that SQL statement behind an interface so that the
>> rest of my application was unaware of it.
>>
>
> And the benifits are?
>
Plentiful. Didn't we discuss this in "Databases as objects?" The
biggest difference between Martin's and my approaches in this area is my
belief the system starts with the data model and his starts with an
behavioral model. Mind you, that's not a trivial difference...
--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.
Robert Martin
Not at all. One of the fundamental rules of Agile is YAGNI, "You
Aren't Going to Need It." In short, this rule says that you should not
include support for something just because you think you are going to
need it. Only provide support for what you need right now.
We used this advice in the development of FitNesse (www.fitnesse.org).
Early on we were pretty sure we'd need some kind of database; but since
the early features of the system didn't require persitence, we didn't
select or implement a database.
Later in the development we started needing the ability for simple
queries, but we still didn't need persistence. Since the queries were
simple (just name lookups) we created a data lookup interface and
implemented it with a hashmap.
Still later we started needing longer term persistence, but nothing
very elaborate, so we reimplemented the data lookup interface with a
flat file system.
We've never needed anything more than that. We didn't know this when
we started. We thought we'd need an RDBMS back end; but that just
never turned out to be the case.
I have also written other applications in which the decision to go to
an RDBMS was made very early, because the features clearly required it.
Not features for the future, but features for right now.
So, Agile DOES provide guidance about when and where to use tools like RDMBSs.
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Robert Martin
> 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.
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
fre...@gmail.com
> > 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.
>
> Can you give an example of an application that would have an excessive
> number of getemployeBySomeCriteria() methods that doesn't encroach on
> becoming a report writer?
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. Lets say we have a function sending information to
insurance company about changes in salaries, we need a way to find
employees with changed salary. How could you possible solve this only a
few functions for finding employees?
> All our reports have been implemented as
> stored procedures and have been meticulously crafted to perform well and
> balance to other reports. There are many similarly-named reports but
> the user doesn't really see that because they navigate through the data
> starting at the top-level and drilling-down.
Are there any significant difference between producing data on a paper,
displaying it on a computer screen or using it in a thread sending
e-mails? I have seen systems like you describe above. The only way to
access a lot of the information was to print it, or get it as a large
PDF-file. It so 60's.
> If there really was a requirement for ad-hoc getEmployee() methods
What's ad-hoc about set theory and predicate logic?
Fredrik Bertilsson
http://mybase.sf.net
topmind
On Jan 26, 12:59 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2007-01-25 22:23:23 -0600, JXStern <JXSternChange...@gte.net> said:
>
> > On Tue, 23 Jan 2007 15:43:12 -0600, Robert Martin
> > <uncle...@objectmentor.com> wrote:
>
> >>> I deny any such claim even makes sense, other than making Agile a
> >>> wrapper you can throw anything at all into.
>
> >> My point was that "Agile" makes no judgements on whether a parcticular
> >> tool is "good" or "bad" (i.e. pro/con). Rather it makes judgements
> >> about how and when tools should be used.
>
> > I deny that it makes even a little bit of sense to say that Agile
> > offers any judgement on when and whether to use RDBMS. You're
> > overloading the term "Agile" to link unrelated advice in random
> > directions.
>
> Not at all. One of the fundamental rules of Agile is YAGNI, "You
> Aren't Going to Need It." In short, this rule says that you should not
> include support for something just because you think you are going to
> need it. Only provide support for what you need right now.
Then why do you wrap all your SQL behind classes, methods etc? Was that
an up-front need? Yagni adherence would dictate waiting until you
actually need wrapping. (By the way, I somewhat disagree with Yagni. It
is a good rule of thumb, but should not be sought dogmatically.
Software development is about weighing gajillion tradeoffs. It's a
tradeoff weighting symphony, You don't bang on just one piano key.)
>
> We used this advice in the development of FitNesse (www.fitnesse.org).
> Early on we were pretty sure we'd need some kind of database; but since
> the early features of the system didn't require persitence, we didn't
> select or implement a database.
>
> Later in the development we started needing the ability for simple
> queries, but we still didn't need persistence. Since the queries were
> simple (just name lookups) we created a data lookup interface and
> implemented it with a hashmap.
>
> Still later we started needing longer term persistence, but nothing
> very elaborate, so we reimplemented the data lookup interface with a
> flat file system.
>
> We've never needed anything more than that. We didn't know this when
> we started. We thought we'd need an RDBMS back end; but that just
> never turned out to be the case.
It sounds like FitNesse could have still used a database, or at least
it is close to the borderline. Making logs, reports, and querying is
almost always helpful even if not absolutely necessary. When you scale,
you will almost certainly start needing DB-like freatures, such as
multi-user concurrency and the above.
>
> I have also written other applications in which the decision to go to
> an RDBMS was made very early, because the features clearly required it.
> Not features for the future, but features for right now.
>
> So, Agile DOES provide guidance about when and where to use tools like RDMBSs.
>
> --
> Robert C. Martin (Uncle Bob) | email: uncle...@objectmentor.com
-T-
Robert Martin
>
> Robert Martin wrote:
>> On 2007-01-24 01:35:40 -0600, fre...@gmail.com said:
>
>> Consider this:
>>
>> Select employee_number from employee where date_of_birth < 1952 and sex
>> = F and employment_type = EXEMPT OR emloyment_type = SPECIAL and salary
>> > 90000;
>>
>> I'd like to hide this behind:
>>
>> find_all_employees_eligible_for_early_retirement();
>>
>> Firstly, it makes the program easier to understand.
>
> Do you think that those who disagree WANT hard-to-understand programs?
No. What does that have to do with my statement?
> Hell, if I WANTED hard-to-understand programs, I would happily use OO
> and have a GOF party.
Naughty, Naughty. You know full well that design patterns can either
obscure or clarify depending on how they are used.
> Perhaps SQL trips you up,
No.
> but you have to be
> careful which psychology of yours you extrapolate to other human
> beings.
You are completely missing the point. The Select statment above is
loaded with detail. (DOB, salary, emloyee type etc). The function
simply named the policy. Hiding that detail behind the policy name is
a good, and very old, engineering discipline.
> I find Perl a tangled mess of non-neumonic symbols and weird
> rules, but some love Perl and are incredably productive with it.
Sure. Any language is clear once you know it.
>
>> Secondly, it
>> isolates the policy from the implementation. I can change the
>> implementaiton of the SQL statement without affecting the functions
>> that call find_all_employees...
>
> But you fail to consider simplicity. If such a statement is only used
> *once*, then wrapping it in a function/method creates more code and
> more red tape. That creates confusion and slower productivity in
> itself. It is not a free lunch.
1. That's a big if.
2. Putting a select statement into a function requires a negligible
amount of code that has a one-time negligible cost.
3. Giving the select statement a name reduces confusion and increases
productivity every time the statement is read.
> I agree that if it is used several times, then it makes sense to put it
> into a shared function. But you seem to want to wrap ever last one.
In general I do. For any number of different reasons.
1. It's clearer.
2. It's easier to test since I can replace the function implementations
with canned data.
3. I can deploy the business rules that call the functions separately
from the SQL that implements the functions. (This is a big deal for
most medium to large systems, and even has significant impact on
smaller systems)
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Robert Martin
>>>>> How many getEmployeeBySomeCriteria methods do you think you will end up
>>>>> with in a normal payroll application?
>>
>>>> I imagine it will be quite a few,
>>
>>> Only a few ways of fetching employees? By name, by employment no, by
>>> SSN, by department, by city.... But I guess that you will do it the OO
>>> way, fetching all employees and select the instances you really want,
>>> by traversing them and call a matcher/filter function. Performance is a
>>> secondary issue.
>>
>> Who would do a dumb-ass thing like that? Sorry for the vulgarity but...
>
> When I encounter this type of implementations, the main reason is
> because they want to limit the number of getEmployeeBySomeCriteria
> methods. Another reason is because they want to work with an objects
> graphs instead of relational calculus.
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.
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.
> 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".
>
>> Then I would hide that SQL statement behind an interface so that the
>> rest of my application was unaware of it.
>
> And the benifits are?
1. Separation of concerns makes both sides more readable.
2. Both sides can be tested independently of the other.
3. Either side can be deployed independently of the other (meaning at
differen times) allowing me to fix bugs, or add features, to one side
without redeploying the other.
etc.
> 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.
Robert Martin
> The biggest difference between Martin's and my approaches in this area
> is my belief the system starts with the data model and his starts with
> an behavioral model. Mind you, that's not a trivial difference...
Indeed not. We should debate that one day. ;-)
Robert Martin
> I have looked at Fowler's works, and found a lot of suspicous designs.
> He hates RDBMS almost as much as you. If you found a sure-shot example,
> please bring it up.
Neither Martin nor I hate RDBMSs. Martin's book on Patterns of
Enterprise Architecture is largely about techniques for using RDBMSs in
web based systems written in Java and .NET.
As for "suspicious designs", I think you should point them out rather
than broad brush the man's work with your incorrect assumption of his
hatreds.
--
Robert Martin
> Being popular is not the same as being good.
Neither is being unpopular. But this conversation has left the arena
of substance.
--
Robert Martin
> OO gets a lot more LIP SERVICE than actual use. A good many OO
> proponents complain that a lot of production Java code is "procedural
> cross-dressing as OO". OO is kind of like vegatibles: the doctors keep
> saying they are good for you and one will claim to eat them, but most
> ignore them in practice. (The analogy ends there: unlike OO, vegitables
> are good for you.)
Actually, it's "conscientious design" that are the vegetables. It's not
that many programmers don't use OO; it's that many programmers barely
know how to write programs period. The daily WTF just scratches the
surface.
You, Bryce, have undertaken this jihad to rid the world of OO without
really understanding what you are disparaging. Your claims about
taxonomies, and mutually exclusive hierarchies show a distinct naivete
regarding the discipline of OOD. Your casually negative comments about
GOF indicate that your examination of the field has been cursory at
best.
In short, you are too loud about something you know too little about.
--
Robert Martin
>
> Robert Martin wrote:
>> On 2007-01-24 06:10:30 -0600, fre...@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: uncl...@objectmentor.com
topmind
Robert Martin wrote:
> On 2007-01-25 22:53:48 -0600, "topmind" <top...@technologist.com> said:
>
> >
> > Robert Martin wrote:
> >> On 2007-01-24 01:35:40 -0600, fre...@gmail.com said:
> >
> >> Consider this:
> >>
> >> Select employee_number from employee where date_of_birth < 1952 and sex
> >> = F and employment_type = EXEMPT OR emloyment_type = SPECIAL and salary
> >> > 90000;
> >>
> >> I'd like to hide this behind:
> >>
> >> find_all_employees_eligible_for_early_retirement();
> >>
> >> Firstly, it makes the program easier to understand.
> >
> > Do you think that those who disagree WANT hard-to-understand programs?
>
> No. What does that have to do with my statement?
You are implying that we don't know the difference between "easy to
understand" and "hard to understand", and that is why we don't wrap
more. I know pretty well after all these years what trips me up and
what doesn't. What I cannot do is heavily extrapolate that to everybody
else because brains are too different.
> > Perhaps SQL trips you up,
>
> No.
>
> > but you have to be
> > careful which psychology of yours you extrapolate to other human
> > beings.
>
> You are completely missing the point. The Select statment above is
> loaded with detail. (DOB, salary, emloyee type etc). The function
> simply named the policy. Hiding that detail behind the policy name is
> a good, and very old, engineering discipline.
Not every damned detail under the sun. This sounds similar to a debate
that raged on C2 a few years ago:
http://c2.com/cgi/wiki?HeadlinesTechnique
http://c2.com/cgi/wiki?LongFunctionsDiscussion
> >> Secondly, it
> >> isolates the policy from the implementation. I can change the
> >> implementaiton of the SQL statement without affecting the functions
> >> that call find_all_employees...
> >
> > But you fail to consider simplicity. If such a statement is only used
> > *once*, then wrapping it in a function/method creates more code and
> > more red tape. That creates confusion and slower productivity in
> > itself. It is not a free lunch.
>
> 1. That's a big if.
> 2. Putting a select statement into a function requires a negligible
> amount of code that has a one-time negligible cost.
It adds code, interface maitaining layers, and fill up the "function
space".
> 3. Giving the select statement a name reduces confusion and increases
> productivity every time the statement is read.
Not specific enough. Too much clutter slows me down, and superfulous
chunk-a-tizing creates clutter.
>
> > I agree that if it is used several times, then it makes sense to put it
> > into a shared function. But you seem to want to wrap ever last one.
>
> In general I do. For any number of different reasons.
>
> 1. It's clearer.
By what metric? You again seem to be extrapolating your personal
preferences to others.
> 2. It's easier to test since I can replace the function implementations
> with canned data.
I see no reason to test at such a small level. Testing an SQL statement
outside of the context of the app is of marginal use anyhow. Do you
wrap every math formula and reg-ex also?
// RCM lampoon code
...
x = addThreeNumbers(a, b, c);
...
function addThreeNumbers(a, b, c) {
return(a + b + c);
}
> 3. I can deploy the business rules that call the functions separately
> from the SQL that implements the functions. (This is a big deal for
> most medium to large systems, and even has significant impact on
> smaller systems)
Please clarify.
>
>
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
topmind
Robert Martin wrote:
> On 2007-01-25 23:12:11 -0600, "topmind" <top...@technologist.com> said:
>
> >
> > Robert Martin wrote:
> >> On 2007-01-24 06:10:30 -0600, fre...@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: uncl...@objectmentor.com
-T-
Daniel Parker
On Jan 26, 4:37 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2007-01-26 11:42:52 -0600, freb...@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/
topmind
Robert Martin wrote:
> On 2007-01-25 22:42:58 -0600, "topmind" <top...@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: uncl...@objectmentor.com
-T-
topmind
Robert Martin wrote:
> On 2007-01-25 23:06:28 -0600, "topmind" <top...@technologist.com> said:
>
> > OO gets a lot more LIP SERVICE than actual use. A good many OO
> > proponents complain that a lot of production Java code is "procedural
> > cross-dressing as OO". OO is kind of like vegatibles: the doctors keep
> > saying they are good for you and one will claim to eat them, but most
> > ignore them in practice. (The analogy ends there: unlike OO, vegitables
> > are good for you.)
>
> Actually, it's "conscientious design" that are the vegetables. It's not
> that many programmers don't use OO; it's that many programmers barely
> know how to write programs period. The daily WTF just scratches the
> surface.
>
> really understanding what you are disparaging. Your claims about
> taxonomies, and mutually exclusive hierarchies show a distinct naivete
> regarding the discipline of OOD. Your casually negative comments about
> GOF indicate that your examination of the field has been cursory at
> best.
>
> In short, you are too loud about something you know too little about.
The problem is YOU, not me. You either don't understand the scientific
process, or don't care to use it. For example, you have repeatedly
insisted that wrapping SQL in methods/functions makes "programs easier
to understand". Attempts at clarification have been fruitless. Thus,
the possibility that you are mistaking personal preference in OO as
objective evidence is quite high.
And, your rudeness made me sorry I bought your damned book and put
money into your patronizing little pocket.
OO needs good teachers, not mean preachers.
-T-
AndyW
wrote:
Now now ladies - no need for the handbags fight.
AndyW
wrote:
>
>Robert Martin wrote:
>> On 2007-01-23 18:11:25 -0600, "topmind" <top...@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
fre...@gmail.com
> >> rest of my application was unaware of it.
>> And the benifits are?
> 1. Separation of concerns makes both sides more readable.
Do you have something to back this up?
> 2. Both sides can be tested independently of the other.
I don't understand why OO people insits testing their application
without the database. Most business applications are a rather thin
layer babysitting a database. Testing that layer without the database
is rather useless.
> 3. Either side can be deployed independently of the other (meaning at
> differen times) allowing me to fix bugs, or add features, to one side
> without redeploying the other.
> etc.
Views (and stored procedures) are deployeable indepentently of the
application. But I not sure I understand why deploying different parts
of the application indepently is so very important.
> > 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.
Ok, so you finally agree that using classes as data structures is a bad
idea?
> An object is a relation, and it is very convenient to use.
>From http://en.wikipedia.org/wiki/Relational_model:
"A relation is defined as a set of n-tuples". Do you claim that "an
object is defined as a set of n-tuples". (Or maybe you claim that an
object is one n-tuple?) How do you apply joins, projections and
selections to objects? Now you are trying to do the same as Lahman:
After realizing that set operations and predicate logic are superior to
the network model, you are trying to hijack the relational model.
Fredrik Bertilsson
http://mybase.sf.net
Dmitry A. Kazakov
Relation is an operation over objects in a model which would implement RA.
But also a relation can be an object in some higher-level model. Even SQL
has that level, consider CREATE TABLE as an operation over relations as
object. The advantage of OO is that you can mix models more freely. For
that matter RA is much more limiting framework. Just consider expressing
arithmetic, image processing, or for that matter CREATE TABLE in terms of
RA!
I cannot tell if OO [~ subtyping relation and dispatch] could be
represented in RA. (The reverse is clearly possible) Which would make
Robert's argument *formally* correct. But in spirit it is, being old known:
"we all are Turing-complete, guys."
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Patrick May
>> >> Then I would hide that SQL statement behind an interface so that
>> >> the rest of my application was unaware of it.
>>> And the benifits are?
>
>> 1. Separation of concerns makes both sides more readable.
>
> Do you have something to back this up?
Experience. Treating the SQL code and stored procedures as
services used by the non-relational (OO, procedural, functional, or
what have you) code makes both simpler in terms of the number of
concepts being managed, shorter, and therefore more readable relative
to the alternative. When SQL is mixed with non-relational code,
anyone reading the code has to change context repeatedly from database
access to translation to application logic. This is less readable.
>> 2. Both sides can be tested independently of the other.
>
> I don't understand why OO people insits testing their application
> without the database.
1. It's faster, which means more tests get run, which means higher
quality.
2. The database schema and the application logic change for different
reasons. Decoupling the two minimizes the impact of those
changes.
3. The database isn't always available to application developers,
particularly when working remotely or off the network. (While it
is possible to install a subset of the database on a laptop, it's
much easier to simply mock it out.)
> Most business applications are a rather thin layer babysitting a
> database.
Do you have something to back this up? ;-)
Seriously, you seem to be using "business application" as a
synonym for CRUD application. This makes sense if you agree with
Bryce's recent claim that Eclipse is "systems software", but it
doesn't reflect what I consider business applications.
Do you consider telco OSS/BSS systems to be business
applications? Trading systems? Order management systems? I've
worked on all of these relatively recently, they all make use of an
RDBMS, but by no means are they a thin layer babysitting it.
>> 3. Either side can be deployed independently of the other (meaning
>> at differen times) allowing me to fix bugs, or add features, to one
>> side without redeploying the other. etc.
>
> Views (and stored procedures) are deployeable indepentently of the
> application. But I not sure I understand why deploying different
> parts of the application indepently is so very important.
It is absolutely essential in large, or even medium-sized
systems, both in development and deployment. Maintainability and
extensibility are core non-functional requirements. The financial
impact and risk to the business of "Shut down everything and
reinstall." is not a viable mechanism for meeting those NFRs.
Regards,
Patrick May
> Robert Martin wrote:
>> 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?
I suggest "developers who understand and have experience with
multiple paradigms and who therefore can make the appropriate
engineering trade-offs to achieve their customers' goals and provide
the maximum business value given the specific problem domain and
context." You could shorten that to "well-rounded programmers" if you
like.
I don't know anyone who understands object-orientation who also
insists that it is the one true and only approach to use in all
situations. That "one trick pony" attitude seems to be prevalent only
among those who know only one trick.
>> 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.
This approach is not unique to nor was it invented by procedural
or relational programmers. It is a standard design technique used in
a variety of paradigms. See message-oriented middleware, SOA (Jini in
particular), and even CORBA for examples.
Sincerely,
Daniel Parker
wrote:
> Relation is an operation over objects in a model which would implement RA.
I don't know what that means. In RA, a relation is defined as a set,
whose members are tuples. Operations (restriction, join, projection
etc.) can be applied to relations, which produce other relations.
Daniel
fre...@gmail.com
> anyone reading the code has to change context repeatedly from database
> access to translation to application logic. This is less readable.
Can you please give some example? Are you talkning about the fact that
some environments force you to write SQL statements as strings? Or the
fact that interfaces like JDBC is too low-level?
> > I don't understand why OO people insits testing their application
> > without the database.
> 1. It's faster, which means more tests get run, which means higher
> quality.
Are really test performance a factor that should have impact on how to
design software?
> 2. The database schema and the application logic change for different
> reasons. Decoupling the two minimizes the impact of those
> changes.
Do you have some examples of such change (that could not be solved
using views)?
> 3. The database isn't always available to application developers,
> particularly when working remotely or off the network. (While it
> is possible to install a subset of the database on a laptop, it's
> much easier to simply mock it out.)
If the database isn't availible for developers, I suggest solving that
problem instead of changing the way you design software. Installing a
full database on a laptop has not been a problem for the last 10
years. Eclipse uses more memory and CPU on my laptop than my SQL
Server, Oracle, Postgres and MySQL instances together.
> Do you consider telco OSS/BSS systems to be business
> applications? Trading systems? Order management systems? I've
> worked on all of these relatively recently, they all make use of an
> RDBMS, but by no means are they a thin layer babysitting it.
I consider them business applications. Done the right way the major
part of the business logic is implemented using constraints, views and
triggers. The main responsibilities for the application are
presentation and communication. Done the wrong way, the application is
a big ball of mud trying to reinvent a database. Without data-aware
GUI widgets, the presentation layer also tend to be a big ball of mud.
> >> 3. Either side can be deployed independently of the other (meaning
> >> at differen times) allowing me to fix bugs, or add features, to one
> >> side without redeploying the other. etc.
>
> > Views (and stored procedures) are deployeable indepentently of the
> > application. But I not sure I understand why deploying different
> > parts of the application indepently is so very important.
> It is absolutely essential in large, or even medium-sized
> systems, both in development and deployment. Maintainability and
> extensibility are core non-functional requirements. The financial
> impact and risk to the business of "Shut down everything and
> reinstall." is not a viable mechanism for meeting those NFRs.
But horizontal layers doesn't help. If you shut down the database or
presentation layer, you don't have very much application to run
anyway.
Fredrik Bertilsson
http://mybase.sf.net
Dmitry A. Kazakov
> On Jan 27, 4:05 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
>> Relation is an operation over objects in a model which would implement RA.
>
> I don't know what that means. In RA, a relation is defined as a set,
> whose members are tuples.
It meant the characteristic function of, which is a Boolean-valued
operation.
> Operations (restriction, join, projection
> etc.) can be applied to relations, which produce other relations.
Which is an even better example than mine, that relations can be values
(and thus objects).
topmind
Why do you consider it "unstructured"? What is an example scenario
you have in mind?
>
> Andy
-T-
topmind
AndyW wrote:
> >
> >And, your rudeness made me sorry I bought your damned book and put
> >money into your patronizing little pocket.
> >
> >OO needs good teachers, not mean preachers.
> >
> >-T-
> >
> >>
> >> --
> >> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
>
>
> Now now ladies - no need for the handbag fight.
Kiss my gurdle!
Thomas Gagne
>>> 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.
>>>
>> Can you give an example of an application that would have an excessive
>> number of getemployeBySomeCriteria() methods that doesn't encroach on
>> becoming a report writer?
>>
>
> 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?
employees eligible for early retirement why should we assume that
requirement should have been anticipated? Do one-off questions deserve
one-off solutions?
Instead of bloating our systems with the accumulation of years of report
requests, what if the IT department was able to turn-around requests for
that kind of data fairly quickly? Perhaps the IT department could keep
track of the requests it gets and create a most-frequently-asked-for
reports page?
> 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.
Sounds like a straight-forward SELECT statement, when crafted by a
knowledgeable programmer it won't result in Cartesian products or take
the database down to its knees.
> Lets say we have a function sending information to
> insurance company about changes in salaries, we need a way to find
> employees with changed salary. How could you possible solve this only a
> few functions for finding employees?
>
Why do we assume the only way to find things is through a OO function?
Why ignore the database and the simplicity of SQL?
>
>> All our reports have been implemented as
>> stored procedures and have been meticulously crafted to perform well and
>> balance to other reports. There are many similarly-named reports but
>> the user doesn't really see that because they navigate through the data
>> starting at the top-level and drilling-down.
>>
>
> Are there any significant difference between producing data on a paper,
> displaying it on a computer screen or using it in a thread sending
> e-mails?
Not that I'm aware of. That's a presentation problem, isn't it?
> I have seen systems like you describe above. The only way to
> access a lot of the information was to print it, or get it as a large
> PDF-file. It so 60's.
>
I don't think you have. And judging by your dismissive attitude towards
1960s software technology I'm unsure you're aware of what happened then,
either.
>> If there really was a requirement for ad-hoc getEmployee() methods
>>
>
> What's ad-hoc about set theory and predicate logic?
>
Nothing. But why not use a language more suited to set theory than an OOPL?
--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.
Thomas Gagne
> On 2007-01-26 12:44:12 -0600, Thomas Gagne <tga...@wide-open-west.com>
> said:
>
>> The biggest difference between Martin's and my approaches in this
>> area is my belief the system starts with the data model and his
>> starts with an behavioral model. Mind you, that's not a trivial
>> difference...
>
> Indeed not. We should debate that one day. ;-)
but it didn't focus specifically on where systems start. I'll probably
visit it during my talk at this year's Smalltalk Solutions in Toronto
but it won't be the focus.
topmind
Patrick May wrote:
> "topmind" <top...@technologist.com> writes:
> > Robert Martin wrote:
> >> 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?
>
> I suggest "developers who understand and have experience with
> multiple paradigms and who therefore can make the appropriate
> engineering trade-offs to achieve their customers' goals and provide
> the maximum business value given the specific problem domain and
> context." You could shorten that to "well-rounded programmers" if you
> like.
Everybody claims they are, but few prove it by showing clearly how
they are comparing stuff. Professor Weinrich (sp?) was just about the
only debator I know who was fairly good at explaining their betterment
beliefs in a semi-scientific way.
>
> I don't know anyone who understands object-orientation who also
> insists that it is the one true and only approach to use in all
> situations. That "one trick pony" attitude seems to be prevalent only
> among those who know only one trick.
The mix preferences are all over the map. Some seem to really like it.
It may indeed be a personal preference and OO fits their brain better
than other paradigms. I won't dispute that. I only dispute the claims
or implications that OO is objectively better.
The more I look at it all, the more I am convince that a lot of it is
about psychology. Experience in both programming and the domain helps,
but people tend to lean toward certain techiques. For example, I used
to line up parameters of calls to the same functions into columns
before I ever got a chance to use table-centric technologies. Tables
are in my blood.
>
> >> 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.
>
> This approach is not unique to nor was it invented by procedural
> or relational programmers. It is a standard design technique used in
> a variety of paradigms. See message-oriented middleware, SOA (Jini in
> particular), and even CORBA for examples.
It is not a matter of invention credit, but general design
philosophy. Procedural uses task as its primary code divider. OO uses
a potpurri of divisions, and this is partly why I find it so messy. It
lacks consistent design rules and organizational discipline. It is a
big soup of classes. It needs a concept bigger in scale than classes
to organize it, but there is no such convention that works so far.
>
> Sincerely,
>
> Patrick
>
-T-
Patrick May
>> When SQL is mixed with non-relational code, anyone reading the code
>> has to change context repeatedly from database access to
>> translation to application logic. This is less readable.
>
> Can you please give some example? Are you talkning about the fact
> that some environments force you to write SQL statements as strings?
> Or the fact that interfaces like JDBC is too low-level?
I'm referring to the benefits of separating concerns. 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.),
and executing the application logic. Separating these concerns is
good engineering practice because it makes the implementation of each
responsibility simpler, easier to test, and easier to understand.
>> > I don't understand why OO people insits testing their application
>> > without the database.
>> 1. It's faster, which means more tests get run, which means higher
>> quality.
>
> Are really test performance a factor that should have impact on how
> to design software?
Software should be designed to be testable. Software should be
tested as thoroughly as possible to ensure quality. Running tests
frequently identifies problems early and improves quality. All other
things being equal, a design that supports frequent testing will
result in better quality than one that does not.
>> 2. The database schema and the application logic change for
>> different reasons. Decoupling the two minimizes the impact of
>> those changes.
>
> Do you have some examples of such change (that could not be solved
> using views)?
The simplest example is during the early stages of development.
Neither the database schema nor the application architecture are
stable. Application developers are designing and implementing their
logic, database developers (who may be the same individuals filling a
different role) are focused on normalizing data and ensuring adequate
performance. The two sets of components are changing for different
reasons.
More generally, databases typically support multiple applications
and systems. Changes to the database required by one application are
often not required by other applications. The two should be insulated
from each other.
Even within a single application/database relationship, the
schema can change independently of the application logic.
Denormalization for performance is the canonical example of this.
Views are one way of providing this insulation, but there is no
particular reason to prefer them to the exclusion of all other
alternatives. You can consider O-R mapping logic to be an application
view instead of a SQL view.
>> 3. The database isn't always available to application developers,
>> particularly when working remotely or off the network. (While
>> it is possible to install a subset of the database on a laptop,
>> it's much easier to simply mock it out.)
>
> If the database isn't availible for developers, I suggest solving
> that problem instead of changing the way you design software.
You're assuming that it is a problem. Even when the application
developers do have access to the database, the ability to mock it out
provides value in development and testing. This ability provides the
additional bonus of not having to install, maintain, and run an RDBMS
on every development machine.
> Installing a full database on a laptop has not been a problem for
> the last 10 years.
Oracle still has a pretty hefty footprint in terms of disk space
and memory, and it will run slower than a mocked interface. It is
certainly convenient to have it available, but when the design
supports clear separation of concerns the developer can choose to test
without it while developing new functionality. This decreases the
testing overhead which encourages tests to be run more often. It also
helps to ensure that the interfaces between various components are
testable, which leads to better quality.
>> Do you consider telco OSS/BSS systems to be business
>> applications? Trading systems? Order management systems? I've
>> worked on all of these relatively recently, they all make use of an
>> RDBMS, but by no means are they a thin layer babysitting it.
>
> I consider them business applications. Done the right way the major
> part of the business logic is implemented using constraints, views
> and triggers.
That's a broad claim. Are you asserting that all business logic
should be implemented in SQL? That this is even possible? If this is
how you prefer to work, what are you doing in comp.object?
> The main responsibilities for the application are presentation and
> communication.
Actually, in an OSS the main responsibility is to ensure
provision of telephone services to subscribers. The business rules
and technical environment are complex. These are not CRUD systems.
> Done the wrong way, the application is a big ball of mud trying to
> reinvent a database.
Another broad claim. Mixing business logic with storage
information (i.e. database schemas) and transformation code is more
deserving of the BBOM appellation.
>> >> 3. Either side can be deployed independently of the other
>> >> (meaning at differen times) allowing me to fix bugs, or add
>> >> features, to one side without redeploying the other. etc.
>>
>> > Views (and stored procedures) are deployeable indepentently of
>> > the application. But I not sure I understand why deploying
>> > different parts of the application indepently is so very
>> > important.
>>
>> It is absolutely essential in large, or even medium-sized
>> systems, both in development and deployment. Maintainability and
>> extensibility are core non-functional requirements. The financial
>> impact and risk to the business of "Shut down everything and
>> reinstall." is not a viable mechanism for meeting those NFRs.
>
> But horizontal layers doesn't help. If you shut down the database or
> presentation layer, you don't have very much application to run
> anyway.
Not true. These kinds of systems have to be designed to be
resilient even when one or more components are unavailable. There can
be no single points of failure, including databases. An example of
this occurred at an MVNO a few months ago. Their MRP/ERP system went
down, database and all, for more than fifteen hours. Their OMS
continued accepting orders from the website, retailers, and in-house
sales system during the outage. All other steps in the workflow
remained functional. When the MRP/ERP system came back online, all of
the pending orders were processed.
We were able to achieve this level of resiliency by separating
concerns and eliminating single points of failure in the system.
Sincerely,