Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: To use or not to use OO Perl

by kutsu (Priest)
on Oct 22, 2004 at 14:40 UTC ( [id://401493]=note: print w/replies, xml ) Need Help??


in reply to To use or not to use OO Perl

These are not silly question, indeed Ovid wrote an interesting Tutorial on this very subject (Often Overlooked OO Programming Guidelines). As for myself the main reasons I use OO programming is when I want to re-use the code with multiple programs (which means modules are usually in OO) or if the code is very large and by putting it in OO I make it more readable (at least more readable by me).

"Cogito cogito ergo cogito sum - I think that I think, therefore I think that I am." Ambrose Bierce

Replies are listed 'Best First'.
Re^2: To use or not to use OO Perl
by SpanishInquisition (Pilgrim) on Oct 25, 2004 at 17:17 UTC
    I always write modules with OO interfaces (instead of exporting functions), but I find that only about 1/5 of my modules actually count as real OO. What does this mean? It means I use new and self, but other than keeping track of instance data, I'm not using any major OO constructs. Just using new means I don't have to pass the same datastructure argument to each function in my module each time. So that's pretty basic. My modules are usually more indicative of functional (do *not* read as "procedural") programming than OO itself.

    Code-reuse is not really something that is unique to object oriented development, and it's a shame that people think OO invented code-reuse. It did not. In the wrong hands, OO subclassing actually allows for reuse-avoidance, or even copy-and-paste development in a politically correct format. Furthermore, it is a shame that the philosophy-of-uber-inheritance is so tightly coupled with OO thought that most OO programs instantly grow a tremendous class-hierachy. This too, need not be the case.

    Anyhow, OO is fine -- but don't think it's about reuse or maintainability or massive inheritance hierachies or anything like that. It's mostly about state and clean interfaces -- or, at least -- that's how it SHOULD be. The number of real world problems correctly modelled by massive inheritance trees are few and far between.

      Anyhow, OO is fine -- but don't think it's about reuse or maintainability or massive inheritance hierachies or anything like that. It's mostly about state and clean interfaces -- or, at least -- that's how it SHOULD be. The number of real world problems correctly modelled by massive inheritance trees are few and far between.

      If you ask me, OO is a method for modelling problems that are based on interactions between Things. Not all problems are easily or properly modelled this way. When used for suitable problems, object-oriented code can be stunningly elegant; when used for unsuitable problems, it's usually a steaming heap of crap unnecessary complexity.

      tilly argued this point better and more completely: The world is not object oriented.

      --
      Yours in pedantry,
      F o x t r o t U n i f o r m

      "Lines of code don't matter as long as I'm not writing them." -- merlyn

        The reference by FoxtrotUniform to The world is not object oriented is very important despite the fact the 50+ associated nodes tend to spin off into subjects that are a far cry from the orginal. (Those spin-offs have value of their own). As more of an engineer than academic (how many times do I say that), I find the academic discussions more entertaining than practical. I have missed out on some very practical things, it seems, by discounting them in this way, e.g., the notion of Functional Programming.

        It is always a challenge to decide whether the time spent in studying a new model of thinking/designing/programming is worth the investment in order to achieve productivity for the user as well as the programmer. Spreadsheets (also mentioned in the orginal node and in the discussion at Re: Re: The world is not object oriented) are a fine example of productivity without an underlieing academicly derived model. Spreadsheets are important because they provide a way for people to model their numerical thinking. So too, MatLab and many other popular applications.

        It may sound like I'm saying to ignore these purest models. No, I'm just saying, like others, particularly engineers, use the tools that work. Don't bother with rederiving the equations.. they can be found in the papers and books.

        Now, of course, if you are trying to develop a research project for an advanced degree, well it should be unique and interesting, for its own sake.

        perlcapt
        -ben

      Nearly all my modules are based on some form of encryption, which means I can reuse a lot of OO constructs as is. I did not specify this because the main point of my post was the link to Ovid's tutorial and the link inside it to Damian Conway's ten rules for when to use OO. Having said this, I still prefer to use OO when projects are similiar, as it easier for me to "cut&paste" or reuse code as I can and it is much easier for those I work with to understand and work with OO code - which is why the main point was the Often Overlooked OO Programming Guidelines and Damian Conway's ten rules for when to use OO both of these explain a situational problem (why to use OO) in a much more complete fashion then the small node I wrote in the time I had.

      "Cogito cogito ergo cogito sum - I think that I think, therefore I think that I am." Ambrose Bierce

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://401493]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (5)
As of 2024-03-28 15:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found