Home > Back-end >  Does an absract class also force the exposing of implementaion details?
Does an absract class also force the exposing of implementaion details?

Time:01-28

One definition of abstraction is hiding the implementation details and the one I am using for this question.

I read the question and many answers for using abstract in Java (Abstract class in Java). However, if we can define the functionality we want in subclasses from an abstract class, this seems to also contain the opposite of abstraction.

That is, by writing an abstract class we are exposing the implementation details.

If we look at the point of view from with in the implementing class, the only hidden implementation details provided by abstract class are

final public void finalMethod()

and

public void implementedMethod() // considering we do not override it.

However:

abstract public void abstractMethod();

seems to do the opposite of abstraction, as now we are in fact forced to implement this method, i.e. expose the implementation details.

What is the opposite of abstraction?

One answer is concretization as see here in "What’s the opposite of abstraction?" on Software Engineering.

The refined question is can an abstract class provide both abstraction and concretization?

It appears to do both.

CodePudding user response:

If I understand your question right, to clarify what hiding the implementation means in this context you should approach it from the other way around.

It is not the abstract class that hides anything, but the class that extends (and eventually implements) the abstract class is hidden from the abstract classes point of view.

The abstract classes function is not to hide the implementation, but to share code between related classes.

For the second part of the question, Yes!. An abstract class can provide concretization. Meaning you can provide implementation in an abstract class in Java. Hiding implementation is not the purpose of abstraction in Java, but rather a side effect in my opinion.

A very similar question had already been posted in this SO thread You can check out it's accepted answer as well.

CodePudding user response:

Based on your comment clarifying the type of answer you are looking for, here's what I would say:

Basically, you have the right idea. Abstraction in Java (and in software dev in general) means that parts of the class must be filled in later, within a given framework. For instance, check out ServerSocketEx

The purpose of this class is extend what java.net.ServerSocket gives you with a a framework. In the framework, you must define two things: A factory that creates socket runners/handlers, and an implementation that specifies what the SocketRunner should do with incoming data. This enables the ServerSocketEx to accept connections and create a handler and a thread to run it. It is concrete in its implementation of accepting connections and in the API a SocketRunner needs to abide by, but abstract in how those connections should be processed

  • Related