detert@lognet2.arpa (CMS David K. Detert) (04/27/89)
Can anyone email me a short (SHORT) description of object oriented programming and how it differs from NORMAL programming. Thanks, Dave CMSgt David K. Detert, USAF ARPANet: detert@lognet2.arpa
new@udel.EDU (Darren New) (04/27/89)
In article <14058@louie.udel.EDU> "CMS David K. Detert" <detert@lognet2.arpa> writes: >Can anyone email me a short (SHORT) description of object oriented >programming and how it differs from NORMAL programming. Thanks, Dave You should probably also post this to comp.lang.smalltalk if you can. That's where the Real Object-Oriented Programmers (tm) hang out :-)
dan-hankins@cup.portal.com (Daniel B Hankins) (04/30/89)
My mail to you bounced, so here's my reply. Perhaps it is of general interest anyway: >Can anyone email me a short (SHORT) description of object oriented >programming and how it differs from NORMAL programming. Thanks, Dave This isn't short, but I begin with an opening summary that should take care of your requirements. For more enlightenment, read further. 'Normal', or procedural, programming's underlying philosophy is that a program describes a sequence of actions to perform on some data. Object-oriented programming's underlying philosophy is that a program models real-world objects and concepts, and that the structure of the program should reflect the structure of the problem domain. Procedural programming has three major defects that OO programming attempts to solve. The first is software reusability - often a programmer can find a procedure that does _almost_ what he wants, but has to rewrite it because it doesn't fit his problem domain. The second is modifiability, or locality of reference - references to the components of data structure are scattered throughout the program. Any change to the data structure or its semantics results in changes all over the program, and often rewrites of many sections. This is especially a problem in large software systems. The third is generality - a procedure to add two things can only add things of one particular type. If one has an Add procedure for integers, one has to name the one for complex numbers something else. It is between difficult and impossible to write generic routines. Object-oriented programming, then, consists of three major concepts: encapsulation, polymorphism, and inheritance. To make the following discussion clearer, remember that the basic unit of declaration in an OO language is the object, rather than procedures or data types/variables. An object consists of a set of methods (roughly equivalent to procedures) together with some data. Encapsulation means that the internal structure of an object's data is _not_ available to other objects in the program. That structure is only available to the methods defined in that object. In order to manipulate the data, other objects send messages to the target object. The target object receives the message and invokes the appropriate method. Another way of looking at it is that the other object invokes a procedure with the object as the primary parameter, possibly with other parameters. Here's an example of a message send, and the corresponding procedure call: k := x add y /* x is sent the message 'add y' and returns a result object which is then given the local name k */ k := add(x, y); /* the add procedure of object x is invoked with additional parameter y. The resulting object is assigned to k */ Note that in an OO language, the internal data structure of x is not available to the caller/mesage sender. X could be a complex number in either polar or rectangular format; the method that invokes 'x add y' doesn't care one bit. The internal structure of the object can be changed at any time, and the only code that will have to change is the procedures declared within that same object. This gives locality of reference and makes modifying/fixing programs much easier. Polymorphism means that a single message may be valid for more than one kind of object. Add can apply to integers, reals, fixed-point numbers, polar complex numbers, strings, and so on. And they can all be named the same. Which code actually gets run depends entirely on the object which is the target of the message. In the example above, the code does not care what kind of object x is; only that it be able to process the add message. This leads to much more generic code that can handle a variety of situations, provided only that the messages it sends make sense to the objects it sends them to. Inheritance means that an object can be like another object with some changes. If object A inherits from B, then A is identical in behavior to B, unless some changes have been declared. Various methods of the parent object can be replaced in the child, additional ones can be added, and methods can be deleted. The same goes for variables declared in an object. Note that while method code is shared between parents and children, each object has its own values for its variables. So if one wants the behavior of X with a few changes, those customizations are likely to be much easier to implement in an OO language than a procedural one; one need only specify the differences. Some languages (such as Smalltalk) go further than this and separate objects into class objects and instance objects. Class objects inherit method and variable definitions from each other, while instance objects inherit the methods and have individual values for the variables. In a radically object-oriented language, variables may simply be pointers to other objects; there is no separation between objects and data. The simplest kinds of data (integers, reals, strings, and so on) are provided as object classes built into the system or language. Smalltalk does this. Integers and strings are objects just like everything else. Hope all of this makes things clear. For more info, look into the Smalltalk books (should be available at various college bookstores). They explain object-oriented programming better than I could hope to. Dan Hankins Cold Nuclear Fusion: Instant energy, just add water.
warb@faatcrl.UUCP (Dan Warburton) (05/01/89)
Object oriented programming includes the concept of identity into your programs. Individule objects have idenity and refer to "self" and send messages (invoke generics) to others. Also objects are arranged in a heirachy (spell-check) so similar attributes may be inherited from ancestors.