About Question enthuware.ocpjp.v8.2.1229 :

Help and support on OCA OCP Java Programmer Certification Questions
1Z0-808, 1Z0-809, 1Z0-815, 1Z0-816, 1Z0-817

Moderator: admin

Post Reply
schchen2000
Posts: 106
Joined: Mon Mar 28, 2016 11:36 pm
Contact:

About Question enthuware.ocpjp.v8.2.1229 :

Post by schchen2000 »

You want to pass different implementations for the same abstraction in method calls.
Does the following code precisely describe what you meant in the quote above? What's in the quote above is the last answer option given. Thanks.

Code: Select all

abstract class AbstractClass{

        public abstract void foo();

}

class InheritedClass extends AbstractClass{

        public void foo(){

                System.out.println("\nThis is foo() from InheritedClass....");

        }   

}

public class AbstractionTest extends AbstractClass{

        public void foo(){
 
                System.out.println("\nThis is foo() from AbstractionTest....");
  
        }   

        public static void main(String... args){

                AbstractClass temp = new InheritedClass();

                temp.foo();

                temp = new AbstractionTest();
  
                temp.foo();

        }    

}

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1229 :

Post by admin »

That is correct.
If you like our products and services, please help us by posting your review here.

schchen2000
Posts: 106
Joined: Mon Mar 28, 2016 11:36 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1229 :

Post by schchen2000 »

admin wrote:That is correct.
Thanks.

Ingvarr
Posts: 7
Joined: Sun May 08, 2016 8:09 am
Contact:

Re: About Question enthuware.ocpjp.v8.2.1229 :

Post by Ingvarr »

Do I understand correctly that datatypes are considered related if and only if they have IS-A relationship? Like in 'class B extends A, therefore A and B are related', is that correct?

Same question from another angle: although all classes derive from Object, we cannot say that such and such classes are related simply by having a common ancestor, right?

What about common functionality? Suppose, we take this merry bunch where all concrete classes derive from the abstract class OutputStream:
[img]
OutputStreamFamily.png
OutputStreamFamily.png (17.49 KiB) Viewed 4506 times
[/img]
These classes have lots in common because we use them within one particular domain, IO operations, yet we can't say that FileOutputStream and ObjectOutputStream are related? or can we? Similarly, would having a common superinterface make classes related? Like, lots of data structures implement Collection; are LinkedHashSet, ArrayList and LinkedList related? Okay, so these particular types override many methods, but what about the case where some classes are using lots of common methods defined in a superinterface? By the way, what IS a common method, precisely? the one that has the same signature across several classes? or just a commonly shared name?

All these questions lead to this: what reasons would make us choose interfaces over abstract classes? Right now I'm thinking that we should start our hierarchy with an interface when classes that implement it have many common – or should I say 'non-overridden'? – methods, but I keep seeing conflicting info on the web… Some people maintain that if state more important than behavior we'd better use abstract class… And then there is always this mind-boggling Java Collections Framework where AbstractCollection sits right underneath Collection, which sort of hints on practically equal importance… Frankly, I'm lost here; need a friendly nudge in right direction…

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1229 :

Post by admin »

First of all you need to remember that "related" is not a technical term. But this term is used in the context of is-a relationship in a matter of speaking. Parent-Child, ancestor, base class, super class, sub class are all unambiguous technical terms and are preferred to "related".
As you have noted, Object is the root of all classes. In that sense, all classes are related. But this is not the meaning of "related" that is generally ascribed to this term because being related in this sense doesn't tell you anything new. At the same time, FileOutputStream and ObjectOutputStream have OutputStream as a common ancestor, which is a lot more meaningful than Object. So in the context of OutputStream, both the classes are related.

Now, B is-a A is true only if A is a super class of B. In other words, if A is an ancestor of B or A is a parent of B.

There have been a lot, and I mean A LOT, of discussions, articles, and thoughts written on when to choose interface and when to choose an abstract class. I will suggest you to google this so that you will get to know what industry experts thing and that will give you a good handle on it.

For two classes to have "common functionality", they must be related through a common ancestor that has this common functionality. It could be either an abstract class or an interface. Merely having same method (and signature) does not mean that the classes have common functionality in a technical sense because you cannot pass one class for the other unless you have a shared ancestor. For example, if you want to pass an OutputStream to some method, you can pass a FileOutputStream or an ObjectOutputStream because they do share common functionality through OutputStream. If these classes didn't extend or implement OutputStream, you wouldn't be able to pass either of them to a method that required OutputStream even if both the classes may contain the same methods as OutputStream.

A lot of these terms that you have asked about are more about common sense than about technicality. So you need to think logically about them. If you want an Animal as a pet, you will be happy with a Dog or a Cat because they are both Animals (common functionality) but not a Robot even though it might have a lot of the same functionality as an Animal.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

Ingvarr
Posts: 7
Joined: Sun May 08, 2016 8:09 am
Contact:

Re: About Question enthuware.ocpjp.v8.2.1229 :

Post by Ingvarr »

First of all you need to remember that "related" is not a technical term. But this term is used in the context of is-a relationship in a matter of speaking. Parent-Child, ancestor, base class, super class, sub class are all unambiguous technical terms and are preferred to "related".
Yes Paul, I realise that --- and this is the root of all my worries. It appears that "related classes" is the accepted terminology favored if not by the industry then by Oracle itself. Say, just the last night I googled up this rather sloppy term with a site: filter applied (like this: site:http://docs.oracle.com/javase "related classes"), and sure enough, the dreaded expression cheerfully popped up in lots of places. For example, at https://docs.oracle.com/javase/tutorial ... tract.html:
Which should you use, abstract classes or interfaces?
•Consider using abstract classes if any of these statements apply to your situation:
  • ◦You want to share code among several closely related classes.
    ◦You expect that classes that extend your abstract class have many common methods or fields, or require access modifiers other than public (such as protected and private).
    ◦You want to declare non-static or non-final fields. This enables you to define methods that can access and modify the state of the object to which they belong.
•Consider using interfaces if any of these statements apply to your situation:
  • ◦You expect that unrelated classes would implement your interface. For example, the interfaces Comparable and Cloneable are implemented by many unrelated classes.
    ◦You want to specify the behavior of a particular data type, but not concerned about who implements its behavior.
    ◦You want to take advantage of multiple inheritance of type.
Mala Gupta's prep guide on 1Z0-804 (JSE7) is also using the derived-versus-related dichotomy quite liberally. Incidentally, Jeanne Boyarsky and Scott Selikoff's book on 1Z0-808 is much tidier in this respect, that's why I liked it best. But I'm so tired of all such ambiguities, there are so many of them...

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1229 :

Post by admin »

The problem is there is no precise definition of "related classes". This meaning of this term depends on the context as I explained in my post above.
If you like our products and services, please help us by posting your review here.

Javatje
Posts: 9
Joined: Wed Jun 30, 2021 6:53 am
Contact:

Re: About Question enthuware.ocpjp.v8.2.1229 :

Post by Javatje »

"You need to have a root class for a hierarchy of related classes."
This can be achieved with a concrete class also. Or can't it?

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1229 :

Post by admin »

Javatje wrote:
Fri Nov 12, 2021 5:26 am
"You need to have a root class for a hierarchy of related classes."
This can be achieved with a concrete class also. Or can't it?
Yes, it can be. What is your point? The problem statement doesn't say abstract class is the only way to do it! It is merely asking you to pick one out of abstract class or an interface given a situation.
If you like our products and services, please help us by posting your review here.

Post Reply

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 40 guests