0

My question is. Are these the same? 

public class Pet {
}

public class Fish extends Pet {
}

If I extend the class Pet to my Fish class, is that the same as if I instantiate the Pet class in my Fish class? The extends is above and the instantiate is below. Are they the same?

public class Pet {
}

public class Fish {

Pet myPet = new Pet ();
}
ᴘᴀɴᴀʏɪᴏᴛɪs
  • 7,169
  • 9
  • 50
  • 81
Houzi88
  • 27
  • 2
  • 1
    No, they are not the same. You need to do a bit of reading on just what inheritance is in OOP. – alzee Dec 21 '16 at 19:11
  • 1
    When you extend a class you are defining another class (subclass) which inherits some attributes and methods of the first class. When you instantiate a class you are creating a new object (instance) of that class. In your code, in the first case you are creating a new class named Fish which has some common things (inherited) with the class named Pet, then Fish is a subclass of Pet, while in the second case you are creating a new class, also named Fish, which does not have things in common with Pet, but it hast an attribute named myPet of type Pet. – Sergio Pio Alvarez Dec 21 '16 at 19:13
  • Google composition vs inheritance – StaticBeagle Dec 21 '16 at 19:16
  • Why would I choose one over the other? Don't they technically do the same thing though? Allow you to just call methods in that given class? – Houzi88 Dec 21 '16 at 19:21

4 Answers4

0

They are not the same.

In the first example, with inheritance, an instance of a Fish can access all of it's own properties and methods, including those inherited from Pet, via this or self, depending on language.

In the second example, myPet is just a variable that happens to be an instance of the Pet class, but Pet and Fish have no relationship to each other.

alzee
  • 1,393
  • 1
  • 10
  • 21
0

No, They are completely different.

In this one public class Fish extends Pet { } you are using inheritance to extend the Pet class to the Fish class, meaning that Fish is a subclass of Pet it will inherit the Pet class.

However in this one

 public class Fish {

 Pet myPet = new Pet (); }

You are creating a whole new object called Fish which does not extend from anything, just that it has a class level object that is a Pet, so you can use the Pet objects methods variables etc through the myPet object however it is not inherited by Fish so Fish would be its own object and not a subclass of Pet.

These are the differences.

As for when you should use which, here is the general rule: if you are enhancing a class then you should use Inheritance, however if you are just going to be using a class for its particular function then you should instantiate it as a variable in the class.

SteelToe
  • 2,477
  • 1
  • 17
  • 28
  • Thank you very much for your response! – Houzi88 Dec 21 '16 at 19:22
  • Why would I choose one over the other? Don't they technically do the same thing though? Allow you to just call methods in that given class? – Houzi88 Dec 21 '16 at 19:25
  • Generally if you are going to be enhancing a class, then it is better to use inheritance, however if you are just going to be using a class, then it is better to use it in the form of creating a new object to use it – SteelToe Dec 21 '16 at 19:28
0

They are completely different. extends is 'is-a' relationship , while later (composition) is 'has-a'. Take a look here for more details.

dhamu
  • 605
  • 1
  • 7
  • 17
0

First example describes inheritance, the second one - composition. Those are two OOP concepts. They allow programmer to reuse common logic. Your should prefer to use composiiton over inheritance.

Copy from other SO answer:

They are absolutely different. Inheritance is an "is-a" relationship. Composition is a "has-a".

You do composition by having an instance of another class C as a field of your class, instead of extending C. A good example where composition would've been a lot better than inheritance is java.util.Stack, which currently extends java.util.Vector. This is now considered a blunder. A stack "is-NOT-a" vector; you should not be allowed to insert and remove elements arbitrarily. It should've been composition instead.

Unfortunately it's too late to rectify this design mistake, since changing the inheritance hierarchy now would break compatibility with existing code. Had Stack used composition instead of inheritance, it can always be modified to use another data structure without violating the API.

I highly recommend Josh Bloch's book Effective Java 2nd Edition

Item 16: Favor composition over inheritance

Item 17: Design and document for inheritance or else prohibit it

Good object-oriented design is not about liberally extending existing classes. Your first instinct should be to compose instead.

Community
  • 1
  • 1
marknorkin
  • 3,904
  • 10
  • 46
  • 82
  • So they are basically the same? They just allow a certain class to use another class methods? So why choose one over the other? What you're saying is to instantiate the class instead of extending because it's easier to edit later down the road? – Houzi88 Dec 21 '16 at 19:27
  • @Houzi88 The first line of the citation reads "They are absolutely different.". – Meik Vtune Dec 21 '16 at 19:28
  • @MeikVtune They are different but they do the same thing basically, right? – Houzi88 Dec 21 '16 at 19:32
  • 1
    @Houzi88 well, as I said they allow programmer to reuse common logic. The inheritance at first may seem easier, but later it's hard to maintain it and reason about code that uses it. Use "is-a" and "has-a" rules to determine which one you need – marknorkin Dec 21 '16 at 19:46