Forum Stats

  • 3,728,470 Users
  • 2,245,631 Discussions
  • 7,853,548 Comments

Discussions

Abstraction in java

User_JARGP
User_JARGP Member Posts: 3 Green Ribbon

I am just a beginner in java and have some queries on abstraction in java

1 :- Suppose I have created an interface CalArea which have abstract area function mentioned in it.

Now I have created two classes Square and Circle both implements CalArea interface and overrides the method area to calculate the area of shape and the code is working fine.

My question is If I remove interface or instead of implementing an interface I am calculating the area of Square and Circle using area method which is not overrided.

Will it still be called an abstraction ?

Because in both cases we are using concrete class object to call area function as we couldn't create objects of interface. And we are only providing the essential detail to user that is method name instead of method implementation.

2. In my opinion interface only force us to implement some methods which are common to all class to lie in particular category.

For example : If Ferrari needs to be car it should implement some features which are common to all cars . Just the implementation could me different with some extra features added on it.

How can interface provide 100% abstraction just because it doesn't have concrete methods. At last user will use the object of class which implements interface to access the method. so if user is only using method name then even without interface we are achieving 100% abstraction.

As per my knowledge abstraction means just allowing user to use method name to perform his/her task rather than method implementation details. Which we even do without interface and abstract class.

Please correct me if I am wrong

Tagged:

Comments

  • Vasily Strelnikov-Oracle
    Vasily Strelnikov-Oracle Member Posts: 8 Employee

    First of all, I'd like to make couple of factual corrections:

    1. Interface defines one or more behaviours that any other class can implement, regardless of what that class is, or which part of the class hierarchy it is from. Notice, we are not talking about "all class to lie in particular category".

    2. Interfaces can define default, private and static methods that are concrete. Coincidentally this has nothing to do with the discussion about abstraction. 

    Now let's address the understanding of abstraction. 

    It seems to me there is some kind of confusion here between a concept of encapsulation, and a concept of abstraction. 

    Encapsulation is all about hiding implementation details of a given type. The narrow understanding of this principle is making instance variables private and providing public methods to operate on the variables. But there is also a wider understanding that any implementation details such as internal mechanics and logic implemented within a class is encapsulated, behind a "facade" of its public methods. Which means that an invoker of a method does not need to know this methods implementation details. 

    Let's now proceed to abstraction principle explanation: 

    Example 1 

    Consider the following code fragment:

    public void someMethod(ClacArea ca) {
     ca.calculate();
    }
    

    Assume that ClacArea is an interface that defines the calculate method, and that it can be implemented by a variety of different classes. 

    In this example, someMethod does not care if you pass a Square, or Circle, or an Elephant as an argument, so long as it implements the CalcArea interface. Without such interface you would have to write code to implement each specific calculation use-case separately. The role of the interface in this case is to guarantee that all classes that implement it, override this calculate method, and thus it can be consistently used without having to perform any type-checks or type-castings. 

    Summary: This someMethod in the example does not care, or even know anything about specific implementations of the CalcArea, because the only thing it considers relevant is the abstract method defined by the interface itself. - Sounds like a good example of abstraction principle, doesn't it?

    Example 2 

    Consider the following code fragment:

    public void someMethod(Square s) {
     s.calculate();
    }
    public void someMethod(Elephant e) {
     e.calculate();
    }
    

    and so on...

    Indeed invoker (i.e. someMethod) does not need to know what exactly is going on inside calculate method (sounds like encapsulation, isn't it?), but it still has to be aware about specific concrete class (Square, Elephant) that provides this implementation. Notice the word "concrete" that is the antonym of "abstract".

    Now revisit the first example - Notice how invoker (i.e. someMethod) does not even know which specific concrete implementation of the interfaces it is actually using at any point. Well that is because it is relying on the interface to provide an abstraction layer that any class can implement.

    User_JARGP
Sign In or Register to comment.