+ 4
Which one is true:
Why we declare a class as abstract class: 1. We declare a class as abstract because we are not intending to create the object of that class? Or: 2. We don't exactly no the real implementation of the class. Think about overridding class method as the early explanation in equation to calculate the area of square and rectangle please? Do you think both answer are reasonable? Thank you class, Joy, prof ondola, Monica, Rik Wittkop, AJ for your explanation:)
5 Answers
+ 3
Your first statement is true per definition, because it is not possible to instantiate an abstract class anyway.
But I don't agree with statement 2. It's not about not knowing the implementation. Using abstract class is about code extensibility and code sharing. We build a class hierarchy because some objects have shared functionality but different implementations. Like we can calculate the area of any shape, but for each specific type of shape the formula is different. And by adding a triangle and a circle later, most likely our code which displays the area of shapes, will be unaffected, because the different calculation method is only added in the new subclasses.
Most of the time though, I would prefer writing an interface, instead of an abstract class.
+ 2
Point one is correct.
Point two is misguided. It's not about not knowing, it's about the fact we can't write an implementation generic enough for any and all subclasses, and thus we need to enforce implementation on concrete subclasses, where an implementation makes sense.
+ 1
But in the earlier stage of oop learning, many books eventually lecturers explain that abstract class (sure it contains at least 1 pure virtual function or event virtual function in c++ or abstract method in Java), is written because we don't really know what Will be the exact or concrete implementation of this abstract method.
0
If so, have you ever consider that all the authors aof programming languages (book) and lecturers should revise their handwriting especially about their examples at the early teaching of OOP particularly in introduction to abstract classes and virtual function? Or, it just a simplification at the early stage of abstract classes and virtual functions which in turn will lead to inheritance and polymorphism (method or function overloading and overridding)? We can't Deny the facts that many AUTHORS still write on their books that the reason why an engineer write an abstract class is because we, they don't really know what the detailed implementation looks like but we know that each geometrical shape has it own specific function to calculate its own area?
0
May be we need to differentiate between problems arise in developing of something like text-based programming and graphical-based programming. Because for example, in GUI, components that extends from JFrame for example, only related with adjustment the size, bgcolor, caption, and so on. You can extends JFrame1 from existing JFrame which only need to adjust or override it initial parameter, height, width, background, add an event associate to new JFrame1 component and other attributes or property. It is slighly different from designing from the scratch, something new, but we can't decide at this moment the graphical representation of the enemy objects in game you have developed, you can't visualize the pyshical representation of enemies, monsters, ninjas, or event you don't know the kinds enemies objects to be visualize.