0

i have researched the topic of abstract classes. And I am not sure, if I understand the sense of this construct.

Is it right, that abstract classes are only control structures in OOP, respectively that I don't forget to implement a method in a sub class? I see no other benefits. I know that abstract classes never become an object. So, what the sense / benefits of abstract classes, abstract methods etc.?

Thanks for help.

Green1492
  • 35
  • 5
  • 1
    Does this answer your question? [Benefits of using an abstract classes vs. regular class](https://stackoverflow.com/questions/3182440/benefits-of-using-an-abstract-classes-vs-regular-class) – derpirscher Feb 12 '22 at 13:43
  • No, not really :/ – Green1492 Feb 12 '22 at 14:43
  • I think the best question to start with is to ask, _what is [abstraction](https://stackoverflow.com/questions/41661603/abstraction-as-a-definition)?_ After gaining a firm grasp of abstraction itself, it becomes clear that abstract classes in a given language are just one (syntactic) means of achieving that goal. – jaco0646 Feb 12 '22 at 18:20

1 Answers1

3

Is it right, that abstract classes are only control structures in OOP, respectively that I don't forget to implement a method in a sub class?

This is actually the responsibility of interfaces.

Abstract classes are for sharing the code, the logic or behavior between multiple subclasses. And because the behavior provided by the base class may require that some missing parts of the logic are provided by subclasses, we can declare a base class as abstract and declare abstract members in it - similarly to interfaces. "abstract" in this context basically means that the functionality is incomplete and can't be used straight away, without filling the gaps.

In practice, sharing of the code through subtyping is generally discouraged and therefore abstract classes are less popular nowadays than in the past. We learnt that it is usually better and easier to maintain if we share the code by composition of multiple separate classes than by subclassing (https://en.wikipedia.org/wiki/Composition_over_inheritance).

Edit: see this example:

abstract class AbstractDataHandler {
    fun doSomething() {
        // acquire data
        processData(data)
        // do something else with data
    }

    abstract fun processData(data: Data)
}

class MyDataHandler : AbstractDataHandler() {
    override fun processData(data: Data) {
        // process data
    }
}

We have some kind of a data handler. At some point it has to perform some kind of data processing, but this processing should be different depending on the specific subclass. So AbtractDataHandler can't perform the whole operation alone. It needs a way to invoke data processing step that is provided by the subclass. It defines this processing as an abstract function.

The same example could be implemented with composition instead:

interface DataProcessor {
    fun processData(data: Data)
}

class DataHandler(private val processor: DataProcessor) {
    fun doSomething() {
        // acquire data
        processor.processData(data)
        // do something else with data
    }
}

(In this specific case it would be probably more Kotlin-ish to not use an interface, but a function type.)

Also, abstract classes are common if we need to implement an interface and there is some very basic functionality that is the same across all implementations. For example, all implementations have to provide the same fields for storing the data. Then abstract class could provide these fields, but it does know nothing about implementing the rest of the interface, so most of functions remain abstract.

broot
  • 21,588
  • 3
  • 30
  • 35
  • thank you for your explanation. But that raises more questions :( - When I want to use inheritation I build an abstract class. For example, I can use the methods from the inherited class. That is clear to me respectively i know the benefits of inheritation. But why I build an abstract class and an abstract method or a methode which functionality is incomplete? – Green1492 Feb 12 '22 at 14:43
  • 1
    Because we need to access a functionality from the base/abstract class and this functionality is provided by the subclass. Abstract class needs a way to somehow reference this functionality and it does this by defining a function that is not yet available - it's abstract. Then subclass provides it. I can provide an example later today. – broot Feb 12 '22 at 14:51
  • See updated answer. – broot Feb 12 '22 at 16:13
  • Thank u. When we define an abstract class, it is required to define a subclass respectively the compiler throw an error, if we don't define a subclass? Is it the same with abstract methods (override)? – Green1492 Feb 12 '22 at 16:41
  • I'm not sure what do you mean. When we define an abstract class, it is not required to define its subclass. But we won't be able to instantiate this abstract class directly, because it's "incomplete". If we create its subclass then yes, we are required to implement all missing pieces (all abstract members). – broot Feb 12 '22 at 17:02
  • An abstract class can have many different concrete subclasses — some not imagined when the abstract class was written. Look for example at [AbstractList](https://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html), which provides almost all you need to implement the [List](https://docs.oracle.com/javase/8/docs/api/java/util/List.html) interface properly: iteration, scanning, sublists, etc. All you need to provide are getters for an element and for the size — it implements everything else in terms of those (though sometimes less efficiently than you could do directly). (contd…) – gidds Feb 12 '22 at 19:18
  • …It's an abstract class and can't be instantiated, because it doesn't know anything about how or where the list elements are stored; that's what you have to provide in a subclass. (They could be in an array, encoded in some complex structure, on disk, on a remote machine… The abstract class doesn't need to know.) Note that while those abstract methods are part of how it interacts with its subclasses, to _users_ of the subclass, those are just implementation details — all its users care about are that it implements `List`. – gidds Feb 12 '22 at 19:18