Object Oriented Programming
In his book Object Oriented Software Construction (1st edition 1988, 2nd edtion 1997) Bertrand Meyer gave a clear and precise definition of what object oriented programming (OOP) is:
Object oriented software construction is the building of software systems as structured collections of implementations of abstract data types.
Structured means that there are is a and has a relations between the building blocks of the software system.
These building blocks - called classes - are implementations of abstract data types.
An abstract data type describes a data type with the help of four sections:
Due to the don't repeat yourself princile (DRY) Bertrand Meyer added the concept of class invariants to this concept in order to avoid redundancy of postconditions, as all methods of an abstract data type might have some postconditions in common. Therefore a class invariant can be regarded as a postcondition which has to hold true for all methods of an abstract data type.Accepting this definition of OOP as given and correct and accepting further that analysis, design, implementation and test are essential activities in the course of object oriented programming, there is a first demand on the design level of what an object oriented language has to be able to provide:
On a design level an object oriented programming language must be able to declare a new type by defining its entire abstract data type, i.e. the specification of the new type.
As the OOP definition above also demands the implementation of that abstract data type, there is a second demand on the implementation level of what an object oriented language has to be able to provide:
On an implementation level an object oriented programming language must be able to add a new type by implementing a class which fulfills the specification.
What does that mean to Java? Java seems to fulfill the second demand as it offers the concept of classes and allows us to write a kind of specification by using the concept of javadoc comments. But what about the first demand? Is is possible in Java to define an entire abstract data type on a design level? On a design level Java offers the concept of interfaces to define a new type on an abstract level. But interfaces offer only two of the demanded four sections of an abstract data type:
To overcome that inablity to define an entire abstract data type, Java 1.4 introduced the assert keyword to be able to define preconditions and postconditions as assert statements. As the assert keyword of Java is only applicable on an implementation level, i.e. in method bodies and furthermore is lost by overridding a method, Java did not succeed to overcome that flaw. The direction using assetions was right but but done halfhearted.Java needs an extended concept of assertions in order to be able to address the missing two sections of an abstract data type:
That is where the C4J concept of interface contracts and C4J concept of class contracts comes in. These two concepts are added to Java by C4J. As a result, both demands on object oriented programming languages are fulfilled:
On a design level interface contracts enable Java to declare a new type by defining its entire abstract data type, i.e. the specification of the new type. This is done by two software development techniques called Analysis by Contract and Design by Contract.
On an implementation level class contracts enable Java to add a new type by implementing a class which fulfills the specification, i.e. by adding pre- and postconditions to methods, which can not be declared in interfaces in Java such as constructors or protected methods. This is done by two software development techniques called Implementation by Contract and Testing by Contract. By activating the interface and classs contracts, C4J checks at runtime whether the implementation fulfills the specification.To sum up, C4J extends the concept of assertions in Java to fulfill the definition of object oriented programming. Or even shorter:
C4J makes Java an object oriented programming language!