Object creation

[nagalenoj]

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.

[gwadej]

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.

[JavaFan]

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.

[rir]

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"

[targetsmart]

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.

[John M. Dlugosz]

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.

[vinoth.ree]

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