Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!zweig From: zweig@brutus.cs.uiuc.edu (Johnny Zweig) Newsgroups: comp.object Subject: Re: What is OOP? (not asking for intro. stuff) Message-ID: <1990Feb12.204645.12441@brutus.cs.uiuc.edu> Date: 12 Feb 90 20:46:45 GMT References: <+B8|X-@rpi.edu> Sender: news@brutus.cs.uiuc.edu Reply-To: zweig@cs.uiuc.edu Organization: U of Illinois, CS Dept., Systems Research Group Lines: 26 I think it is important to distinguish Object-Oriented Programming in the definitive sense from what O-O programmers do when they get to work every day. OOP means organizing software in a natural way that consists of objects performing operations on one-another (as opposed to functions that operate on more loosely-structured data). This means that classes exist -- but does not mean (IMHO) that you need class-hierarchies or types. Consider a delegation-based language: everyone who delegates to object Foo can be considered to be a member of a class (to wit: the class of all objects that are similar enough that I make them all delegate to Foo). I think you need some notion of class to even be able to talk about an object-oriented program -- if I have a bunch of objects, I need to be able to describe (at least to another human; the code need not embody this knowledge) what _kind_ of object each one is, and what it's _for_. I think class-hierarchies, inheritance and typing (ignore that last one all you SmallTalkers) come pretty naturally once you commit yourself to making a program that consists of objects. It comes under the "what you do when you get to work" part of it -- nobody would use an O-O language without some way of reusing behavior (inheritance/delegation) if they were doing OOP and had any way of getting away with using one that does (note the subtle Ada-bashing in there). The stuff people argue about ("tastes classy!" vs. "less typing!") is really not part of "what OOP is" rather, it is part of "how I like to do OOP". -Johnny Distinction