This feels just a bit like an exam question to me. The question feels just a little bit too neat and the more I wrote below, the more I felt that way. Still, I think it is important question for those who care about OOP, so I'm providing, with reservation, an answer below. I don't like giving people answers to questions that are meant to be a test of their own synthesis of class materials rather than a test of their ability to "find it on the web".

Encapsulation

Scoping (public/private/protected): In Java encapsulation is enforced by the compiler. It is impossible to write code that accidentally accesses variables meant to be private. This increases your upfront work since you have to explicitly declare the access level of any public or protected member (fields and methods with no explicit declaration are private to a package). It decreases your testing work, because you don't need to worry about constructing tests to see if consumer packages are obeying the privacy rules.

Subclass access to superclass data: In Java you can access protected variables inherited from the parent without qualification. In Perl, any variable not in the current package, must be qualified. To access a data member of a parent class, without qualification you have to explicitly assign it to a variable within the current package. (Note: you could arrange to auto-export protected variables by writing a special import routine that checked the "@ISA" variable for the package calling "use XXX" or import(), but this isn't out of the box.)

Java also protects you from name collision. In Perl, you must use and publicize some sort of naming convention in order to insure that subclasses don't clobber the variables of superclasses. In Java, names are scoped to their package. If the superclass and subclass have the same named field, the subclass field hides the superclass field, but you can always access the superclass field, by using super.myvar instead of this.myvar.

Inheritance

Perl supports multiple inheritance, provides two built-in strategies for prioritizing implementations from different superclasses, and also gives you a way to roll your own, if you wish.

Java is much more restrictive. It is often said to support only single inheritance, but it would be more accurate to say that it supports a very restricted form of multiple inheritance.

In Java you can only declare a single class as superclass. However, you can give a class as many interfaces as you wish. The same things get inherited (classes, methods, data) from both the superclass and the interface. The only difference is in what an interface can contain.

Interfaces can only define abstract methods, that is, object methods withut implementations. So you can inherit object method prototypes from an interface but not object method implementations. You can only inherit object method implemetnations from a superclass.

However, that does not mean you can't inherit implementations from an interface - you just have to define them in a member class. If an interface wants to provide inheritable implementations it usually does it this way. Then the subclass defines boiler plate code that implements each abstract object method inherited from the interface by wrapping one of the provided member class methods.

You can even go one further and implement the methods by sending the call to a proxy object which then identifies the interfaces and available methods via reflections and chooses which interface's implementation to use. Thus, even in Java you can roll your own inheritance scheme if you really, really want to.

The main difference as regards inheritance is really in how you write the code. In Perl, multiple inheritance of implementations is out-of-the-box. In Java, it is not and you have to do a lot of work and have a fair amount of Java expertise to emulate it.

Polymorphism

Both Java and Perl support true polymorphism, but Java gives you more explicit control over what others can do with your class. In Java you can prevent overriding of a method by declaring the method final and you can force subclasses to define a method by declaring it abstract. This makes it possible to do compile time checks on new classes.

Perl doesn't offer any such control. The best you can do to force declaration of a method is to have the superclass method die or spit out warnings. However, these warnings will only take effect if a running program tries to use a method that was not overridden and should have been. There is no compile time check. As for declaring methods final, I'm not sure how you would do it without doing something really fancy to intercept all additions to the symbol table. (Can that even be done?).

The upside of Perl's approach to polymorphism is that it is easier to patch bad code without actually editing it. In Java if a method is declared final by an over-aggressive OOP cop, and you are an API consumer you are stuck unless you can rewrite that class. In Perl, you are never stuck that way.

The downside is that if that final method is really important to the class's longterm health and right use, you have to write a conformance test suite for subclasses. In Java the compiler will do all the work for you.

Some final thoughts

The biggest difference however between Java and Perl isn't in the three topics you mentioned (Encapsulation, Inheritance, and Polymorphism), but rather in something much deeper: the underlying model for bundling functionality and data into a single unit or object.

In Java you are forced into a data centric notion of object. In Perl you can choose between a functional and a data centric object.

In Perl, if all your data is used by one main function, in lieu of defining a package, you can define a closure function that will hold copies of all relevant data plus its own code. This is often much neater and simpler than defining a class and all its apparatus.

In Java, the only way to combine data and functionality in a unit is to declare a class. To be sure, you can define a temporary class with a single method and place it within a method call. Like a closure it grabs copies of the data in the surrounding method. However, you still need to do all the boilerplate code required for a class declaration even though all you want is that one class method.

Someone just got an A.

Despite the suspected possible essay question from the OP — I just wanted to say how glad I am you went ahead and wrote this reply. As someone who is in the thick of studying OOP in Perl this was very helpful.

In particular, I've been studying closures this week. (Through perldoc perlref and the Camel book.) I've find it to be a really interesting technique that I suspected allows one to flirt with OOP without having to fully dive in. I'm still honestly having some trouble wrapping my head around it (let alone OOP in Perl) which I don't think will improve until I use it more regularly and make my first 999 mistakes. Your post did help clarify the way a little more. Again, thanks.



"...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." — Don Quixote

what is difference between Oops concepts in Perl and Java in terms of implementation.

Perl's builtin object model is pretty fundamental. It allows for arbitrary models to be used.

Encapsulation

Perl doesn't define how to implement attributes, so encapsulation is up to the specific model used.

In most cases, the attributes are easily accessible from the outside, but encapsulation is still very strong. It's just that it's enforced by policy, not by technical means.

Inheritance

Single and multiple. Two different method resolution order for multiple inheritance.

Polymorhpism

Yes. All methods are virtual, basically.

I don't like Perl OO too much, IMHO there are two many ways to do it! If you want to use OO in Perl I suggest to take a look at Moose. There is manual and a cookbook to get you started.

There are big differences, the two languages are completely different. On top of what ikegami said Let me add/clarify something on Inheritance. Perl supports both single and multiple inheritance. In Java multiple inheritance is not supported directly. This was a design decision. Instead Java has the concept of interfaces. According to some multiple inheritance is evil. The standard argument is the "diamond problem":

  A
 / \
B   C
 \ /
  D
[download]

Suppose a virtual method in A is implemented by both B and C. Question: Which one do you get when you instantiate D?

If you use the Java's interfaces it's not a problem, interfaces don't have implementations. If you make A, B, and C all interfaces, then D chooses how to implement the A method. The Java interfaces are a kind-of multiple inheritance but simplified. Having said this if you use abstract base clases with pure virtual functions (I'm thinking more C++ here) there is no reason why you can't use multiple inheritance.

Cheers

Harry

And for the rest of it, Perl's approach to objects is like C's approach to regular expressions: C gives you pointers to lists of numbers, and that's enough to build your own regexp engine. Similar, Perl gives you the bare minimum to build an object system but leaves all the heavy lifting of building a useful system to the programmer. So we get to make the same mistakes again, and again, and again. So we have had hashref based objects, arrayref based objects, pseudo-hashes, base, fields, locked hashes, fly-weight objects, inside out objects, spiffy, fieldhashes, moose, mouse, and other things I cannot remember. And the next couple of years, people will find other implementations because all the previous ones suck.

An object in Perl is really just a reference that has been blessed into a namespace (and that could be a blessed directory handle if you are that perverse).

Together with dynamic features like AUTOLOAD that makes it (in the general case) very hard to introspect objects (i.e. figuring out at runtime which attributes and methods an object has) - something that is easy in Java.

Also classes in Java are "closed" i.e. you cannot add new methods at runtime whereas in Perl a "class" is just a package and methods can be added easily at runtime.

Finally (this is where Java wins hands-down) the memory-management (i.e. garbage-collection) in Perl is based on a simple reference-counting algorithm whereas in Java is is a mark-and-sweep strategy which means that whole graphs of unreachable objects will be garbage-collected in Java whereas in Perl a simple circular reference will leak memory unless you explicitely weaken a reference.

Eh? Is Google down or something?

...roboticus

When your only tool is a hammer, all problems look like your thumb.