The title is probably almost as inciteful as Ravi's email -- but 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- 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 At 06:00 AM 4/3/2006, you wrote:
>The title is probably almost as inciteful as Ravi's email -- but >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?
"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?
>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
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.
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.
Scott says, "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". "
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.
>Scott says, "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". "
>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.
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
==================================================== Scott W. Ambler Senior Consultant, Ambysoft Inc. www.ambysoft.com/scottAmbler.html
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- 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
> 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. :-)
"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?
Discussion subject changed to "Legacy transformations was Re: ovdiscussion Re: Responsibility-Driven Design versus Functional Decomposition" by Scott W. Ambler
> 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...
Nice, Scott. A couple of your own articles for self promotion thrown in 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.
Rebecca, you said, "Any time you decide to use your 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.
> 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.
It is painful to have to wait a day or so to see our writings to become publicly visible. I am going to stop participating in these discussions unless we can have a faster way of seeing our views expressed.
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?
Scott W. Ambler wrote: > On Mon, April 10, 2006 2:20 pm, Tim said:
> 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.
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.
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.
>Rebecca, you said, "Any time you decide to use your >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.
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.
"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?
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.
On 11/04/06, Rebecca Wirfs-Brock <rebe...@wirfs-brock.com> wrote:
> At 11:20 AM 4/10/2006, Tim wrote: > >Rebecca, you said, "Any time you decide to use your > >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.
> 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.
> "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?
-- 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
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.
On 11/04/06, Tim <tim.d.mil...@hotmail.com> wrote:
> 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
> Scott W. Ambler wrote: > > On Mon, April 10, 2006 2:20 pm, Tim said:
> > 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.
-- 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
> 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?
>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.
- Scott ==================================================== Scott W. Ambler :-) Senior Consultant, Ambysoft Inc. www.ambysoft.com/scottAmbler.html
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.
> 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.
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. 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.
"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?
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.
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.
> 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 :-) Senior Consultant, Ambysoft Inc. www.ambysoft.com/scottAmbler.html
> 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 :-) Senior Consultant, Ambysoft Inc. www.ambysoft.com/scottAmbler.html
