0

I have few questions related to oop in java.

I understand that is-a relationship means inheritance.

I understand that can do relationship means I need to implement interfaces.

Problems arise here :

factory pattern

Now, if I have more variables eg:

in class Square -> int side; in class Rectangle -> int width , int height.... and so on.

If I do as suggested good practice , ie create a interface instance

Shape s = new Square();

then I cannot access instance variable side.

So, I had to rely on something like this :

Square s = new Square(); s.side = 3; s.draw();
  1. So, Is my design incorrect?
  2. Should class that implements interface only have the methods that interface has and nothing else for calling purposes?

Same question arises in case of Inheritance. eg: 

public class Animal{ } public class Reptile extends Animal{ } public class Dog extends Animal{ }

Now, If i try something like this :

Dog has its own variables like teeth, legs and eyes.

Animal a = new Dog(); a.teeth = 30; // will not work

OR

will it be correct according to practices like this :

Dog d = new Dog(); d.teeth = 30;

So, I am missing some design details? Please explain.

I my trying my best to make correct design.Just stumbled on these things.

Improve this question
1
  • can do ? no implementing interfaces is also an IS-A relation. You can declare it as the subclass,or, you can also cast it: InterfaceType a = getImplementation(); If you know that getImplementation() returns type A, you can say: InterfaceType a = getImplementation(); A a = (A)a; Commented May 21, 2015 at 11:01

3 Answers 3

Reset to default
1

I don't see any problems with the inheritance and polymorphism relevant to your design. (Except I would say that squares, circles, rectangles are shapes so maybe use inheritance instead). There might be something about Java syntax you're missing though.

Consider any declaration:

A test = new B()

The first keyword, A, tells the computer what the type of variable is. In this case, you guarantee the computer that whatever your variable refers to is going to be an A. The second keyword, test, is just the name of your variable. The third part, = new B() tells the computer that you're assigning test to refer to a new object of type B. As long as B is an A, you're fine.

Now let's consider the first example, with Square and Shape. If you say

Shape s = new Square()

you are telling the computer that s is reference to a Shape - i.e. "Whatever s is referring to is always going to be a Shape. When you set it = new Square() you are saying that you want it to reference a Square. This is fine because a Square is a Shape. However, you cannot then say s.side = 3 because s you have only guaranteed the computer that s refers to a Shape and not all Shapes have just 1 side length.

Suppose for sake of contradiction that you should be able to access s.side. Then how would you reconcile these two code blocks? 

Square s = new Square(); s.side = 3; System.out.println( s.side ); Shape s = new Square(); s.side = 3; s = new Circle(); System.out.println( s.side );

Clearly a Circle does not have a side which would "circumvent" our logic.

On the other hand, if you say

Square s = new Square();

You guarantee the computer that whatever s refers to will have a side property, and so you are allowed to access s.side.

Addition: Specific answer to your question "So, I am missing some design details?"

I don't think you are missing design details. I think you are just not quite getting what the code means. For example, there are cases where you want to say

Animal a = new Dog();

and there are cases where you want to say

Dog a = new Dog();

In determining what type identifier (Animal or Dog) you want to use, you ask yourself the question, "Am I operating on Animals or Dogs?" If you're operating on animals, you say

Animal a = new Animal();

Then, you could do more complex operations. For example, if you had a list of Animals and all Animals had a method live(), then you could go through the list and make all Animals live() without having to worry if its a Dog a Cat or a Camel. Code:

ArrayList< Animal > listOfAnimals = new ArrayList< Animal >(); //populate the list for ( Animal a : listOfAnimals ) { a.live(); }

If you're operating on only dogs (e.g. you need them all to bite), then you have to use the Dog identifier. Code:

ArrayList< Dog > listOfDogs = new ArrayList< Dog >(); //populate the list for ( Dog d : listOfDogs ) { d.bite(); }

What problems would arise if instead, we declared ArrayList< Animal > listOfDogs = new ArrayList< Animal >(); and made every element bite()?

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

Properties (variables that belong to the object like "side" in your Square example) are usually private in Java.

Ask yourself what you want to do with the properties that is common to all shapes. If there isn't anything, then they don't belong in Shape anyway. Width and height for example make sense in a Rectangle, but not in a Circle so they shouldn't be in Shape.

Say you wanted to calculate area though. That's common to all shapes but done in different ways for each of them.

In that case, you'd add a method to your interface (let's call it calculateArea()) and implement it put the different implementations in the various subclasses, so Square would calculate it using side * side, whereas Rectangle would use width * height and Circle would use Math.Pi * radius * radius.

So in this case, the properties should be private and belong to the subclasses as they are different in each of them, whereas things that are common to all shapes (like the ability to calculate the area) go on the interface.

I hope this makes it a bit clearer for you.

Improve this answer

Comments

1

Your design is correct (so far). To answer your questions specifically:

So, is my design incorrect? - no - it is correct, as far as it goes.

Should a class that implements an interface only have the methods that interface has and nothing else for calling purposes? No - it can and probably will have other methods as well. Otherwise, all classes implementing an interface would be the same.

You would only do:

Shape s = new Square();

if you want to perform operations on s that can apply to any shape (e.g. draw).

If you need to do Square specific things, you need to use a Square variable. There is nothing to say that you have to use a super-class.

I suggest you keep going with your design and find some real-word examples and then it will become clearer.

UPDATE:

Note that the new operation is probably going to be used inside your factories. Similarly, setting properties such as the number of sides will (or could) happen inside a factory method. Factories will always need to know about the exact type they are dealing with.

Outside of the factory, things can be more general.

So a rule that might help your design (but is not hard and fast) is to favour use of the specific classes in the factory and the Shape class outside of it.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.