Run-time semantics alone determine whether a routine is an object method or a class method, so you can easily write one that swings both ways. (A common idiom makes an object method out of a constructor.) There is nothing special about a constructor method in Perl; you can call it anything you want, but most Perl programmers call it new to make you feel welcome. Not only is the underlying implementation of an object exposed, but you get to implement it yourself from a bewildering array of choices. (The one you’ll feel most comfortable with is a hash; don’t even look at the others until you’ve gotten the hash under your belt.) And there is no native support for creating instance data attributes or inheriting them, although there are optional pragmata (base, fields) that provide some syntactical sugaring for doing so. Regardless, your callers should not access your instance data directly but instead via accessor methods. You may use a module (such as Class::Struct) to create those methods automatically, although it seems that any class worth writing these days requires custom logic in each accessor method anyway. It is possible for a caller to modify the object’s instance data directly unless you go to great lengths to make the instance data as private as you’re accustomed to. (See “Closures as Objects” in the perltoot documentation page.) This is rarely perceived as a problem in Perl since the philosophy is that people who fiddle with instance data directly when the specification for the public interface to the class doesn’t permit it deserves whatever they get. Because there are no function prototypes (of the kind you’re used to) in Perl, there is no method overloading with different prototype signatures. You get to validate the number and type of arguments you’re called with at run time, if you want. You cannot enforce abstract (pure virtual) methods to be overridden at compile time, but you can create one that throws a run-time exception, unless it has been overridden. You’ll find more methodical comparisons among Perl, C++, and Java in Damian Conway’s excellent book, Object-Oriented Perl (Manning, 1999). 12.5.1 Specific Tips for the Java Programmer In Perl you have the option of creating a program that is not at all object-oriented and horrors isn’t even a class. This is actually the best approach for solving many problems, as hard as it may be to get out of the habit of doing a class hierarchy decomposition every time you write a program. The issue of “to what extent code you publish for reuse should be object-oriented” has engendered fiercely partisan arguments in the Perl community, with impassioned advocates at both ends of the spectrum. The upshot of this is that you can take whatever position you want and justify it by an appeal to authority.[4] Our rule of thumb is: If you’re writing something just for your own use which is not likely to have significant reusability, the overhead for making it object-oriented is unlikely to be worthwhile. If you’re writing something to be used by other people, an O-O interface will probably be worth the effort, considering how neatly it separates the interface from the implementation and relieves you of the need to provide any more support than simply ensuring that the interface lives up to its promises. [4] Use everything to your advantage …
Note: If you are looking for good and high quality web space to host and run your java application check Vision java hosting services