30 CRITERIA FOR OBJECT ORIENTATION $2.2 value.So you can handle objects whose type you do not know for sure,without violating the safety of the type system. It should be possible to determine at run time whether the type of an object conforms to a statically given type. Deferred features and classes In some cases for which dynamic binding provides an elegant solution,obviating the need for explicit tests,there is no initial version of a feature to be redefined.For example class BOAT may be too general to provide a default implementation of turn.Yet we want to be able to call feature turn to an entity declared of type BOAT if we have ensured that at run time it will actually be attached to objects of such fully defined types as MERCHANT SHIP and SPORTS BOAT. In such cases BOAT may be declared as a deferred class (one which is not fully implemented),and with a deferred feature turn.Deferred features and classes may still possess assertions describing their abstract properties,but their implementation is postponed to descendant classes.A non-deferred class is said to be effective. It should be possible to write a class or a feature as deferred,that is to say specified but not fully implemented. Deferred classes (also called abstract classes)are particularly important for object- oriented analysis and high-level design,as they make it possible to capture the essential aspects of a system while leaving details to a later stage Memory management and garbage collection The last point on our list of method and language criteria may at first appear to belong more properly to the next category-implementation and environment.In fact it belongs to both.But the crucial requirements apply to the language;the rest is a matter of good engineering. Object-oriented systems,even more than traditional programs (except in the Lisp world),tend to create many objects with sometimes complex interdependencies.A policy leaving developers in charge of managing the associated memory,especially when it comes to reclaiming the space occupied by objects that are no longer needed,would harm both the efficiency of the development process,as it would complicate the software and occupy a considerable part of the developers'time,and the safety of the resulting systems, as it raises the risk of improper recycling of memory areas.In a good object-oriented environment memory management will be automatic,under the control of the garbage collector,a component of the runtime system. The reason this is a language issue as much as an implementation requirement is that a language that has not been explicitly designed for automatic memory management will often render it impossible.This is the case with languages where a pointer to an object of30 CRITERIA FOR OBJECT ORIENTATION §2.2 value. So you can handle objects whose type you do not know for sure, without violating the safety of the type system. Deferred features and classes In some cases for which dynamic binding provides an elegant solution, obviating the need for explicit tests, there is no initial version of a feature to be redefined. For example class BOAT may be too general to provide a default implementation of turn. Yet we want to be able to call feature turn to an entity declared of type BOAT if we have ensured that at run time it will actually be attached to objects of such fully defined types as MERCHANT_ SHIP and SPORTS_BOAT. In such cases BOAT may be declared as a deferred class (one which is not fully implemented), and with a deferred feature turn. Deferred features and classes may still possess assertions describing their abstract properties, but their implementation is postponed to descendant classes. A non-deferred class is said to be effective. Deferred classes (also called abstract classes) are particularly important for object￾oriented analysis and high-level design, as they make it possible to capture the essential aspects of a system while leaving details to a later stage. Memory management and garbage collection The last point on our list of method and language criteria may at first appear to belong more properly to the next category — implementation and environment. In fact it belongs to both. But the crucial requirements apply to the language; the rest is a matter of good engineering. Object-oriented systems, even more than traditional programs (except in the Lisp world), tend to create many objects with sometimes complex interdependencies. A policy leaving developers in charge of managing the associated memory, especially when it comes to reclaiming the space occupied by objects that are no longer needed, would harm both the efficiency of the development process, as it would complicate the software and occupy a considerable part of the developers’ time, and the safety of the resulting systems, as it raises the risk of improper recycling of memory areas. In a good object-oriented environment memory management will be automatic, under the control of the garbage collector, a component of the runtime system. The reason this is a language issue as much as an implementation requirement is that a language that has not been explicitly designed for automatic memory management will often render it impossible. This is the case with languages where a pointer to an object of It should be possible to determine at run time whether the type of an object conforms to a statically given type. It should be possible to write a class or a feature as deferred, that is to say specified but not fully implemented