Re: Interesting take on Paradigms (OO vs Procedural)

"Charles Hottel" <chottel@[EMAIL PROTECTED]
> wrote in message
news:13urbjoss3fk4bf@[EMAIL PROTECTED]
>
> "Rick Smith" <ricksmith@[EMAIL PROTECTED]
> wrote in message
> news:13ur1alih0ug9ae@[EMAIL PROTECTED]
> >
> >>"Kellie Fitton" <KELLIEFITTON@[EMAIL PROTECTED]
> wrote in message
> >
news:20701054-5cb5->4abb-b841-15b85c63b8f8@[EMAIL PROTECTED]
> >
> > [snip]
> >
> >>You might find what my COBOL teacher said about OOP interesting:
> >
> >>Begin quote:
> >
> > [snip]
> >
> >>Object oriented is simply an oversold and overhyped programming
> >>concept, without any clear benefits that can be fathomed in the
> >>IT world of business applications.   Nonetheless, object oriented
> >>design is mainly solutions to problems that COBOL does not have.
> >
> >>End quote:
> >
> > It is my understanding that, "in the IT world of business
> > applications"; most data is representational, not object.
> > The distinction is that the former has little or no behavior
> > while the latter does.
> >
> > One problem with attempting to add behavior to
> > representational data is that the process is potentially
> > never-ending. One may add methods to the class to use
> > the data in one way, then add more methods to use it
> > another way, and so on. In formal OO design, this
> > requires opening the class to add the methods--a no-no
> > that violates the Open/Closed Principle. If inheritance is
> > used to extend the class, then inheritance can not be used
> > also for sub-classing, without creating "class spaghetti".
> > To avoid this problem, one simply leaves the data as is
> > and creates separate cl***** that have the required
> > behavior. For business information, these cl***** use
> > the paradigm "clerks performing procedures on or with
> > data", which is pretty much what COBOL programs
> > do now.
> >
> >
>
> You can use the decorator pattern to add behavior to an object and the
> object does not even know about the new behavior.

The distinction here is that Decorator adds to an
individual object, whereas the addition I was referring
to was to the class and thus to all objects instantiated
from that class.

Choosing Decorator, when the addition is needed for
all, adds overhead and complexity that would not
otherwise occur since every access to every object is
indirect. Stacking Decorator for each change would
seem to make things much worse, much faster.

Using a "Clerk pattern" for each behavior is as simple
as it gets.