Objects: Concepts and Terms

C++ vs Smalltalk

 From: rmartin@oma.com (Robert C. Martin)

 There are two distinct vocabularies in OOT.  I call them the C++ and

 Smalltalk vocabularies because they is a correlation between

 the vocabulary that programmers use, and the language that they use.

 C++				Smalltalk

 -------------------------       ------------------------------

 Class				Class

 Object				Object

 Base Class			Super Class

 Derived Class			Sub Class

 Member Function			Method, or Instance Method.

 Call a Member Function	Send a message

 Static Member Function	Class Method

 Member Variable			Instance Variable

 Static Member Variable	Class Variable

 Pure Virtual Function		Subclass Responsibility

 --

 Robert Martin       | Design Consulting   | Training courses offered:

 Object Mentor Assoc.| rmartin@oma.com     |   OOA/D, C++, Advanced OO

 14619 N. Somerset Cr| Tel: (708) 918-1004 |   Mgt. Overview of OOT

 Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.

Table of Eiffel vs C++ vs Smalltalk

[Snyder 93, Alan Snyder<alan.snyder@eng.sun.com>, The Essence of Objects: Concepts and Terms, IEEE Software V10n1(Jan 93)pp31-42]

Set of Core Concepts

1. OBJECT_0::=
   Net{

   1. All objects embody an abstraction.
   2. Objects provide services.
   3. Clients issue requests.
   4. Objects are encapsulated.
   5. Requests can identify objects.
   6. New objects can be created.
   7. Operations can be generic.
   8. Objects can be classified in terms of their services.
   9. Objects can have common implementations.
   10. Objects can share partial implementations.

   
   }=::OBJECT_0.

   Formal Model of Core Concepts

2. OBJECT_1::=
   Net{

   1. Objects::Sets.
   2. Abstractions::Sets.
   3. Services::Sets.
   4. Clients::Sets.
   5. Requests::Sets.
   6. Implementations::Sets.
   7. Part_Implementations::Sets.
   8. Operations::Sets.
   9. embody::Objects(any)-(1)Abstractions.
   10. provide::Objects(any)-(1)Services.
   11. issue::Clients(any)-(any)Requests.
   12. identifies::Requests(any)-(1)Objects.
   13. classification::Equivalence_relation(Objects ).
   14. (O1): classification ==> (=)mod provide. (O2): implements::Objects(any)-(any)Implementations.

   15. (O3): PART_WHOLE(objects=>Implementations, isin=>part_of). [ PART_WHOLE in math_21_Order ]
   16. (O4): Part_Implementations part_of Implementations,
   17. share::(@Objects)(any)-(1)Part_implementations.

   18. (O5): New objects can be created.

   19. (O6): Operations can be generic.

   20. (O7): Objects are encapsulated.

   21. Classes::=Objects/classification.
   22. is_a::@(Classes,Classes)=Every object in (1st) is also a (2nd).
   23. has_a::@(Classes,Classes)=Every object of (1st) encapsulates an object of class (2nd).
   24. like_a::@(Classes,Classes)=(1st) shares an abtraction with (2nd).

       }=::OBJECT_1:

       Informal Definitions of Terms

   25. Object::=something that is identifiable and has a visible role in providing a service that a client can request.
   26. Client::=A human or a program that issues requests for services. Implicitly an object can act as a client merely by requesting services from other objects as part of the process whereby it services its own clients. The relation between a client object and its server is that of collaborations.

   27. Encapsulated_0bject::=An object that can only be accessed by clients by issuing requests.

       Beware of confusing encapsulation with information hdiing. Encapsulation is animplementation option. Information hiding is a powerful heuristic for designing maintainable objects: each object encapsulates a design choice.

   28. Embedded_object::=An object created by wrapping an existing structure or process that is not an object within an appropriate interface.

   29. Protected_Object::=An object that restricts the ability of specific clients to request its services.

   30. Object_reference::=a value that reliably identifies a specific object

   31. Request::=a client action to cause a service to be performed and identifies an operation denoting the requested service and includes parameters which may identify object.

   32. Generic_operation::=an operation that has different implementations for different objects, with observably different behavior, but a single uniform request.

   33. Interface::=describes the ways that an object can be used. Describes a set of potential requests that identify the object as a parameter.

   34. Interface_Hierarchy::=a classification of interfaces in terms of conformance. A lattice in which higher interfaces are more general and accept requests that are also accepted by conforming objects.

   35. Type::=An identifiable entity with an associated predicate defined of values. A member of the type satisfies the associated predicate.

   36. Sub_type::=A type whose members are also members of another type that is called a super-type.

   37. Super_type::=A type some of whose members can be also members of another type called a subtype.

   38. Binding::=The process of selecting the code to perform a requested service.

   39. Dynamic_binding::=A binding made at the time the service is requested.

   40. Static_Binding::=A binding is made before the service is requested.

   41. Object_implementation::=An executable description of how to perform the set of services associated with an object plus the data associated with the object.

   42. State_Variable::=Serves as the concrete realization of the data associated with objects.

   43. Method::=A procedure that performs a service.

   44. Implementation_Inheritance::=A mechanism for creating object implementations incrementally in terms of other object implementations.

       Associated Concepts

   45. Active_objects::=objects that can initiate computation without being requested to do so by a client.

   46. Composite_objects::=objects that are formed by combining or linking together other objects so that they can be manipulated as a unit.

   47. Hot_link::=Changes in an object linked into a composite object is reflected in the composite object.

   48. Event_notification::=A client can register interest in an event or condition occurring in an object and be notified when it occurs.

   49. Event_driven_control_structure::=A program structure with a top-level loop that waits for events and dispatches them to appropriate handlers.

   50. Presentation_semantic_split::=Using separate objects to represent meaning in abstract and to display information to the user. There can be many ways to display one meaning.

   51. Relationships::=Information that is associated with multiple objects not with individual objects.

       Classical vs Generalized Model.

   52. Classical_model_of_objects::=A request has a parameter that identifies the object that provides the service.

       Other useful terms

   53. Persistance::=The property of an object through which its existance trancends time (i.e. the object continues to exist after its creator ceases to exist) and/or space (i.e. the object's location moves from the address space in which it was created). [Booch 91, p70]

   . . . . . . . . . ( end of section CORBA) <<Contents | End>>

. . . . . . . . . ( end of section Objects: Concepts and Terms) <<Contents | End>>