In managed COBOL, each class inherits from exactly one other class. If the inherited class is not specified (in the INHERITS clause), then the class inherits from System.Object (.NET) or from java.lang.Object (JVM).
Context:
Program Structure Types
class-id A. 01 sField string. method-id doStuff. ... end method. class-id nestedClass. ... end class. end class.
See also the Core sample, which is available from $COBDIR/demo.
An abstract class cannot itself be instantiated, but non-abstract classes can inherit from the abstract class, and can be instantiated. Because an ABSTRACT class has to be inherited, it cannot be FINAL.
An abstract class typically contains abstract methods, which are not implemented in the class declaration, like method declarations in an interface. It is however possible for an abstract class to define non-abstract methods. A class inheriting the abstract class, and which is not itself abstract, must provide implementations for all the abstract methods defined in the abstract class. Only an abstract class can contain abstract methods.
Use OVERRIDE when implementing the members of an abstract class in the non-abstract members of the derived class, as shown in the following example:
class-id. Animal abstract. method-id MakeNoise abstract. *> No implementation allowed end method. end class. class-id Dog inherits type Animal. *> Overrides the MakeNoise method in the Animal class method-id MakeNoise override. display "Woof!" end method. end class.
In this example, the abstract class Animal contains the abstract method MakeNoise. Because the non-abstract class Dog inherits from the abstract class Animal, it must provide an implementation of MakeNoise using the OVERRIDE modifier.
An abstract class can contain non-abstract methods in addition to abstract methods.
A class that inherits an abstract class must also be declared as an abstract class if it does not provide implementation of the inherited class' members.
A final class cannot be inherited. Because of this, methods in a final class cannot be overridden.
Declaring a class as FINAL is useful to prevent subversion of the class. It prevents a subclass from potentially changing the intended class functionality by overriding its intended behavior.
Nested classes can access static fields, properties and methods within the containing classes.
The optional SHARING PARENT phrase in the nested class definition enables instance methods and properties in the nested class to access the instance fields, properties and methods in the containing class.
class-id ContainingClass. ... class-id Nested1. ... end class. class-id Nested2 sharing parent. ... end class. end class.
Nested classes with the SHARING PARENT phrase may only be instantiated from within an instance method in the enclosing class. They can access the instance members from that containing class, even when those instance members are private.
Such a nested class contains an implicit reference to an instance of its containing class. The nested class uses this reference to access the enclosing class's instance members. This means that the containing class instance will not be garbage collected until all references to the inner class held externally have themselves been garbage collected.
For example:
class-id ContainingClass. 01 companyName string value "Micro Focus". method-id instance1. 01 o type Nested2. set o to new Nested2 ... end method class-id Nested2 SHARING PARENT. method-id method2 display companyName end method. end class. end class.
Nested classes defined without the SHARING PARENT phrase may be declared as public, private or internal. Depending on the visibility specified, they can be instantiated from any context, not just from the containing class, and not just from instance methods. They can only access instance members of the containing class using an explicit object reference.