Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Re: The world is not object oriented

by BUU (Prior)
on Jan 03, 2004 at 04:53 UTC ( #318466=note: print w/replies, xml ) Need Help??

in reply to The world is not object oriented

One reason, which I think you didn't touch upon, is that OO seems to produce much simpler code, at least conceptually. I think that this is because it's much more closely related to procedural programming than the other types of programming, and because (imho, etc) procedual is the simplest type of programming, being closest to it makes for code thats easier to understand.

So OO is often taught as the next step beyond procedural, simply because it's simpler and easier to teach and understand.

Another thought is that OO tends to make code sound simpler, at least conceptually speaking, especially when speaking in more natural languages (such as english and so on). It's much easier to say Object 1 calls Object2's method baz which then takes an object3 which it manipulates in this manner, then to start describing how a functionally oriented program works.

Perhaps what I'm getting at is that objects tend to be the best way to hide implementation details, and this makes everything seem much much simpler when your trying to model something. This may not even be true when you are writing the code, but it's much easier to conceptualize.

One thing I've noticed is that occasionally you have library type code that is programmed as a class/object combination simply because thats the only way the author knows how to appropiately encapsulate his data and methods. This is often the case with Singleton pattern objects, theres no real reason to use an object in this case, you just need a module, but some times the author or the language can't use a module, so you use a Singleton object.

Replies are listed 'Best First'.
Re: Re: The world is not object oriented
by stvn (Monsignor) on Jan 03, 2004 at 06:21 UTC

    I agree with you, alot of Singleton classes are mearly modules shoe-horned into classes. But i disagree that this is reason not to use OO and instead use a plain ole module. It is largely dependent upon the context. While I always advocate mixed paradigm programming within the larger application, I think that on a smaller scale, paradigms should be reasonably seperated.

    If my application is largely OO, then a Singleton approach/syntax makes sense. A Singleton's singular instance can be passed around and treated like any other object, the other objects blind to its Singleton-ness. In this case the module approach/syntax would be awkward and clumsy.

    Now if my application is largely procedural/imperitive/functional style, then the module approach/syntax makes much more sense. It fits the context here. Where an Singleton object would be akward and clumsy.

    Ideally a module should provide both interfaces (if appropriate), much like (yes i know just auto-creates an object instance for you if you use the non-OO interface, but hey, encapsulation isn't just for OO).


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://318466]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2018-02-24 08:41 GMT
Find Nodes?
    Voting Booth?
    When it is dark outside I am happiest to see ...

    Results (310 votes). Check out past polls.