bie@solman.mlb.semi.harris.com (Ben Eaton) (05/22/91)
I know I am going to get flamed for asking this but I am going to
ask it any way.
QUESTION - What is "Object Oriented Programming"?
Maybe I just fell off the turnip truck (that mite explain the
bruises). I keep running across this term but I have yet to see an
explanation or a definition of it.
If someone out there could dispel my ignorance (well at least some
of it) I would be very grateful.
Thank you,
The Bruised Turnip (A.K.A. Ben Eaton)grp@Unify.com (Greg Pasquariello) (05/23/91)
In article <1991May22.134354.11444@mlb.semi.harris.com>, bie@solman.mlb.semi.harris.com (Ben Eaton) writes: > > > I know I am going to get flamed for asking this but I am going to > ask it any way. > > QUESTION - What is "Object Oriented Programming"? > > Maybe I just fell off the turnip truck (that mite explain the > bruises). I keep running across this term but I have yet to see an > explanation or a definition of it. > > If someone out there could dispel my ignorance (well at least some > of it) I would be very grateful. > > Thank you, Object oriented anything involves working with objects - pieces of code and state that are normally inextricably tied together. Access to the state of an object is done via the code (called methods). Most OO systems allow you to incrementally develop new object types (called classes) via a subclassing mechanism. Subclassing lets you take an object that allows specific operations and specialize it, benefiting from the code and state of the existing class. OO provides a high level of data abstraction and encapsulation. Because of this, it allows you to view a problem in terms that are closer to your real world exprience, which IMO is the biggest single benefit of the OO paradigm. After all, anything I can do with an OO language, I can do with a procedural language as well. OO Languages take the OO paradigm and make it easy to implement your model in code. > > The Bruised Turnip (A.K.A. Ben Eaton) --- Greg Pasquariello grp@unify.com Unify Corporation Be good and never poison people
xtbjh@levels.sait.edu.au (behoffski) (05/24/91)
In article <1991May22.134354.11444@mlb.semi.harris.com>, bie@solman.mlb.semi.harris.com (Ben Eaton) writes: > > I know I am going to get flamed for asking this but I am going to > ask it any way. > > QUESTION - What is "Object Oriented Programming"? > A fine question: you will not get flamed. I suspect that my answer here, which leans heavily on philosophy, may get flamed. Object Oriented is a buzzword, in the same league as "fourth-generation language" and "structured programming". If a product is decribed using such a buzzword, it usually means the following: - nearly everybody agrees that X is a problem at the moment - Y is a buzzword coined by someone to describe their solution to X - much noise is made saying that Y is a Good Thing - everybody adopts the term Y to bolster their image This viewpoint is more than a little cynical, of course, yet I claim that it can be applied to "structured programming" and "4th-generation language" and will eventually be seen to apply to "object oriented." I would argue that the evolution of software has followed something close to the following: - start off with lines of code and individual variables - invent structured programming to control masses of lines of code - invent data structuring to control masses of bytes of data - bolt object oriented constructions on top of data structure and code structure to try and give improved interfaces Your comments are welcome (I'm reasonably flameproof!) -- Brenton Hoff (behoffski) | Senior Software Engineer | My opinions are mine xtbjh@Levels.UniSA.edu.au | AWA Transponder | (and they're weird).
mikeh@touch.touch.com (Mike Haas) (05/25/91)
>bie@solman.mlb.semi.harris.com (Ben Eaton) writes: >> >> >> I know I am going to get flamed for asking this but I am going to >> ask it any way. >> >> QUESTION - What is "Object Oriented Programming"? >> >> Maybe I just fell off the turnip truck (that mite explain the >> bruises). I keep running across this term but I have yet to see an >> explanation or a definition of it. >> >> If someone out there could dispel my ignorance (well at least some >> of it) I would be very grateful. >> >> Thank you, I can give you some example statements of object-oriented code to see how coding style changes with OOP. This works with ODE (Object Development Environment), an extension to JForth on the Amiga, and comes with the jforth package. I think there's also a version of ODE that will run on Mach2 on the mac, but don't quote me. OOP allows you to define data objects like forth, but when tyou do so in OOP, you automatically inherit some set of functions that 'know' about that object. Consider an ARRAY defined by forth (FARRAY) and an ARRAY data element created with ODE (OARRAY). Both would create something in the dictionary. with the CREATE DOES> word of the forth type, one function, the DOES> component is defined to 'know' something special about the data area. (the DOES> part of ARRAY calculates the address of the element based on a CELL's width, for example). In ODE, an ARRAY definition inherits many functions that know about it's data's structure. This is because the ARRAY data type is not created as a naked new data element, it is a 'child' of a parent data type. For example, the ODE ARRAY class may be a child of the CELL class (CELL might create single-element structures, it follows next to create a class that would 'borrow' from this in creating MULTI-element data storage of the same cellular size). In forth, the RUN-time action of FARRAY is only to return the address of a particular element as in 12 FARRAY ( -- address ) In ODE, this could be done with a statement like 12 ADDRESS-OF: OARRAY which would also return ( -- address ). The power comes into play because you can also have a PRINT: function (they're called METHODS in ODE) that is smart enough to display the whole data area in nice formatted dump fashion. PRINT: OARRAY would produce 0 = 0 1 = 0 2 = 1c0 3 = ffff ok while PRINT: on a CELL child would print only it's value (not even an index). You can have many, many functions for each class, and even though they have the same name (PRINT: OARRAY and PRINT: whatever) they never get mixed up. the right thing happens. Think about this...how bout an array of pointers to ODE OBJECTS. Assuming we are storing them in our standard FARRAY, and it was 4 cells long... 4 0 DO i FARRAY (a) ( fetch - my reader won't accept the right character ) ( -- addr-of-ODE-object ) PRINT: [] LOOP ( the [] operator causes PRINT: to work on ) ( whatever is on the stack ) The result could be four different kinds of printouts, based on whatever type of ODE object was stored in the ARRAY. This only scratches the surface of OOP, I hope it at least makes enough sense that your interest is increased, and not the other way around.