Re: Interesting take on Paradigms (OO vs Procedural)


"Charles Hottel" <chottel@xxxxxxxxxxxxx> wrote in message
news:13urbjoss3fk4bf@xxxxxxxxxxxxxxxxxxxxx

"Rick Smith" <ricksmith@xxxxxxx> wrote in message
news:13ur1alih0ug9ae@xxxxxxxxxxxxxxxxxxxxx

"Kellie Fitton" <KELLIEFITTON@xxxxxxxxx> wrote in message

news:20701054-5cb5->4abb-b841-15b85c63b8f8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[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 classes that have the required
behavior. For business information, these classes 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.


.

Relevant Pages

  • Re: Interesting take on Paradigms (OO vs Procedural)
    ... IT world of business applications. ... design is mainly solutions to problems that COBOL does not have. ...
    (comp.lang.cobol)
  • Re: Interesting take on Paradigms (OO vs Procedural)
    ... IT world of business applications. ... design is mainly solutions to problems that COBOL does not have. ...
    (comp.lang.cobol)
  • Re: Relational-to-OOP Tax
    ... burden of proof to support that claim in the context of behavior ... your presentation and business rules. ... good interface design is difficult. ... with multiple paradigms simultaneously, choosing the techniques best ...
    (comp.object)
  • Re: OO Design induces an existential crisis
    ... You call yourself an experienced business applications ... that is pretty good for meeting the principles of both OO design and SOA ... If they are reading one of my articles, they are probably a developer ... a function point counter and a cost wonk, ...
    (comp.object)
  • Re: How should I generate a primary key?
    ... Obviously the designer did not get all of the business rules from the ... Should the database ... A Work Order records the transaction of a truck service at a given ... This has got nothing to do with bad design, it is about the developer trying ...
    (comp.databases)