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

Object creation

by nagalenoj (Friar)
on Jun 03, 2009 at 12:44 UTC ( #767989=perlquestion: print w/ replies, xml ) Need Help??
nagalenoj has asked for the wisdom of the Perl Monks concerning the following question:

Objects are used when we need multiple instances and it is used to bind variables and related methods.

I have written a class and I don't need multiple instances of the class to be used. Is it necessary to create object for the class?

I feel its not necessary. Because the functions can be accessed directly and the values can be accessed. Is it right? Kindly clarify me...

--
Nagalenoj H.

Comment on Object creation
Re: Object creation
by vinoth.ree (Parson) on Jun 03, 2009 at 13:04 UTC

    Object-oriented modules keep all function and variable names close to the vest. They are not available directly, you access them through the module name.

    According to Rumbaugh

    Encapsulation can be violated when code associated with one class directly accesses the attributes of another class. Direct access makes assumptions about storage format and location of the data. These details must be hidden within the class....The proper way to access an attribute of another object is to "ask for it" by invoking an operation on the object, rather than simply "taking it."

    Objects in perl

    Vinoth,G
Re: Object creation
by JavaFan (Canon) on Jun 03, 2009 at 13:06 UTC
    It's not "necessary". It's never "necessary" to use objects. There are fine languages that can do anything Perl can, without having objects.

    That doesn't mean you cannot write good code that just has one instance of a class during the life time of the program.

    Whether having such a singleton is a good idea depends partially on the (sub)goal you are solving, but mostly on you, the programmer. If you feel comfortable using a singleton, by all means, do. If you don't think it's appropriate, don't.

Re: Object creation
by gwadej (Chaplain) on Jun 03, 2009 at 13:06 UTC

    This is really a general design question. As such, there are a large number of potential approaches. Without a lot more information, there's no way for anyone to give you any solid advice. So, here's some general guidance instead.

    There are some who would argue that everything should be an object. However, in some applications, making an object does not really provide any benefit. For example, if there is no state (or data) in the object, it's not really an object. It's a library.

    If you have data and methods that manipulate this data, you might want to think carefully about the suggestion that

    ... I don't need multiple instances of the class ...

    Many times in my career, I've seen problems caused by making the assumption that there could only ever be one of something. Later, when it became clear that there were two, life becomes much more interesting than we wanted.

    As with any design question, there are a large number of trade-offs that must be made based on the specifics of your problem.

    G. Wade
Re: Object creation
by targetsmart (Curate) on Jun 03, 2009 at 13:35 UTC
    Other monks have given you enough wisdom, so my part of the wisdom is

    anything thing that is left unused for a long time will go off(decompose/destroy/disappear etc).

    If you ask me I would always prefer to write programs in an OO way, because I don't know when I am going to extend it, more over the concepts that I learnt I want to stay in constant touch and practice it. So IMO OO is the choice.(not for one liners really ;-) )

    But again I am not advocating anything to you, it is your decision.


    Vivek
    -- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.
Re: Object creation
by rir (Vicar) on Jun 03, 2009 at 14:06 UTC
    It depends.

    If there is no state maintained in package variables, the motives to use an object are weakened. If you are maintaining state, you should do a bit of research on the singleton pattern.

    Using an object allows an easier transition away from the singleton pattern if usage situations change.

    The missteps that I've seen have involved not anticipating singleton breaking situations: adding extended info on objects by keying into another database, by industry standard codes, and by administrative matters where having the power of internal routines would have helped.

    If in doubt, I'd present an object to client code just to stabilize the client interface.

    Be well,
    rir

    Update: comma-fied list of "breaking situations"

Re: Object creation
by John M. Dlugosz (Monsignor) on Jun 03, 2009 at 18:57 UTC
    That is patently true. If there is no state at all, I'd say go for it. If there is state, even if you only plan on having one instance, make one anyway. Designs change, programs evolve and become more complex.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://767989]
Approved by marto
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (13)
As of 2014-07-30 11:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (230 votes), past polls