The basic idea is for the abstract class to provide the skeleton and basic functionality and allow the concrete implementation to provide exact details.
Suppose you have an interface with ... +20 methods, for example, with the List interface.
List {interface } + add( object: Object ) + add( index:Int, object: Object ) + contains( object: Object ): Bool + get( index : Int ): Object + size() : Int ....
If someone needs to provide an implementation for this list, he must implement +20 methods each time.
An alternative could be the presence of an abstract class that already implements most of the methods and allows the developer to implement several of them.
for example
To implement a non-modifiable list, the programmer only needs to extend this class and provide implementations of the get (int index) and size () methods
AbstractList: List + get( index: Int ) : Object { abstract } + size() : Int { abstract } ... rest of the methods already implemented by abstract list
In this situation: get and size are abstract methods that the developer must implement. The rest of the functionality may already be implemented.
EmptyList: AbstractList { public overrride Object Get( int index ) { return this; } public override int Size() { return 0; } }
Although this implementation may seem absurd, it would be useful to initialize the variable:
List list = new EmptyList(); foreach( Object o: in list ) { }
to avoid null pointers.
OscarRyz
source share