Responsibility-Driven Design versus Functional Decomposition
Matt Stephens
anyway, there seems to be a modern trend in software design, where
classes are broken down so far that you end up with lots of one-method
classes. It's as if the classes are first allocated by responsibility
(slicing through the "big function pie" one way), then further broken
down by function (slicing orthogonally, so you end up with lots of
impoverished little classes).
e.g. you might have a BookReview class which *should* encapsulate
everything to do with a book review, and be the first "port of call" if
you want to track down a particular BookReview-related function. But
the "post-modern" design fashion is for BookReview itself to just be a
bag of data with no functions (anaemic domain object), then have
individual functions separated into (e.g. to fit into Spring
Framework): BookReviewCommand, BookReviewValidator,
BookReviewController, BookReviewDAO, JdbcBookReviewDAO etc.
So you end up with separate classes to handle individual BookReview
functions - validation, parsing form input, containing the form fields,
saving/loading etc. Often each class only has a single method (and
sometimes that method consists of a single line).
By the way I'm not trying to target Spring Framework specifically, but
it's a good example of where this sort of design is encouraged.
Also I realise there's been lots of discussion elsewhere about anaemic
domain objects, but my question is more about the "slicing & dicing" of
functions into lots of itty-bitty classes, with no single point of
entry.
So -- I was wondering what the other people on this list think about
this modern trend in software design, and if we're edging our way back
towards functional decomposition, in the name of loosely-coupled
designs?
Matt
Rebecca Wirfs-Brock
You raise a very interesting point...and one which I can't speak
about w/o seeming biased.
But I'll try.
It seems to me that frameworks especially dictate a style of
factoring, and in this case the Spring framework has led to "single
responsibility" per class (where single responsibility is often equal
to single method). On the other hand, when I use frameworks, I expect
some benefits. So in this case the benefits are a clean separation
into one object does one thing. And because of that principle you end up with:
an action controller that does one thing
a domain object that holds data (which is validated by another)
a data transfer object that is automatically constructed, etc., etc.
Now in all fairness, there are some benefits. Because of "separation
of concerns" it is easy to insert mocks and do incremental testing.
When people follow this style on a project it is easy to isolate
problems..and it is easy to enforce writing tests.
But it isn't exactly how I'd factor things if I followed my own
responsibility-driven advice: give objects responsibility to do
something with what they know. I'd tend to put validation
responsibilities directly in domain objects, if nothing else.
I'm not sure this is "post modernism" or whether it is following the
natural style a framework leads you to...or aother trend (misapplied,
in my opinion) of the "single responsibility per class rule" fostered
by misapplying Bob Martin's advice. I recently went to his book and
reread was he says very carefully/. He argues for whenever there is
an axis of change, split a class into two distinct collaborating one.
Then design the desired interface to the services needed, and allow
the implementation to vary . Thus you can see how you might get an
xyzValidator (if we think xyzValidation might change)...but the fact
is it often doesn't change. Unless you consider the
xzyValidationTestClass to be the point of variation (which I don't).
So I'm not sure having different testing classes is justification
enough to factor a design into all those tiny classes. It would be,
in my opinion if there were real differences in behavior.
So this trend of factoring things out to the smallest bit of
executable behavior may be a result of good intentions or merely
misapplied "design guidance". It leads to more more classes, more
stylized programming, and more justification for using such a
framework as Spring (isn't that part of it? trying to really push
what that framework can do for you? ;-) ).
Enough said for now.
Rebecca
Rebecca Wirfs-Brock President, Wirfs-Brock Associates
website: www.wirfs-brock.com blog:
http://www.wirfs-brock.com/rebeccasblog.html
cell: 503-313-4978 phone: 503-625-9529
reb...@wirfs-brock.com fax: 503-625-1969
"A man should learn to detect and watch that gleam of light which
flashes across his mind from within, more than the lustre of the
firmament of bards and sages. Yet he dismisses without notice his
thought, because it is his." --Ralph Waldo Emerson
Don't you want to take responsibility for your design?
Scott W. Ambler
>It seems to me that frameworks especially dictate a style of
>factoring, and in this case the Spring framework has led to "single
>responsibility" per class (where single responsibility is often equal
>to single method). On the other hand, when I use frameworks, I expect
>some benefits. So in this case the benefits are a clean separation
>into one object does one thing. And because of that principle you end up with:
>an action controller that does one thing
>a domain object that holds data (which is validated by another)
>a data transfer object that is automatically constructed, etc., etc.
I think that taking either approach will result in a design which is
easy to maintain and to evolve if you do it correctly. However, you
would run into trouble if some people on your team follow functional
decomposition (FD) and others follow RDD. Choose an approach and
stick to it. Furthermore, if you're using a framework, then clearly
it's in your best interest to follow the strategy which it
supports. For example, if you're using Spring then you should lean
towards the OO version of FD that it prefers. I suspect it would be
a serious mistake to "fight the framework".
- Scott
PS: In case you don't know, Rebecca has written some really good
books on RDD, the most recent one is Object Design: Roles,
Responsiblities, and Collaborations (
http://www.amazon.com/exec/obidos/ASIN/0201379430/ambysoftinc
). It's definitely worth checking out.
====================================================
Scott W. Ambler
Senior Consultant, Ambysoft Inc.
www.ambysoft.com/scottAmbler.html
Refactoring Databases: Evolutionary Database Design
(www.ambysoft.com/books/refactoringDatabases.html) is now available!
Tim
Matt Stephens wrote:
> The title is probably almost as inciteful as Ravi's email --
Did you have the chance to read the article that Ravi criticized? If
you did not have a chance to do so, here is the quote from the
"venerable" incorrigibly rude Scott Ambler's first response,
"Ravi, assuming that you're talking about my Glacial Methodology
article in the most recent version of OV it was meant as an April
Fool's joke and wasn't meant to be taken seriously.
For anyone interested, a more thorough description can be found at
http://www.ambysoft.com/essays/glacialMethodology.html "
Once you read that article, and have read more of the Great Scott's
agileDBA articles, you'll see how rude and classless this man is. If
you have a background in relational theory or databases, you'll see
that what he criticizes is not what actually happens in any project.
Hence Ravi's statements that Scott Ambler sets up strawmen, demolishes
them and claims all data professinals are dinosaurs.
Scott owes Ravi and the data professionals a serious apology.
Tim
Tim
towards the OO version of FD that it prefers. I suspect it would be
a serious mistake to "fight the framework". "
Hmmm. So your design must conform to the framework, not to the problem
domain, is that what you are saying? Ideally, a high level OO design
should be independent of the tools used to implement it, sticking
closer to the business problem one is trying to solve.
Tim
Scott W. Ambler
What I'm saying is that your design must reflect both the problem
domain and the chosen architecture. If Spring is part of that
architecture, then yes, my design will reflect that. If COBOL is
part of the architecture then my design will reflect that. If
Smalltalk is part of the architecture... well, you get the idea.
A design is effectively a mapping of the problem space to the
solution space, so it has to reflect both.
- Scott
Tim
Your statement, "A design is effectively a mapping of the problem
space to the
solution space, so it has to reflect both." implies that the actual
classes will depend upon the language and the framework chosen.
This has several implications:
1. There is some dependence on the framework. Hence, if we wanted to
switch the framework, a significant amount of work needs to be done.
2. Persistence. Since the object models are different for different
languages and frameworks, an OO-DBMS with the objects being persisted
based on the current model, must be aware of the object model. It
cannot be used directly by another application that needs the data just
for reporting, for example. The reporting application must know the
classes and the public methods (the API, in other words.) If there are
several different applications accessing this data, each must become
aware of the original application.
If two different applications are built more or less at the same
time, each addressing different concerns of the organization, each with
different object models, with possibly different and sometimes
conflicting views of the data, which application should be considered
the definitive one as far as data is cocncerned?
3. New OO languages: If a new language comes along, then it is possible
that the whole object model must be dropped and a new one created! That
would be a significant change.
In practice, what this means is that once a language and a framework
have been chosen, there is an effective lock-in to these choices.
Changes to these are not easy to make.
Is that interpretation accurate?
Amy, is that technical enough for you? Am I still a troll? Hope you
move me into your good books now. :-)
Tim
Rebecca Wirfs-Brock
I might have said that there's a difference between a low-level
design and a higher level design. Any time you decide to use your
favorite framework, implement in your favorite programming language
or database you are making implementation choices. These choices do
make it harder for you to pull up roots and re-implement your design
in another context...but not impossible. A good friend of mine and
former colleague makes his business writing transformation tools (and
then implementing transformation code specifications) in order to
migrate a design from one older legacy technology to a newer one...
In my opinion, whenever you can isolate a part of your implemented
design from unnecessary technical constraints, that gives you some
wiggle room (for a good ongoing lively discussion of these issues I
encourage you to wander over to the domain driven design newsgroup
which spends a lot of time discussing how best to do this and to
"createa clean extensible domain model that can accomodate a number
of different situations". People on that newsgroup talk a whole lot
about how to separate your domain model from persistence technical
mappings....and if you dig into Eric Evans' writing on the matter,
you'll realize that on any complex software project there isn't just
one model...and it fact it is quite natural to have different parts
of a complex system have different views on their sub-domain based on
what they're trying to accomplish. Eric has written about techniques
and patterns for identifying upstream-downstream dependencies between
domains, as well as patterns for effectively isolating and dealing
with interdependencies. But no one said it is ever easy.
In short, if there are different views of persistent data, then I
suspect there isn't one unified object domain model for that data. So
it is OK to recognize that and to not force fit "the model" onto data
that is used in disparate ways.
I hope I raised the issues in a way that lead to some interesting
discussions (now that I am back from my week of meetings and have
time to contribute to this group).
Rebecca
p.s. The discussion group domaindrivendesign on yahoo I find quite
interesting...............you might, too
Scott W. Ambler
<snip>
> A good friend of mine and
>former colleague makes his business writing transformation tools (and
>then implementing transformation code specifications) in order to
>migrate a design from one older legacy technology to a newer one...
Actually, a very good site (IMHO) describing legacy transformations
is http://systemtransformation.com/ . Bill Ullrich, author of Legacy
Systems: Transformation Strategies
http://www.amazon.com/exec/obidos/ASIN/013044927X/ambysoftinc/ , is
one of the primary people associated with the site. He knows his
stuff and his book is pretty darn good.
I have some interesting thoughts about the database side of things
posted at http://www.agiledata.org/essays/legacyDatabases.html which
summarizes the detailed chapter on the subject in Agile Database
Techniques ( http://www.ambysoft.com/books/agileDatabaseTechniques.html )
Mike Feathers' book, Working with Legacy Code
http://www.amazon.com/exec/obidos/ASIN/0131177052/ambysoftinc , is
also a valuable resource for anyone trying to transform legacy
systems into actual assets.
<snip>
- Scott
====================================================
Scott W. Ambler :-)
Tim
your response.
And as a true capitalist with every intention of raking in the moolah
at every possible opportunity, a link or two to amazon through your
website so that you can gain a buck or two.
Completely expected, I think.
Tim
Tim
the magazine who is participating in these discussions?
Tim
Tim
favorite framework, implement in your favorite programming language
or database you are making implementation choices. "
Actually, this is not quite true for databases. When doing conceptual
modelling or logical modelling, the question of the actual DBMS
(Database management system) never comes up. The physical
implementation of the actual datamodel is often very similar across
databases. In fact, given their similarity, the physical tables for
Oracle and PostgreSql implementations can be completely identical.
My point is that there is no closeness to the high level model as far
as OO design is concerned. One has to consider the language used to
implement it right from the start.
Scott W. Ambler
On Mon, April 10, 2006 2:20 pm, Tim said:
> Actually, this is not quite true for databases. When doing conceptual
> modelling or logical modelling, the question of the actual DBMS
> (Database management system) never comes up. The physical
> implementation of the actual datamodel is often very similar across
> databases. In fact, given their similarity, the physical tables for
> Oracle and PostgreSql implementations can be completely identical.
Actually, it depends. Your physical data model would be very different if
your target environment is an RDB like Oracle instead of an XML database,
or a network database.
Also, when it comes to RDBs it depends on how detailed your model gets.
If you start to take issues such as database-specific implementation
features then there are important differences. For example, SQL Server
now implements the CLR within the database and Oracle supports Java. And,
as we all know, there are differences in the way that stored procs are
implemented.
>
> My point is that there is no closeness to the high level model as far
> as OO design is concerned. One has to consider the language used to
> implement it right from the start.
Actually, that's not necessarily true. For example, I present a
high-level class diagram at
http://www.agiledata.org/essays/agileDataModeling.html#Figure1 . What
language does that diagram imply? But yes, the reality is that you've
usually selected the technology (or had it selected for you) and that will
bias your models.
Data professionals have the exact same issue. Call it like it is, if
you're an Oracle shop (or DB2, or Sybase, or...) chances are exceptionally
good that you're going to implement on Oracle (or...). In situations
where this is actually the case, it makes you wonder how much busy work is
going on with all this logical modeling.
- Scott
http://www.ambysoft.com/scottAmbler.html
Refactoring Databases (
http://www.ambysoft.com/books/refactoringDatabases.html ) is now
available.
Tim
publicly visible. I am going to stop participating in these discussions
unless we can have a faster way of seeing our views expressed.
Tim
Tim
What you have presented in the diagram that you linked below is
actually a data model using UML, not a class diagram.
In effect, your question after that link simply proves my point that
relational data models are DBMS agnostic. If you are saying that the
data model is the class model itself, then all I'll say is why bother
with OO modelling if you are going to use a (relational) data model as
the basis for your OO model?
Tim
Tim
Network models and hierarchical models were known to have severe
limitations and were abandoned in the 1970s when relational technology
became popular. XML databases are nothing but a reincarnation of the
hierarchical database ans are doomed to face a similar fate.
By the way, OO came into being in the 1960s with the creation of
Smalltalk and Simula (preceding it, I think), relational technology
came into being in the 1970s with E F Codd's seminal paper. Hence
relational technology is newer than OO technology. Therefore, anybody
who refers to database experts as "data dinosaurs" should probably
refer to OO practitioners, who use even older technologies, as those
belonging to a Pre-Cambrian era! Let's see how it sounds: Pre-Cambrian
OO practitioners. Has a nice erudite ring to it.
Do spend a few minutes thinking about the last paragraph.
Enjoy!
Tim
Rebecca Wirfs-Brock
Tim- If you follow a very strict set of design guidance, it is
somewhat easier to end up with parts of your oo design that are
pretty technology neutral. Eric Evans has written about domain driven
design in his book, and presents a number of patterns that really
encourage folks to separate domain concepts into objects that are
very focused and don't mix in persistence mapping or presentation
layer concerns into their behaviors. While you do have to implement
those domain objects in your programming language of choice, these
objects (if designed properly) are more or less technology
independent. I think that style of implementation is gaining
popularity for a good reason...it results in objects representing
business concepts being clearly separated from those that get
information into/out of web forms/databases/etc.
So for those domain objects designed in this way, at least, the high
level model is much closer to the implementation.
Regards,
Rebecca Wirfs-Brock
markcol...@gmail.com
Take a look at www.ratio.co.uk/W13.html and www.ratio.co.uk/W9.html -
both are concerned with how to structure large applications to
minimise coupling, improve test coverage and potential for re-use.
Ciao,
Mark.
--
Mark Collins-Cope
Ratio - Training, Consultancy and Development
--------------------------------------------------------------------------
+44 (0)20 8579 7900 or :+44 (0)777 163 6882
Author: "Agile Development with Iconix Process"
Editor: www.ratio.co.uk/objectiveview.html
---------------------------------------------------------------------------
recursion is - of course - a form of magic
markcol...@gmail.com
I'm coming into this not having read all of the message, but following
up on a few of the themes...
(1) Agile development does (in general) de-emphasise "excessive"
upfront modelling - the focus is on proving stuff with working
software. There is still a debate going on about just how much
modelling or not modelling should be done - developers often take
different positions on this. Some teams do little modelling. I prefer
myself to do a bit more than some - but the emphasis is on delivering
working software at regular intervals.
With regard to understanding business requirements, the emphasis is
very much on understanding the detail of the current increment, not
worry so much about future increments. There is a cost to pay for this
- that you may have to refactor your code and database in the next
increment to bring the underlying software model you have implemented
up to scratch.
(2) I personally like to develop what I call a specification model -
which is something like a domain model, but will also include system
concepts like user-groups (for security - these aren't really domain
concepts). In particular a spec. model has no methods on it (only
attributes) - it is there to clarify everyone's understanding of what
the system is supposed to do. As such, it may well be cross-referenced
in functional (use case) descriptions. E.g.
create_customer - creates a new Customer in Hotel.Customers - where
Customer and Hotel are on the spec. model. Hotel
1--------------*Customer.
This is technology neutral and implementation neutral. In fact, the
attributes don't have to be there in the implementation, the system
only has to behave *as if* they were there (they may be, for example,
calculated from the value of other attributes).
I have a feeling this is not unlike what you would call a logical
model? Am I right?
Regards,
Mark.
Scott W. Ambler
>Scott,
>
> What you have presented in the diagram that you linked below is
>actually a data model using UML, not a class diagram.
Actually, it's a conceptual model which I've presented in the context
of data modeling. I could just as easily used it as a basis from
which to develop a detailed class diagram.
>In effect, your question after that link simply proves my point that
>relational data models are DBMS agnostic. If you are saying that the
>data model is the class model itself, then all I'll say is why bother
>with OO modelling if you are going to use a (relational) data model as
>the basis for your OO model?
http://www.agiledata.org/essays/drivingForces.html
At 03:32 PM 4/11/2006, Tim wrote:
>Scott, I was referring to relational data models only.
>
>Network models and hierarchical models were known to have severe
>limitations and were abandoned in the 1970s when relational technology
>became popular. XML databases are nothing but a reincarnation of the
>hierarchical database ans are doomed to face a similar fate.
I agree, XML databases may not do well in the marketplace, and they
certainly won't do well in comparison to relational databases. But,
XML for data transfer is clearly a fact of life that we need to get used to.
File-based storage (often XML), object-base, hierarchical, network,
and other types of data storage all have their uses and market
niches. I would suggest that there is value in modeling the schemas
implemented using those technologies.
>By the way, OO came into being in the 1960s with the creation of
>Smalltalk and Simula (preceding it, I think), relational technology
>came into being in the 1970s with E F Codd's seminal paper.
Yes, you're right.
> Hence
>relational technology is newer than OO technology. Therefore, anybody
>who refers to database experts as "data dinosaurs" should probably
>refer to OO practitioners, who use even older technologies, as those
>belonging to a Pre-Cambrian era! Let's see how it sounds: Pre-Cambrian
>OO practitioners. Has a nice erudite ring to it.
The dinosaur comments which I made in my April Fool's joke wasn't in
reference to technology, they were in reference to mindset.
And, as you may have noticed, object technology has evolved a fair
bit since the 1960s.
Tim
I briefly ran through the two articles you pointed out. While long,
I do not think they have anything new to contribute to software
development. It is well known that good software is developed in
layers, and that layers on the bottom should be completely unaware of
layers above them that use them. Whether it is 2 layers as in
Client-Server or n-layers as in the buzzword "n-layered architecture"
does not really change the fundamental concept.
Also, your use of Keys in one of the examples actually shows that
high-level OO design is moving closer and closer to the conceptual
model that relational database development produces.
Of the purported benefits of OO - encapsulation, abstraction,
polymprphism and inheritance - good procedural languages embody three
of them (encapsulation, abstraction and polymorphism.) As far as
inheritance is concerned, it has very limited uses and it is generally
accepted that composition is preferable to inheritance. Given that, it
seems that OO does not offer as significant benefits as claimed by its
vociferous boosters.
Tim
PS: If I do not see any improvement in the speed with which articles
are posted, I'll stop posting here, And then the contributors to
ObjectiveView Magazine can talk to each other happily, with nary a
dissenting opinion.
Rebecca Wirfs-Brock
I'm curious at hearing about what you consider to be "good" procedural languages. I've always thought that oo programming languages are just a step along in the progression---instead of having to be disciplined in how you program to get well-defined, decoupled parts of your code, you explicitly get encapsulation for free and have to write bad code to break that encapsulation. But my mileage may vary from yours as my procedural languages I have written in include Forth, FORTRAN, COBOL, C, and Pascal (I may be forgetting a few of them).There were means of encapsulating in those languages, but in addition too many ways to encourage tangled data and behaviors (FORTRAN Common was an opportunity for total chaos).
I think that the quote in the Design Patterns book...that they prefer solutions that favor composition over inheritance has in generally been misinterpreted by many to mean that inheritance equates with bad, and composition with good designs. But many of the patterns in their book exploit inheritance (the template method for one)....and the use of inheritance to specify configurable algorithm steps is one I have used extensively in my programming . I still see a lot of elegance, too, in well-formed class hierarchies with clean abstractions and extensible mechanisms. Maybe my Smalltalk programming background biases are showing, but inheritance in my opinion doesn't deserve the bad rap it gets. I also think there is a difference in how people use inheritance based on the language they program in. For example, in Java, subclasses by default can inherit and override superclass' methods...if you want to make a method provide a default implementation, that can be overridden, you have to explicitly declare it to be virtual (pardon me if I am getting the keywords wrong as I am a rusty with C#). This tends to result in a different style for how inheritance is used--or discouraged...
Rebecca
At 09:16 AM 4/12/2006, you wrote:
Of the purported benefits of OO - encapsulation, abstraction,
polymprphism and inheritance - good procedural languages embody three
of them (encapsulation, abstraction and polymorphism.) As far as
inheritance is concerned, it has very limited uses and it is generally
accepted that composition is preferable to inheritance. Given that, it
seems that OO does not offer as significant benefits as claimed by its
vociferous boosters.
Tim
Rebecca Wirfs-Brock President, Wirfs-Brock Associates
Tim
As I mentioned before, here are the features that OO proponents
claim make OO unique: abstraction, encapsulation, polymorphism and
inheritance.
The claim also seems to be that procedural languages do not have any
of these features. A bit of thought will show that the first three of
these features are compatible with any procedural language; Lisp's easy
adoption of the OO paradigm into the CLOS is an excellent example of
this. Incidentally, Lisp was the first language to be certified as OO
by ANSI! Not that the certification means much, but it is defintely
food for thought.
As I've shown in the previous post, PL/SQL has the ability to
abstract, encapsulate using packages, and has function overloading
(one form of polymorphism.) The only thing missing is inheritance. My
experience shows that inheritance, used properly, is needed much less
in good design; hence its benefits are not that significant.
So, in what sense is OO the next step? Does it promote re-use? The
evidence doesn't support it. Why OO then? To most people it is merely a
buzzword and current fad, and is required for getting a job; so they
use it. In one of the first articles in ObjectiveView magazine, Mark
himself ascribes certain features to procedural programming: statements
to the effect that procedural code for large projects always results in
"spaghetti" code that is unmaintainable. All this without attesting any
evidence, and then goes on to claim that OO is better! Another strawman
argument. Seems to be an occupational hazard of contributors to this
magazine!
What are the problems with OO? A noun based taxonomy that is
essentially inflexible to change (at least as far as Java and the curly
braces family of languages is concerned); many if..then constructs even
by such "luminaries" as Bob Martin as shown by his so called "Clean
Code" article in butunclebob.com [If a new developer had shown the type
of code that Uncle Bob gave as an example of clean code, I would've
given him an earful! ]. I personally see a lot of ignorance among the
most vociferous of the OO practitioners/evangelists, who take it as a
given that OO is good, and all procedural is bad!
Decoupled code, or code in layers, happens always by intention, never
accidentally, not even when using OO! I've seen too much OO code that
has circular dependency and strong coupling to accept the claim that OO
leads to decoupled code. No, OO doesn't lead to decoupled code. It is
the programmer who writes decoupled code, not the paradigm used.
Whether the good programmer is using OO or functional or procedural
doesn't matter, he/she will produce good decoupled code. And no matter
what style of programming the average/bad programmer is using, they
will produce bad code, that is hopelessly entangled and has the wrong
abstractions.
As far as Design Patterns book is concerned, Peter Norvig's web site
has some comments on it. I did not find the book very impressive.
Recently, on Uncle Bob's Website it has been shown that the Visitor
pattern is unnecessary, for example. Many patterns are not the best way
of implementing functionality. But that is another discussion.
Tim
Rebecca Wirfs-Brock wrote:
> Tim-
> I'm curious at hearing about what you consider to be "good"
> procedural languages. I've always thought that oo programming
> languages are just a step along in the progression---instead of
> having to be disciplined in how you program to get well-defined,
> decoupled parts of your code, you explicitly get encapsulation for
> free and have to write bad code to break that encapsulation. But my
> mileage may vary from yours as my procedural languages I have written
> in include Forth, FORTRAN, COBOL, C, and Pascal (I may be forgetting
> a few of them).There were means of encapsulating in those languages,
> but in addition too many ways to encourage tangled data and behaviors
> (FORTRAN Common was an opportunity for total chaos).
>
> I think that the quote in the Design Patterns book...that they prefer
> solutions that favor composition over inheritance has in generally
> been misinterpreted by many to mean that inheritance equates with
> bad, and composition with good designs.
<snip>
Scott W. Ambler
>Rebecca,
>
> As I mentioned before, here are the features that OO proponents
>claim make OO unique: abstraction, encapsulation, polymorphism and
>inheritance.
Tim, on the subject of strawmen, I think that you've invested a lot
of time writing one up.
1. Abstraction, as a concept, has been around for a long time and
although the object community does talk about it a lot I think that
pretty much anybody involved with modeling, OO or otherwise, talks
about abstraction a fair bit too. I'd be hard pressed to find an
article that claims that abstraction is only for OO, can you share an
URL to one?
2. Ditto for encapsulation. At
http://www.agiledata.org/essays/implementationStrategies.html I talk
about several strategies for encapsulating DB access, and sure
enough, in the services section I indicate that stored procs are one
of many ways to do so.
3. Polymorphism, as a term, has always been a bit overblown (e.g.
it's a buzzword). As a concept it's pretty useful. Dynamically
typed languages definitely have their benefits resulting from
polymorphism, and do be fair so do statically typed languages
although clearly they're a bit more constrained.
4. Inheritance is arguably a form of subtyping, which is pretty
common in the data world if I'm not mistaken. ;-)
<snip>
> As I've shown in the previous post, PL/SQL has the ability to
>abstract, encapsulate using packages, and has function overloading
>(one form of polymorphism.) The only thing missing is inheritance. My
>experience shows that inheritance, used properly, is needed much less
>in good design; hence its benefits are not that significant.
Actually, you've got the option to run Java in recent versions of
Oracle, so from the RDBMS point of view inheritance is an option for you now.
<snip>
As for the rest of your discussion about object technology, you're
roughly 10-15 years too late. All of the major vendors, including
the major DB vendors, have adopted it. A very large percentage of
developers now work using OO or object-based languages and the vast
majority of tool development seems focused on this environment. The
market place has clearly cast its vote in favor of OO. You can
choose to complain about it, I suspect to no avail, or you can choose
to find ways to work with it effectively.
- Scott
====================================================
Scott W. Ambler :-)
Scott W. Ambler
>Rebecca,
>
> As I mentioned before, here are the features that OO proponents
>claim make OO unique: abstraction, encapsulation, polymorphism and
>inheritance.
Tim, on the subject of strawmen, I think that you've invested a lot
of time writing one up.
1. Abstraction, as a concept, has been around for a long time and
although the object community does talk about it a lot I think that
pretty much anybody involved with modeling, OO or otherwise, talks
about abstraction a fair bit too. I'd be hard pressed to find an
article that claims that abstraction is only for OO, can you share an
URL to one?
2. Ditto for encapsulation. At
http://www.agiledata.org/essays/implementationStrategies.html I talk
about several strategies for encapsulating DB access, and sure
enough, in the services section I indicate that stored procs are one
of many ways to do so.
3. Polymorphism, as a term, has always been a bit overblown (e.g.
it's a buzzword). As a concept it's pretty useful. Dynamically
typed languages definitely have their benefits resulting from
polymorphism, and do be fair so do statically typed languages
although clearly they're a bit more constrained.
4. Inheritance is arguably a form of subtyping, which is pretty
common in the data world if I'm not mistaken. ;-)
<snip>
> As I've shown in the previous post, PL/SQL has the ability to
>abstract, encapsulate using packages, and has function overloading
>(one form of polymorphism.) The only thing missing is inheritance. My
>experience shows that inheritance, used properly, is needed much less
>in good design; hence its benefits are not that significant.
Actually, you've got the option to run Java in recent versions of
Oracle, so from the RDBMS point of view inheritance is an option for you now.
<snip>
As for the rest of your discussion about object technology, you're
roughly 10-15 years too late. All of the major vendors, including
the major DB vendors, have adopted it. A very large percentage of
developers now work using OO or object-based languages and the vast
majority of tool development seems focused on this environment. The
market place has clearly cast its vote in favor of OO. You can
choose to complain about it, I suspect to no avail, or you can choose
to find ways to work with it effectively.
- Scott
====================================================
Scott W. Ambler :-)
David Allen
--- Tim <tim.d....@hotmail.com> wrote:
> What are the problems with OO? A noun based
> taxonomy that is essentially inflexible to change
I currently program using an object-oriented language
(C#) but I used to program in COBOL and Pascal. I
don't see how C# or the object-oriented approach is is
intrinsically more inflexible to change than the
procedural languages that I used to use. It is the
design that is inflexible or flexible. And even then,
flexibility can only be discerned in the context of an
impending change. A design that is flexible for
change along one axis may be inflexible when
considered in the face of other changes.
Thank goodness for refactoring! Refactoring is one of
the most powerful tools I have at my disposal to
change an inflexible design into a flexible design.
Fortunately, it can be used with virtually any
language and paradigm. The ease with which certain
languages can be refactored may vary from others, but
I will not be so bold as to offer an opinion about
that ;)
> Decoupled code, or code in layers, happens always
> by intention, never accidentally, ...
> No, OO doesn't lead to
> decoupled code. It is
> the programmer who writes decoupled code,
I agree with this.
That is one of the things that I enjoy the most about
software development: continually learning more and
better with ways of making software that is useful,
reliable, adaptable, et cetera.
David Kreth Allen
Minneapolis, Minnesota
Scott W. Ambler
On Tue, April 18, 2006 9:58 am, David Allen said:
<snip>
>
> Thank goodness for refactoring! Refactoring is one of
> the most powerful tools I have at my disposal to
> change an inflexible design into a flexible design.
> Fortunately, it can be used with virtually any
> language and paradigm. The ease with which certain
> languages can be refactored may vary from others, but
> I will not be so bold as to offer an opinion about
> that ;)
Gut feel tells me that it's not a language issue, it's a tool issue. Java
is easier to refactor, perhaps, than COBOL right now because to my
knowledge there isn't any refactoring tools. I suspect that says
something about the COBOL tools themselves, not the COBOL language.
Granted, there may be some nuances about one language over another which
makes it easier to refactor, but I bet those nuances won't add up to much.
Perhaps there's an opportunity for a Masters student to do a research
project on this issue?
>
>> Decoupled code, or code in layers, happens always
>> by intention, never accidentally, ...
>> No, OO doesn't lead to
>> decoupled code. It is
>> the programmer who writes decoupled code,
>
> I agree with this.
>
> That is one of the things that I enjoy the most about
> software development: continually learning more and
> better with ways of making software that is useful,
> reliable, adaptable, et cetera.
Yes. You can write good code in Java/COBOL/... and you can write bad code
in Java/COBOL/... It boils down to skill.