What is object oriented programming?
Robert Mark Bram
Below is a response I gave to a first year Java programming student of mine
who asked the question "what is object oriented programming?" This student
has done some programming in Java and Unix shell scripting. I post my answer
to the group because I welcome feedback. :)
Rob
:)
What is object oriented programming?
Every programming language ever used has one thing in common: variables.
That's what programs do: manipulate variables to do what we want. The next
question is "what types of data can variables hold"? Well, the obvious ones
are:
- numbers: big numbers, small numbers, whole numbers and decimal numbers;
- boolean values: true or false;
- characters: single characters and collections of characters (strings)..
There are quite a few others of course:
- dates;
- binary data (graphics)
- arrays of values..
Structured programming is all about building programs that can manipulate
data items such as these. You have the process (code) and you have the data
(variables) as separate things.
Object oriented ideas came about as we began to understand more about the
potential advantages of storing data *with* process. It is easier to think
of a Product object with methods and its own data (given when the object is
made) as it is to think about a set of Product functions that always have to
be given an array of product data before they can do anything...
Basically, Object Oriented Programming is about expanding the concept of
"data types" to allow types of data that include behaviour..
Phlip
> Howdy all!
>
> Below is a response I gave to a first year Java programming student of
> mine who asked the question "what is object oriented programming?" This
> student has done some programming in Java and Unix shell scripting. I post
> my answer to the group because I welcome feedback. :)
>
> Rob
> :)
>
> What is object oriented programming?
Polymorphism? Inheritance? Encapsulation?
The student dwelled on the preliminaries too long to pad out the essay.
--
Phlip
http://www.greencheese.org/PhilosophyBrethrenThree
-- Have a :-) day --
Topmind
It is taboo to ask what OO is in this group, because
it starts a big fat juicy battle that never
seems to end :-)
While the "type" centric definition has been offered,
it tends to break down under techniques used in
more dynamic OO languages, like Smalltalk and Python.
Under these languages, "type" seems to be a fuzzier
or harder-to-trace concept.
-T-
Thaddeus L Olczyk
<relax...@removethis.optushome.com.au> wrote:
>Every programming language ever used has one thing in common: variables.
Bullshit.
Warren Zeigler
news:3e3c95a9$0$7812
> Structured programming is all about building programs that can manipulate
> data items such as these. You have the process (code) and you have the
data
> (variables) as separate things.
>
> Object oriented ideas came about as we began to understand more about the
> potential advantages of storing data *with* process. It is easier to think
> of a Product object with methods and its own data (given when the object
is
> made) as it is to think about a set of Product functions that always have
to
> be given an array of product data before they can do anything...
>
> Basically, Object Oriented Programming is about expanding the concept of
This is a good start, but not enough.
First, if you start the way you did, you could explain that the user is
creating their own "types", combining data with code. (The code for native
types is called when you use operators, which are just a shortcut for
calling the equivalent of polymorphic methods.)
This is programming w/ objects, or object-based programming.
The term "object-oriented" has a special meaning: The tools and/or target
environment must, on top of object-based programming, support encapsulation,
inheritance, and polymorphism.
A couple other basic statements:
* In object-oriented programming, major functionality is realized through
the collaborations of objects.
* With procedural, you simply "do." - Think of describing how to get
somewhere w/ a strip map. W/ objects, you create a structure (think of a
street map) then USE the structure (directions on the map) to accomplish
your goals.
Past this, you will get many different answers for several reasons,
including:
* The methodology used greatly influences people's perspectives
* Many people learn the basics only in code and never see the big picture
* A lot of people have emphasized only one thing, and come across like a
defensive child, unable to evaluate or even discuss rationally. (You have
seen a few of those already.)
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Kenny Chaffin
relax...@removethis.optushome.com.au says...
Certainly that is the core of it. The rest (and the argument to ensue)
follows by corollary and various "helpful" implementation details.
KAC
--
Kenny A. Chaffin
http://www.kacweb.com
Custom Programming and Design
Kemal Enver
polymorphism, encapsulation and the concept of class etc. It can be quite
easy to program in an imperative language fashion even in an oo language
without taking into consideration those other points.
Kemal Enver
u0...@dcs.shef.ac.uk
Skinnybrown
news:d0jp3vg0olre8gour...@4ax.com...
Care to elaborate on that? Maybe by backing it up with an example?
Skinnybrown (www.skinnybrown.net)
--
What I lack in skill, I make up for in inability
Joona I Palaste
on comp.lang.java.programmer:
> "Thaddeus L Olczyk" <olc...@interaccess.com> wrote in message
> news:d0jp3vg0olre8gour...@4ax.com...
>> On Sun, 2 Feb 2003 14:51:15 +1100, "Robert Mark Bram"
>> <relax...@removethis.optushome.com.au> wrote:
>> >Every programming language ever used has one thing in common: variables.
>> Bullshit.
> Care to elaborate on that? Maybe by backing it up with an example?
Functional programming languages lack common-or-garden variables. In
particular, they lack variables that are tied to a particular state.
In functional programming languages, a variable in a function can be
evaluated pretty much any time the language pleases, and it will still
have the correct value.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"C++ looks like line noise."
- Fred L. Baube III
Kaz Kylheku
> Howdy all!
>
> Below is a response I gave to a first year Java programming student of mine
> who asked the question "what is object oriented programming?" This student
> has done some programming in Java and Unix shell scripting. I post my answer
> to the group because I welcome feedback. :)
Your answer is skewed toward programming languages whose object
systems descent from Simula-67.
In reality, there are three principles at the heart of object-oriented
programming.
The first is this: the insertion of a simple pattern matching layer
between a function call and its destination. That pattern matching
layer selects a destination for the call based on unifying the
attributes (mostly the type) of the arguments against the attributes
of the collection of candidate methods. This pattern matching layer
gives rise to generic programming, which allows unlike objects to be
substitutable for each other in the same syntax, and special-case
behaviors to be coded to make it all work.
This pattern-matching dispatch is supported by another feature of
object oriented programming: defining new types that are called
classes, and building them up using inheritance. Inheritance builds an
extension of a type which is substitutable for that type. This allows
existing methods to apply, while allowing the programmer to
selectively code ones which provide a more specific pattern match for
the extended type. In decent OO programming systems, type
substitutability is not restricted to inheritance. A method parameter
can be specialized to types which are not related by inheritance, like
string or integer.
Lastly, these class objects can be subject to destructive
manipulation: they hold state which is stored in slots (a.k.a data
members, member variables, instance variables). This allows objects to
have state-dependent behaviors, though object-oriented programming
over immutable objects is also possible.
Incidentally, pattern-matching dispatch is really a kind of special
case of logic reasoning. Calling an operation is a query, and the
method calls that result are the actions fired in response to rules.
The difference is that the unification rules are simple, often only
one method is found, and the order of firing of multiple methods is
usually predictable. No complex second order logical inference is
needed. Nevertheless, OO is a step toward greater intelligence in the
programming language.
> Object oriented ideas came about as we began to understand more about the
> potential advantages of storing data *with* process.
I think that this was quite understood since Von Neumann's idea of
storing code and data together.
However, object oriented programming languages don't actually *store*
data with process. What is in fact true is that the lesser programming
languages, which support dispatch only on one argument, give rise to
the illusion that code is stored with data. This illusion is the
consequence of name resolution rules (scoping) and of using the same
operator to refer to a ``member'' function as to refer to a member
variable, even though the function is not physically a member of the
object. The association has drawbacks; namely it's difficult to
reconcile with the pattern matching model which chooses a method based
on the dynamic types of all arguments, rather than just the leftmost
one (the object which is said to be ``receiving'' the ``call'' or
``message''). This is a good model for network services, which in fact
have to be modeled as entities that receive messages due to the way
the network operates.
Making methods attributes of classes is simply a workaround to having
an inadequate package system. The class is made to serve as a symbol
table for name lookup.
> It is easier to think
> of a Product object with methods and its own data (given when the object is
> made) as it is to think about a set of Product functions that always have to
> be given an array of product data before they can do anything...
As a rule, it's easiest to think in terms of whatever framework of
thought you have been following for the last five years.
Bundling methods with objects is simply just abuse of the class system
to provide packaging. If you can make a Product package, and put
functions into that package, you get the same benefit of association,
without constraining the object system to treat the leftmost parameter
of a function call as different from the rest.
> Basically, Object Oriented Programming is about expanding the concept of
> "data types" to allow types of data that include behaviour..
Not really; in the expression 2 + 2 which produces 4, this production
4 is a behavior of the integer data type. Yet you could do this in
Fortran.
Isaac Kuo
Joona I Palaste <pal...@cc.helsinki.fi> wrote in message
news:b1ja35$j3j$2...@oravannahka.helsinki.fi...
> Functional programming languages lack common-or-garden variables. In
> particular, they lack variables that are tied to a particular state.
> In functional programming languages, a variable in a function can be
> evaluated pretty much any time the language pleases, and it will still
> have the correct value.
I'm not sure what the terminology usually is. Certainly, calling
the "variables" in a purely functional language "variables" is
misleading because they don't ever "vary". They're more like
function parameters.
Anyway, there can also be procedural languages which lack
variables or even anything which resembles a variable. Simple
macro systems are essentially very basic scripting languages.
In a sense, this is the complete opposite of a functional language.
Whereas in a purely functional language nothing changes and
sequence is unimportant, the whole point of a macro is to do
some changes in an exactly specified sequence.
I think the only things programming languages all have in common
are that they broadly tell a computer what to do ("programming")
and that they do so in a form which humans can understand
("language").
Of course, the latter feature is almost content-free, considering
humans in the good old days had do program their Altairs in
straight binary machine code...humans can understand just about
anything given enough time and effort.
OTOH, perhaps it is a useful distinction in that it distinguishes
human generated code from something a genetic algorithm
cooked up.
Isaac Kuo
H. S. Lahman
> Basically, Object Oriented Programming is about expanding the concept of
> "data types" to allow types of data that include behaviour..
Sorry, but I don't care for this definition at all. It is just as
biased towards data as the behavioral definitions are biased towards
functionality. It also fails to distinguish between OOA/D and OOP.
The core characteristic of OO development is abstracting problem space
entities in terms of cohesive, intrinsic knowledge and behavior
responsibilities. (A typical application has multiple problem spaces,
including various computing spaces.) Another core characteristic is the
notion of encapsulation where the implementation of those
responsibilities is hidden behind an interface. Thus the interaction
between abstractions is defined in terms of responsibilities and interface.
These core characteristics enable a third: peer-to-peer communications.
In an OO application all objects are peers that capture unique,
intrinsic properties of the underlying entities. The 'object' is
logically indivisible at a given level of abstraction. So one defines
the solution as a sequence of direct collaborations among the peer objects.
There are a number of secondary characteristics that are also enabled by
abstraction and encapsulation. They are secondary because one can have
an OO application that doesn't use them individually. However, every OO
application will use most of them. These include: several forms of
polymorphism; inheritance of data, interfaces, and/or implementations;
strong typing; and dynamic binding.
In addition, methodologically OO development emphasizes decoupling
implementations as the primary tool of maintainability. In fact, one
could argue that the main reason OO development exists is to provide
better maintainability when requirements are volatile.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH
Avner Ben
"Robert Mark Bram" <relax...@removethis.optushome.com.au> wrote in message
news:3e3c95a9$0$7812$afc3...@news.optusnet.com.au...
> Howdy all!
>
> potential advantages of storing data *with* process. It is easier to think
> of a Product object with methods and its own data (given when the object
is
> made) as it is to think about a set of Product functions that always have
to
> be given an array of product data before they can do anything...
>
> Basically, Object Oriented Programming is about expanding the concept of
> "data types" to allow types of data that include behaviour..
>
>
I am not happy with the data-centric approach. This is more a definition of
"data-abstraction" than of OOP. The next step would be to explain that
functions are there to allow safe access to data. We end up with a data
structure that constructor, destructor and get/set methods. This is also the
reason why inheritance, polymorphism and genericity are not mentioned at
this stage.
I am in favour of OO definitions that stress the encapsulation of
functionality. Data is there because the functionality may use it
internally, usually, for three reasons:
1. State (of the receiver object, maintained between method invocations).
2. Cached properties (obtained once from the outside world, e.g., GUI,
database, device).
3. Associations - member data that point to other objects by the object
owned or needed by the methods to function properly.
When one understands that the data are there because the functionality need
them, one may proceed to understand the need to override the functionality
and to use functionality regardless of type and hence - object oriented
programming.
Avner.
Alfredo Novoa
> Howdy all!
>
> Every programming language ever used has one thing in common: variables.
Functional languages does not have variables.
> Structured programming is all about building programs that can manipulate
> data items such as these. You have the process (code) and you have the data
> (variables) as separate things.
You have variables and types as separate things. Procedures
(operators) are part of types, like +,-,*,/, etc are part of the type
integer.
> Object oriented ideas came about as we began to understand more about the
> potential advantages of storing data *with* process. It is easier to think
> of a Product object with methods and its own data (given when the object is
> made) as it is to think about a set of Product functions that always have to
> be given an array of product data before they can do anything...
>
> Basically, Object Oriented Programming is about expanding the concept of
> "data types" to allow types of data that include behaviour..
Structured programming types also have behavior.
For instance:
var a,b: Integer;
begin
...
a := a + b;
A type without a behavior is completely useless. By the way 'behavior'
is a rather sloppy term.
Basically, Object Oriented Programming is about expanding the concept
of type to allow code reusing through type inheritance.
By the way there is not a consensus about what in the hell type
inheritance is.
Regards,
Alfredo
Alfredo Novoa
> First, if you start the way you did, you could explain that the user is
> creating their own "types", combining data with code.
It is not specific to OO. With structured programming users can create
their own types with their operators.
Type
Point = record
X,Y: Integer;
end;
function Distance(P1, P2: Point): Length;
begin
...
function Distance(P: Point; L: Line): Length;
begin
...// this operator belongs to Point and Line types
> (The code for native
> types is called when you use operators, which are just a shortcut for
> calling the equivalent of polymorphic methods.)
Do you mean operators are a shortcut?
Operator is only a more formal term for a method.
> The term "object-oriented" has a special meaning: The tools and/or target
> environment must, on top of object-based programming, support encapsulation,
> inheritance, and polymorphism.
But encapsulation and some polymorphism existed in structured
programming.
> A couple other basic statements:
> * In object-oriented programming, major functionality is realized through
> the collaborations of objects.
Like in structured programing through the collaboration of variables.
> * With procedural, you simply "do."
Most OO languages are 100% procedural.
> - Think of describing how to get
> somewhere w/ a strip map. W/ objects, you create a structure (think of a
> street map) then USE the structure (directions on the map) to accomplish
> your goals.
You can do the same with structured programming.
Regards,
Alfredo
Richard Riehle
> First, if you start the way you did, you could explain that the user is
> creating their own "types", combining data with code. (The code for native
> types is called when you use operators, which are just a shortcut for
> calling the equivalent of polymorphic methods.)
Nice explication, Warren.
Based on a post in another thread, by Lahman, and also by the details
of your contribution, I am reminded that we need to consider object
oriented programming as a subset of object technology. For example,
it is frequently useful to employ the object metaphor in our software,
but inheritance and/o polymorphism may sometimes be inappropriate.
Your emphasis on collaboration hits the mark quite squarely. Syzperski
places emphasis on binary (run-time) objects (e.g. DLL's), and software
architects note the role of pipe and filter objects.
As we refine our understanding of object technology, in all of its forms,
we can certainly embrace the importance of a variable as a kind of
object. A variable is always associated, implicity or explicitly, with
some type. That type is bound to a set of methods. It is not too
troubling to allow that a variable of a type is also an object of that type,
and an object of the type is also a variable of the type. Of course, I
understand that sometimes we will have constants, but those are still
bound to a set of methods. Whether we use the term variable or the
term object, we are still looking at an instance of a type. Class is
simply another word for type, in most cases. When we think at the
class level, we may add new properties such as specialization. One
form of specialization is inheritance. We may add some properties
for dynamic selection of methods such as polymorphism.
Stroustrup has indicated that a well-formed class will appear to the
user as if it is a built-in type. My criticism of C++ is well-known,
but my admiration for the skill and reasoning of Dr. Stroustrup is
not diminished by my dislike of C++. Had he been able to start
his work at some other place than C, his finished product would
have been far better than anything developed by anyone else. OK,
I understand that Objective C fans will take issue with that. So be it.
Unfortunately, other new languages, such as Java, have simply
become disconfigured versions of C++, carrying forward the
pathologies of the original language design, many of which go all
the way back to C. The comment from Lahman about depending
too much on language design, also stated by R. Martin many
times over, continues to ring out as important.
Too often someone thinks that learning Smalltalk, Java, or
Eiffel, is enough for them to understand object technology.
There is currently no language design that perfectly embodies
all the best ideas of object technology. It is likely there never
will be. Advocates of particular languages need to understand
that so we can raise the level of the conversation in pursuit
of tools and languages that do well-represent the current
state of reasoning about this topic.
Perhaps we need a better taxonomy of object technology. By this I mean
a taxonomy somewhat more fine-grained than that proposed by
Wegner, et al. Wegner's contribution was OK for its time, but the
new approaches, new ideas, and new language models have forced
us to reconsider the ideas of the 1980's.
Returning to your emphasis on collaboration between objects, I would
suggest we find another term, one that includes the specialization
relationship, the polymorphic relationship, the principle of delegation,
and the many other new ideas that are adding themselves to our notion
of object technology. Perhaps even the term object is becoming a bit
tired. Brad Cox once suggested the idea, "software IC," and I still
use that idea when first introducing software objects. Someone
else suggested, "virtual machines." Whatever we end up calling this
approach to developing software, it is clear that simply focusing on
object-oriented programming with its emphasis on inheritance and
polymorphism, is a bit too narrow a focus to include all the possible
collaborations and relationships possible between software objects.
Richard Riehle
Richard Riehle
> Structured programming types also have behavior.
>
> For instance:
>
> var a,b: Integer;
> begin
> ...
> a := a + b;
>
> A type without a behavior is completely useless. By the way 'behavior'
> is a rather sloppy term.
Actually, it is not so sloppy as it is abstract. In software, we often speak
of "levels of abstraction." It is perfectly appropriate to select the level of
abstraction that best conveys the idea on which you choose to focus. To
choose behavior as the focus brings the responsibility to craft one's
comments accordingly.
The arithmetic, plus (+), does convey some sense of behavior. Every
primitive type has associated behavior. Languages vary on how they
represent behavior. In assignment, for example we have variations
such as,
Copy (A, B);
Move B to A. /* a misuse of the word move */
A = B;
A := B;
A <- B
The behavior of assignment is important to understand. If A and B are
of the same type, we might have a straightforward behavior. If they
are the same type but different sizes (as in arrays or strings), we might get
truncation, filling, or some other set of behaviors. If they are complex
data structures, we might get deep copy or shallow copy, depending on
the language design. Dijkstra makes a comment, somewhere in his
"Discipline of Computer Programming" about the importance of understanding
the behavior of the assignment operator.
Now, taking your example, how does one alter the behavior of the plus
operator in structured programming? This is probably not a fair question
since we typically don't do that in object-oriented programming either.
However, when one decides to design a more complex structure, this
does become a fair question. And the question brings us back to the
idea of levels of abstraction. I am not an advocate of using inheritance
for every kind of design. Even for specialization, inheritance (at least
in the language I use most often), is not the only technique for extensibility
and abstraction specialization. Yet, when inheritance is appropriate,
there are few options that present a more economical and more efficient
approach.
> Basically, Object Oriented Programming is about expanding the concept
> of type to allow code reusing through type inheritance.
That is elementary view of OOP. However, it is not a bad place to begin
your efforts to reason about it. A little more study and a few more programs
will broaden your understanding a bit.
> By the way there is not a consensus about what in the hell type
> inheritance is.
There is a prettty good dominant view of what inheritance is. However,
it is concept that sophisticated practitioners have been able to analyze
and refine to suit their particular needs. Just as there are levels of
abstraction, there are also levels of inheritance. One needs to be careful,
when looking at any idea, that each facet of that idea is examined before
drawing final conclusions about it. Remember the story of the five
blind men and the elephant.
Richard Riehle
Daniel T.
> Below is a response I gave to a first year Java programming student of mine
> who asked the question "what is object oriented programming?" This student
> has done some programming in Java and Unix shell scripting. I post my answer
> to the group because I welcome feedback. :)
>
> What is object oriented programming?
x := y * z;
Q: What specific algorithm should we use to determine the value of y *
z?
A: That depends on the types of 'y' and 'z'. If they are ints, one
algorithm will be used, if floats another, if they represent vectors,
still another.
The algorithm to use must be determined, then. We can force the
programmer to explicitly determine the algorithm, for example:
x := float_mult( y, z );
or we can allow the compiler to determine the algorithm by forcing the
programmer to explicitly state the types of 'y' and 'z', for example:
float y, z;
...
x := y * z; // the float_mult algorithm will be used
or we can allow the runtime system to determine the algorithm by forcing
the program to store type information in the variable, and make the
choice of algorithm when the multiply is actually performed. For example:
y = 2.3; // 'y' knows it is a float
z = 5.3; // 'z' knows it is a float
x := y * z; // the compiler decides to use the float_mult algorithm after
// examining the types of 'y' and 'z'
The essence of OO programming is giving the programmer tools so that he
may create algorithms such that the runtime system can determine what
particular algorithm to use, based on the type(s) of the argument.
Everything else, including allowing "data types" to include behavior,
and hiding implementation, is included in order to support the above...
Vikrama Sanjeeva
>
> Below is a response I gave to a first year Java programming student of mine
> who asked the question "what is object oriented programming?" This student
> has done some programming in Java and Unix shell scripting. I post my answer
> to the group because I welcome feedback. :)
>
> Rob
> :)
>
> What is object oriented programming?
Hi,
Above all, the one major featur/advantage of OO which I like most
and will tell when any layman or a structured progrmmer when ask the
same question from me is that,
The beauty of OO is the way the people thinks in real-world.That
is OO is much as similar as we think in real-world.This is th reason
due to which Bruce Eckle says "I don't know why layman start
programming from structured language, why not from OO language " :-).
Bye,
Viki.
Skinnybrown
news:Aab%9.86463$GX4.3...@news2.east.cox.net...
Perhaps my message was a bit vague. I wasn't so much asking for evidence,
as saying that "Bullshit" isn't really much of an argument, more of an
imature response to a perfectly resonable statement. Somebody with at least
a double figure IQ would probably have said something like "I disagree, an
example would be..." or event "Bullshit, and example would be..." but to
post such a rude and unjustified response is just childish.
--
Warren Zeigler
news:3E3D7646...@adaworks.com...
Thanks for the feedback and kind words.
> Whatever we end up calling this
> approach to developing software, it is clear that simply focusing on
> object-oriented programming with its emphasis on inheritance and
> polymorphism, is a bit too narrow a focus to include all the possible
> collaborations and relationships possible between software objects.
Yes, and I see this narrow focus distorting training. It is a well-known
phenomenon that new OO programmers overuse inheritance and underuse
associations. This comes from excessive emphasis on "the big three."
--
Warren Zeigler
wzei...@UnderstandingObjects.com
"Richard Riehle" <ric...@adaworks.com> wrote in message
news:3E3D7646...@adaworks.com...
Warren Zeigler
--
Warren Zeigler
wzei...@UnderstandingObjects.com
"Alfredo Novoa" <alf...@ncs.es> wrote in message
news:e4330f45.03020...@posting.google.com...
> "Warren Zeigler" <warren...@attbi.com> wrote in message
news:<L65%9.61805$to3....@rwcrnsc51.ops.asp.att.net>...
>
> > First, if you start the way you did, you could explain that the user is
> > creating their own "types", combining data with code.
>
> It is not specific to OO. With structured programming users can create
> their own types with their operators.
No one said that you could not program OO using a procedural language. In
fact, a lot of OO is "good coding practices" from procedural.
The DIFFERENCE is the ease and encapsulation in OO, if you are looking at
languages.
MORE IMPORTANT - The question was "what is OO", not "What is unique to OO."
You stopped partway into it. As I put it in class, objects are like a sauce.
If you cook, you know that you use basic ingredients to create a sauce, then
the sauce itself is a basic ingredient in a new receipe. OO is all about
USING objects, not so much about their construction. Programmers get hung up
on object (sauce, or to use another analogy - brick) construction, when in
reality, that is a preliminary activity to the core of OO - using the sauce
(or the bricks) to make/build the final product.
> > (The code for native
> > types is called when you use operators, which are just a shortcut for
> > calling the equivalent of polymorphic methods.)
>
> Do you mean operators are a shortcut?
>
> Operator is only a more formal term for a method.
We are talking about answering a new student's question. Your comment would
just confuse at that level.
> > The term "object-oriented" has a special meaning: The tools and/or
target
> > environment must, on top of object-based programming, support
encapsulation,
> > inheritance, and polymorphism.
>
> But encapsulation and some polymorphism existed in structured
> programming.
Very true. What is your point?
> > A couple other basic statements:
> > * In object-oriented programming, major functionality is realized
through
> > the collaborations of objects.
>
> Like in structured programing through the collaboration of variables.
Variables do not collaborate, they are used. Collaboration implies action,
thus code.
> > * With procedural, you simply "do."
>
> Most OO languages are 100% procedural.
Now you are going off the deep end.
> > - Think of describing how to get
> > somewhere w/ a strip map. W/ objects, you create a structure (think of a
> > street map) then USE the structure (directions on the map) to accomplish
> > your goals.
>
> You can do the same with structured programming.
Not without "hand rolling" OO in the structured language. Why bother?
S Perryman
news:cf333042.03020...@posting.google.com...
> "Robert Mark Bram" <relax...@removethis.optushome.com.au> wrote in
message news:<3e3c95a9$0$7812$afc3...@news.optusnet.com.au>...
> > Howdy all!
> > Below is a response I gave to a first year Java programming student of
mine
> > who asked the question "what is object oriented programming?" This
student
> > has done some programming in Java and Unix shell scripting. I post my
answer
> > to the group because I welcome feedback. :)
>
> Your answer is skewed toward programming languages whose object
> systems descent from Simula-67.
As it was the first, that is no surprise.
> This pattern-matching dispatch is supported by another feature of
> object oriented programming: defining new types that are called
> classes, and building them up using inheritance. Inheritance builds an
> extension of a type which is substitutable for that type.
Not quite.
Inheritance builds a type that *acquires the properties of the type that
it inherits from* . This process does not require or enforce the
inheriting type to be an extension.
As for "substitutable" , goto Google for N yrs of debate on comp.object
on this topic (I suggest not doing so willingly) ... :-)
Regards,
Steven Perryman
Larry Clapp
In article <e4330f45.03020...@posting.google.com>, Alfredo
Novoa wrote:
> "Warren Zeigler" <warren...@attbi.com> wrote in message
> news:<L65%9.61805$to3....@rwcrnsc51.ops.asp.att.net>...
>
>> First, if you start the way you did, you could explain that the
>> user is creating their own "types", combining data with code.
>
> It is not specific to OO. With structured programming users can
> create their own types with their operators.
>
> Type
> Point = record
> X,Y: Integer;
> end;
>
> function Distance(P1, P2: Point): Length;
> begin
> ...
>
> function Distance(P: Point; L: Line): Length;
> begin
> ...// this operator belongs to Point and Line types
[snip more on structured programming]
This reminded me of a discussion I read about a language that
/supports/ object-oriented programming, versus a language that
/enables/ object-oriented programming:
If the term "object-oriented programming language" means anything,
it must mean a programming language that provides mechanisms that
support the object -oriented style of programming well
There is an important distinction here. A language is said to
/support/ a style of programming if it provides facilities that
makes it convenient (reasonably easy, safe, and efficient) to use
that style. A language does not support a technique if it takes
exceptional effort or skill to write such programs; it merely
/enables/ the technique to be used. For example, you can write
structured programs in Fortran and object-oriented programs in C,
but it is unnecessarily hard to do so because these languages do
not directly support those techniques. [all emphases his]
-- The C++ Programming Language, 2nd ed, Bjarne Stroustrup,
1994, section 1.2
I think Pascal, C, etc. /enable/ OOP, but hardly /support/ it.
(On the other hand, perhaps I misunderstood the point you wanted to
make.)
-- Larry
--
Larry Clapp / la...@theclapp.org
Use Lisp from Vim: VILisp: http://vim.sourceforge.net/script.php?script_id=221
soft-eng
This used to be called "Abstract Data Typing".
OOP came at about the same time as ADT, and they
have a lot of overlap, but the philosophical
motivations of OO were exactly what
its name says: "objects". A word that conveys
it better is "things", since "objects" has become
a slightly more obfuscatory word. There was a project
even named "Thinglab", I think by someone
called Zorning.
The one thing that OOP gets naturally but
ADT didn't originally, is polymorphism.
OTOH, exceptions and generics were originally
from ADT iirc.
S Perryman
news:9fa75d42.03020...@posting.google.com...
> "Robert Mark Bram" <relax...@removethis.optushome.com.au> wrote in
message news:<3e3c95a9$0$7812$afc3...@news.optusnet.com.au>...
> > Basically, Object Oriented Programming is about expanding the concept of
> > "data types" to allow types of data that include behaviour..
> This used to be called "Abstract Data Typing".
> OOP came at about the same time as ADT, and they
> have a lot of overlap, but the philosophical
> motivations of OO were exactly what
> its name says: "objects". A word that conveys
> it better is "things", since "objects" has become
> a slightly more obfuscatory word. There was a project
> even named "Thinglab", I think by someone
> called Zorning.
> The one thing that OOP gets naturally but
> ADT didn't originally, is polymorphism.
One thing is for certain is that the ADT bods although having
an interface/impl separation, were not thinking of having
several components in the same program unit, each of which
provide their own specific impls of said interface.
In fact, this is still a problem today with pure ADTs.
OO was fortunate to escape some of the problem specifically
because of inheritance (which allows impl sharing, which of
course loosens the ADT information concept) , but not without
costs.
> OTOH, exceptions and generics were originally
> from ADT iirc.
CLU, which AFAIK was the first prog lang supporting the ADT
concept specifically, had exceptions and generics. And that was in
the early 70s. PL/1 AFAIK had exceptions too.
Regards,
Steven Perryman
Alfredo Novoa
> Comments inline...
> No one said that you could not program OO using a procedural language. In
> fact, a lot of OO is "good coding practices" from procedural.
In other words OO is an extension (evolution) of structured
programming.
> MORE IMPORTANT - The question was "what is OO", not "What is unique to OO."
> You stopped partway into it.
I think programmers should learn about the evolution of programming
languages and programming techniques. If you want to understand OO,
then it is very recomendable to understand what structured programming
is, and what 2GL, 1GL and 4GL are.
Then it is important to know: "What is new in OO", and what in OO are
only mixed and renamed classic terms.
And it is also very recomendable learning about the limitations of OO
and about the flaws in most popular OO languages.
> As I put it in class, objects are like a sauce.
> If you cook, you know that you use basic ingredients to create a sauce, then
> the sauce itself is a basic ingredient in a new receipe. OO is all about
> USING objects
Objects are simply variables or values.
But sometimes you can find people using the word "object" with any
arbitrary meaning, and changing this meaning constantly across the
writting.
Then objects can be: classes, things, entities, values, variables,
relations, all of above, etc.
> > > (The code for native
> > > types is called when you use operators, which are just a shortcut for
> > > calling the equivalent of polymorphic methods.)
> >
> > Do you mean operators are a shortcut?
> >
> > Operator is only a more formal term for a method.
>
> We are talking about answering a new student's question. Your comment would
> just confuse at that level.
Are the students 8 years old?
I think we can require a minimal mathematical background.
What is confusing is the usual sloppy OO terminology.
Fundamental terminology should be the start of any basic programming
course.
Concepts like: type, variable, value, operator, operand, function,
invariant, precondition, postcondition, model, implementation,
literal, scalar type, collection type, etc, etc.
> > A couple other basic statements:
> > > * In object-oriented programming, major functionality is realized
> through
> > > the collaborations of objects.
> >
> > Like in structured programing through the collaboration of variables.
>
> Variables do not collaborate, they are used. Collaboration implies action,
> thus code.
Variables are objects.
Collaboration, and action are also a fuzzy terms.
> > > * With procedural, you simply "do."
> >
> > Most OO languages are 100% procedural.
>
> Now you are going off the deep end.
Are not Java, and C++ procedural?
> > > - Think of describing how to get
> > > somewhere w/ a strip map. W/ objects, you create a structure (think of a
> > > street map) then USE the structure (directions on the map) to accomplish
> > > your goals.
> >
> > You can do the same with structured programming.
>
> Not without "hand rolling" OO in the structured language. Why bother?
Then progammers were hand rolling OO in the structured languages
during a lot of years.
Regards,
Alfredo
S Perryman
news:e4330f45.03020...@posting.google.com...
> "Warren Zeigler" <warren...@attbi.com> wrote in message
news:<Z9o%9.140035$Ve4.8946@sccrnsc03>...
> > No one said that you could not program OO using a procedural language.
In
> > fact, a lot of OO is "good coding practices" from procedural.
> In other words OO is an extension (evolution) of structured
> programming.
No (or not quite) .
The creators of Simula used the impl of a block-structured prog lang (Algol)
as the basis of the impl for a prog lang (Simula) that was intended to be
used for systems simulation. This prog lang was devised to deal with sets of
*entities* with behavioural properties.
They didn't start with Algol and over time evolve into Simula.
The choice of Algol (for various reasons) was a conscious one from the
start.
http://java.sun.com/people/jag/SimulaHistory.html
Regards,
Steven Perryman
Alfredo Novoa
> Alfredo Novoa wrote:
> Actually, it is not so sloppy as it is abstract. In software, we often speak
> of "levels of abstraction." It is perfectly appropriate to select the level >of
Where is the formal definition of "behavior" in a programming language
context?
We have the more precisse operator term. Why not use it?
Fuzzyness is not the same as abstraction.
IMO bad terminology is the most frequent cause of logical errors.
> The arithmetic, plus (+), does convey some sense of behavior.
IMO this is a lot more clear:
An arithmetic addition operator is an operator.
> Every primitive type has associated behavior.
In more precisse words:
Each type has a set of associated operators.
> If they
> are the same type but different sizes (as in arrays or strings), we might get
> truncation, filling, or some other set of behaviors.
Then they don't have the same type and what you call some other set of
behaviors is more precissely called coercion.
> If they are complex
> data structures, we might get deep copy or shallow copy, depending on
> the language design. Dijkstra makes a comment, somewhere in his
> "Discipline of Computer Programming" about the importance of understanding
> the behavior of the assignment operator.
>
> Now, taking your example, how does one alter the behavior of the plus
> operator in structured programming?
I think you mean how to create new addition operators.
In ADA 83 we can do something like this:
function "+" (LEFT, RIGHT : MATRIX) return MATRIX;
function "+" (LEFT, RIGHT : VECTOR) return VECTOR;
http://archive.adaic.com/standards/83lrm/html/lrm-06-07.html
You can't do this with most OO languages, but nothing impede doing
that in a future language.
> This is probably not a fair question
> since we typically don't do that in object-oriented programming either.
Current OO languages are not very good.
> > Basically, Object Oriented Programming is about expanding the concept
> > of type to allow code reusing through type inheritance.
>
> That is elementary view of OOP. However, it is not a bad place to begin
> your efforts to reason about it. A little more study and a few more programs
> will broaden your understanding a bit.
I am tired of using OO languages. I find all of them rather
unsatisfactory.
For instance:
Limiting the association of operators to a single type is arbitrary,
unnatural and unrealistic.
The pointer based inheritance model is flawed and most languages does
not support multiple inheritance.
The distinction between primitive types and classes is also arbitrary
and unnatural.
They don't have a relation type generator nor relational operators.
With relation variables referenced objects are not longer needed.
Etc, etc.
But it is perfectly possible to create a new OO language without that
flaws.
There is no progress without some nonconformism.
OO fans resemble a lot the old assembler, spaghetthi and structured
fans.
Regards
Alfredo
Jesper Nordenberg
> I think you mean how to create new addition operators.
>
> In ADA 83 we can do something like this:
>
> function "+" (LEFT, RIGHT : MATRIX) return MATRIX;
> function "+" (LEFT, RIGHT : VECTOR) return VECTOR;
>
> http://archive.adaic.com/standards/83lrm/html/lrm-06-07.html
>
> You can't do this with most OO languages, but nothing impede doing
> that in a future language.
You can certainly do it in C++. I don't see what the big deal is with
operators, they are just another way of writing a method.
> The pointer based inheritance model is flawed
What is a "pointer based inheritance model"? For example, does Java have
a "pointer based inheritance model"?
> and most languages does
> not support multiple inheritance.
So? A properly designed OO program seldom needs multiple inheritance. I
never need it, I use interfaces and composition instead.
> The distinction between primitive types and classes is also arbitrary
> and unnatural.
Not all OO languages have a distinction between primitive types and
classes. One example is Smalltalk.
/Jesper Nordenberg
Jesper Nordenberg
> In other words OO is an extension (evolution) of structured
> programming.
Depends on how you see it. Everything is an evolution of something that
existed before.
> I think programmers should learn about the evolution of programming
> languages and programming techniques. If you want to understand OO,
> then it is very recomendable to understand what structured programming
> is, and what 2GL, 1GL and 4GL are.
I dont agree. If you want to compare programming languages, yes, but if
your new to programming I think it's better to start with OO concepts
like interfaces, design patterns, refactoring etc. No need to learn
stuff that you shouldn't use in OO programming.
> Variables are objects.
What do you mean with "variable"? Typically a variable is a handle to a
value. The variable can change it's value, that's why it's called a
variable. An object is a value, not a variable.
>>>>* With procedural, you simply "do."
>>>
>>>Most OO languages are 100% procedural.
>>
>>Now you are going off the deep end.
>
>
> Are not Java, and C++ procedural?
Yes, but an OO language don't necessarily have to be procedural.
/Jesper Nordenberg
Jesper Nordenberg
> The essence of OO programming is giving the programmer tools so that he
> may create algorithms such that the runtime system can determine what
> particular algorithm to use, based on the type(s) of the argument.
What you describe is polymorphism.
> Everything else, including allowing "data types" to include behavior,
> and hiding implementation, is included in order to support the above...
Well, that's an over-simplification. There are other important aspects
in OO like inheritance, encapsulation etc. Read this FAQ for a better
description:
http://www.cyberdyne-object-sys.com/oofaq2/index.htm
/Jesper Nordenberg
Universe
> Alfredo Novoa wrote:
>> In other words OO is an extension (evolution) of structured
>> programming.
> Depends on how you see it. Everything is an evolution of something that
> existed before.
Somethings are a simple "quantitative" "evolution", while others are a
more "qualitative" "revolution", "punctuated equilibrium", or complex
leap.
I see OO as a "revolutionary" leap as opposed to merely prosaic
evolutionary extension of the Structure paradigm.
Elliott
--
http://www.radix.net/~universe ~*~ Enjoy! ~*~
Hail OO Modelling! * Hail the Wireless Web!
@Elliott 2003 my comments ~ newsgroups+bitnet OK
Universe
> Daniel T. wrote:
>> The essence of OO programming is giving the programmer tools so that he
>> may create algorithms such that the runtime system can determine what
>> particular algorithm to use, based on the type(s) of the argument.
> What you describe is polymorphism.
>> Everything else, including allowing "data types" to include behavior,
>> and hiding implementation, is included in order to support the above...
> Well, that's an over-simplification. There are other important aspects
> in OO like inheritance, encapsulation etc. Read this FAQ for a better
> description:
Fundamentally OO is about using objects as the central granule of
modelling abstraction of collaborating networks of objects. All other
properties are a consequence and outcome of that primary fact.
Universe
> Fundamentally OO is about using objects as the central granule of
> modelling abstraction of collaborating networks of objects. All other
> properties are a consequence and outcome of that primary fact.
I'm very much open to specific and concrete refutation or revision.
Jesper Nordenberg
> Jesper Nordenberg wrote:
>>Depends on how you see it. Everything is an evolution of something that
>>existed before.
>
>
> Somethings are a simple "quantitative" "evolution", while others are a
> more "qualitative" "revolution", "punctuated equilibrium", or complex
> leap.
>
> I see OO as a "revolutionary" leap as opposed to merely prosaic
> evolutionary extension of the Structure paradigm.
Well, in that case, I see it as a revolutionary evolution that started
with a complex leap into equilibrium.
/Jesper Nordenberg
Kaz Kylheku
> Kaz Kylheku <k...@ashi.footprints.net> wrote in message
> news:cf333042.03020...@posting.google.com...
> > object oriented programming: defining new types that are called
> > classes, and building them up using inheritance. Inheritance builds an
> > extension of a type which is substitutable for that type.
>
> Not quite.
> Inheritance builds a type that *acquires the properties of the type that
> it inherits from* . This process does not require or enforce the
> inheriting type to be an extension.
You're right of course, and the term ``inheritance'' is used in all
kinds of contexts that don't even involve OO. E.g. a ``This parse tree
node inherits the attributes of its children.'' or ``an object created
in the Unix filesystem inherits the setgid bit of the directory''.
If properties are inherited by a type, but no type substitutability
results, I would not call that inheritance in the object-oriented
sense. To avoid confusion, I would call it something else.
If type substituability does not result, then the inheritance is
incomplete, in fact. Because if you have some type T, then the objects
O of that type satisfy the predicate is-a(T, O). That predicate in
fact defines a property. If the resulting type does not satisfy that
predicate, then it has failed to inherit one of the properties of the
type, and a fundamental one at that, namely that the type is of that
type! :)
Daniel T.
:-) That's funny...
Let's look at the two items you mentioned above specifically...
Inheritance: In a dynamic-typed language, inheritance is nothing more
than a code reuse mechanism. In a static-typed language it is also used
as a mechanism that allows the computer to choose the proper algorithm
at runtime. In the former, inheritance is unnecessary (one could just as
easily reuse code through aggregation,) in the latter inheritance is the
very tool used to support polymorphism. Making polymorphism the most
important aspect, and inheritance a rudimentary support tool that isn't
even necessary...
Encapsulation: In order for polymorphism to work, one must be able to
extract abstract concepts from complex data types, otherwise, there is
no polymorphism because there aren't multiple algorithms for the system
to choose between. IE we must encapsulate our complex data type in such
a way that several will expose a common interface. Again, we find that
encapsulation's purpose is to support polymorphism, without
polymorphism, encapsulation is unnecessary.
Data Hiding (just in case some people still equate it with
encapsulation): Data hiding is unnecessary as an OO concept. Several
languages (for example Python and Object Pascal) don't even have it, yet
useful OO programs can be written.
Daniel T.
> Fundamentally OO is about using objects as the central granule of
> modelling abstraction of collaborating networks of objects. All other
> properties are a consequence and outcome of that primary fact.
Poo. You've just done a wonderful job of describing the nature of ADTs.
Jesper Nordenberg
> extract abstract concepts from complex data types, otherwise, there is
> no polymorphism because there aren't multiple algorithms for the system
> to choose between. IE we must encapsulate our complex data type in such
> a way that several will expose a common interface. Again, we find that
> encapsulation's purpose is to support polymorphism, without
> polymorphism, encapsulation is unnecessary.
I don't know how you define encapsulation and data hiding, but when I
use the term encapsulation I mean protecting the data inside an object
so that it cannot be manipulated from the outside except through the
interface defined by the object. This protection mechanism is valuable
even if polymorphism isn't supported.
> Data Hiding (just in case some people still equate it with
> encapsulation): Data hiding is unnecessary as an OO concept. Several
> languages (for example Python and Object Pascal) don't even have it, yet
> useful OO programs can be written.
:-) Useful OO programs can be written in C as well, but providing
certain basic OO tools in the programming language itself makes it a lot
easier and safer.
/Jesper Nordenberg
Universe
Makes eminent sense.
Pulleeezzz.
Eager for useful comment, including any degree of difference.
Warren Zeigler
--
Warren Zeigler
wzei...@UnderstandingObjects.com
"Alfredo Novoa" <alf...@ncs.es> wrote in message
news:e4330f45.03020...@posting.google.com...
> "Warren Zeigler" <warren...@attbi.com> wrote in message
news:<Z9o%9.140035$Ve4.8946@sccrnsc03>...
> > Comments inline...
>
> > No one said that you could not program OO using a procedural language.
In
> > fact, a lot of OO is "good coding practices" from procedural.
>
> In other words OO is an extension (evolution) of structured
> programming.
Your bias is showing.
No, the two methods have many common elements.
> > As I put it in class, objects are like a sauce.
> > If you cook, you know that you use basic ingredients to create a sauce,
then
> > the sauce itself is a basic ingredient in a new receipe. OO is all about
> > USING objects
>
> Objects are simply variables or values.
No. There are objects that are simply facilities - large or small - then
there are objects that collaborate. The second are often more significant in
their behavior than value.
You obviously have a poor understanding of OO. I suggest you learn more
before such critisizms.
> > We are talking about answering a new student's question. Your comment
would
> > just confuse at that level.
>
> Are the students 8 years old?
You are obviously not an educator.
> I think we can require a minimal mathematical background.
Math is important, but to ONLY define mathematically is very poor education.
In reality, people only thrown math definitions will spend a lot of time
trying to understand implications. They cannot quickly build on such
definitions.
> What is confusing is the usual sloppy OO terminology.
>
> Fundamental terminology should be the start of any basic programming
> course.
No, properly understanding the terminology - and it's implications - IS the
fundamental course.
> Concepts like: type, variable, value, operator, operand, function,
> invariant, precondition, postcondition, model, implementation,
> literal, scalar type, collection type, etc, etc.
>
> > > A couple other basic statements:
> > > > * In object-oriented programming, major functionality is realized
> > through
> > > > the collaborations of objects.
> > >
> > > Like in structured programing through the collaboration of variables.
> >
> > Variables do not collaborate, they are used. Collaboration implies
action,
> > thus code.
>
> Variables are objects.
Close, but no cigar.
> Collaboration, and action are also a fuzzy terms.
Not at all. Now you are having problems with definitions.
> > > > * With procedural, you simply "do."
> > >
> > > Most OO languages are 100% procedural.
> >
> > Now you are going off the deep end.
>
> Are not Java, and C++ procedural?
Of course not.
> > > > - Think of describing how to get
> > > > somewhere w/ a strip map. W/ objects, you create a structure (think
of a
> > > > street map) then USE the structure (directions on the map) to
accomplish
> > > > your goals.
> > >
> > > You can do the same with structured programming.
> >
> > Not without "hand rolling" OO in the structured language. Why bother?
>
> Then progammers were hand rolling OO in the structured languages
> during a lot of years.
Only if they were using the language to create objects.
Universe
> Universe <univ...@radixundo.net> wrote:
A) The ADT approach doesn't rely primarily upon objects as the core of its
modelling *technique*. Objects <> ADTs. And it is only a "technique" not
a full blown paradigm by any means, as I discuss in the next point.
ADTs are not meant to carry *any* given coherent role or
responsibility. Mostly they are seen as scalar or aggregate *value*
prototypes. Eg. float, int, char, string etc.
Granted objects are a takeoff and extension of ADTs as Nygaard and Dahl
freely acknowledge. But just as much at the same time, they make it
clear that objects are quite more than simply ADTs.
B) ADTs are mostly seen by its programmer users as a non-central *part* of
the larger Structured paradigm, whereas somewhat complete and coherent
role responsible objects are situated at the very core, are the essence of
the OO modelling paradigm. Further all of the major properties and
"forces" primarily employed in the OO paradigm - polymorphism, identity,
state, encapsulation - are major facets of objects or a consequence of the
collaborating networks of objects. Which is good segue' for:
C) Networks of collaborating objects, next to objects themselves, and
arguably *more* than simply isolated objects, are a central and
fundamental aspect of the OO modelling paradigm. No such realization
exists respecting the use of ADT's within the Structured modelling
paradigm.
Certainly you see a key step when coming upon objects in OO versus the use
of ADT's within the Structured paradigm.
D) The major granule of abstraction in the Structure paradigm is the
*function/coroutine/procedure* etc and in no way is it ADTs. Whereas in
the OO paradigm objects are chief and core granule of abstraction.
Collaborating networks of objects in the OO paradigm just a step behing in
importance.
Comment(s) welcomed.
Warren Zeigler
news:b1mbs7$91l$2...@news1.radix.net...
> Fundamentally OO is about using objects as the central granule of
> modelling abstraction of collaborating networks of objects. All other
> properties are a consequence and outcome of that primary fact.
Very good, but could you do it w/o using the word "object?"
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
news:t_leinad-244769...@nnrp02.earthlink.net...
What is "collaborating networks" doing there if this is just ADTs???
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Universe
The essential thing about OO encapsulation, which it seems you touch on is
that code units, especially in the OO paradigm, classes/objects, generally
and overwhelimingly mostly should interact interact via their public
interfaces--the external--as opposed to, or in contradistinction to, their
"innards"--the internal.
Many very good and positive things accrue from such a practice as opposed
not doing so. Especially they accrue regarding achieving loose coupling
between units while at the same time gaining highly focused role coherence
within code units. These contribute to systems and programs that have the
chararcteristics of being optimally flexible, and robust, as wells as
high in scalableness.
Universe
> "Universe" <univ...@radixundo.net> wrote in message
>> Fundamentally OO is about using objects as the central granule of
>> modelling abstraction of collaborating networks of objects. All other
>> properties are a consequence and outcome of that primary fact.
> Very good, but could you do it w/o using the word "object?"
Is that really necessary? For some reason(s) I don't think so.
Object <> Object-Oriented. Once one defines "object" without using the
word "object", it seems one is well free to define "object-oriented", as I
do above, by using the word "object" while not using "object-oriented".
N'est ce pas?
Daniel T.
Jesper Nordenberg <jes...@nnl.se.remove.this> wrote:
> > Encapsulation: In order for polymorphism to work, one must be able to
> > extract abstract concepts from complex data types, otherwise, there is
> > no polymorphism because there aren't multiple algorithms for the system
> > to choose between. IE we must encapsulate our complex data type in such
> > a way that several will expose a common interface. Again, we find that
> > encapsulation's purpose is to support polymorphism, without
> > polymorphism, encapsulation is unnecessary.
>
> I don't know how you define encapsulation and data hiding, but when I
> use the term encapsulation I mean protecting the data inside an object
> so that it cannot be manipulated from the outside except through the
> interface defined by the object. This protection mechanism is valuable
> even if polymorphism isn't supported.
So when you use the term encapsulation, you mean hiding the data... OK,
then see below. :-)
> > Data Hiding (just in case some people still equate it with
> > encapsulation): Data hiding is unnecessary as an OO concept. Several
> > languages (for example Python and Object Pascal) don't even have it, yet
> > useful OO programs can be written.
>
> :-) Useful OO programs can be written in C as well, but providing
> certain basic OO tools in the programming language itself makes it a lot
> easier and safer.
Easier and safer, is not more OO. Hiding data so that changes to it can
be tracked is a good thing to do, no matter the language or paradigm.
Richard Riehle
> Richard Riehle <ric...@adaworks.com> wrote in message news:<3E3D7BFA...@adaworks.com>...
> > Alfredo Novoa wrote:
>
> > Actually, it is not so sloppy as it is abstract. In software, we often speak
> > of "levels of abstraction." It is perfectly appropriate to select the level >of
>
> Where is the formal definition of "behavior" in a programming language
> context? We have the more precisse operator term. Why not use it?
Because not all behavior is based on operators. Behavior includes a
variety of things permitted on an object of some type.
> In ADA 83 we can do something like this:
>
> function "+" (LEFT, RIGHT : MATRIX) return MATRIX;
> function "+" (LEFT, RIGHT : VECTOR) return VECTOR;
This is acceptable Ada, no doubt about it. It is also not a
structure programming model. Ada 83 supported the notion
of object even though it did not support extensible inheritance
of type attributes. Ada 95 does support both inheritance and
polymorphism, as you probably know.
In the above example, Matrix and Vector are typically abstract
data types, probably declared as private. Note that the notion
of private rarely, if ever, becomes an issue unless we are
speaking of object technology.
As to overloading of operators, it is sometimes useful to make the
distinction between operators and operations. In Java, you will
find yourself frustrated when trying to overload operators, but there
is no problem with operations. The inability to overload is not
evil. It was probably a good language design decision, given the
limited range of applications appropriate to Java. C++ folks may
sometimes let overloading get out of hand.
The design decisions of a language designer have some foundation
in experience and expectations. It is quite easy for me to complain
that your pickup truck does not have a large enough backseat or for
you to complain that my Corvette fails to carry a large enough load
of gravel, or for Warren Ziegler to complain that he has to wear
a helmet when riding his Harley Goldwing, but not when he is
driving his Jaguar.
If there is no tool that has the properties you require, perhaps you
need to design one that does.
> http://archive.adaic.com/standards/83lrm/html/lrm-06-07.html
>
> You can't do this with most OO languages, but nothing impede doing
> that in a future language.
Well, we can certainly do this in Ada 95, if we wish. In fact, Ada 95
has relaxed some of the restrictions in Ada 83 so we have even more
powerful option available now.
> Current OO languages are not very good.
I have often noted that current programming languages are not yet at
the end of evolutionary cycle needed to create the perfect language.
One hundred years from now, whoever is doing the equivalent of
what we do now in software, is likely to regard us, if at all, with
same regard we give mathematicians in the time of Charelemagne.
> I am tired of using OO languages. I find all of them rather
> unsatisfactory.
I have read your list of complaints below. Not all of your complaints
are true of all languages.
> OO fans resemble a lot the old assembler, spaghetthi and structured
> fans.
Guilty as charged.
Richard Riehle
Daniel T.
> "Daniel T." <t_le...@knilhtrae.ten> wrote:
>
> > Universe <univ...@radixundo.net> wrote:
> >
> > > Fundamentally OO is about using objects as the central granule of
> > > modelling abstraction of collaborating networks of objects. All other
> > > properties are a consequence and outcome of that primary fact.
> >
> > Poo. You've just done a wonderful job of describing the nature of ADTs.
>
> What is "collaborating networks" doing there if this is just ADTs???
The point I'm trying to make is that without polymorphism, you simply
aren't doing OO. All the "objects" in the world doesn't make a program
an OO program.
Really, Elliott said nothing in the above... "OO programing is
programming with objects."
Warren Zeigler
Not true. You have fallen into a common trap.
OO contains many tools. Each is used if and where appropriate for the
abstraction/problem/solution.
You don't have to use the whole alphebet for a sentence to be valid. The
same is true w/ OO techniques and OO programs.
A language or environment MUST support encapsulation, inheritance and
polymrophism to be labeled OO. You don't have to use all of these, or all of
the rest of OO techniques in every program. There is no "bar" between
object-based programs and OO programs as there is for languages and
environments.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
> > Very good, but could you do it w/o using the word "object?"
>
> Is that really necessary? For some reason(s) I don't think so.
Necessary for whom?
I seriously like the definition, and was hoping for an expanded version for
the layman/uninitiated.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
> Many very good and positive things accrue from such a practice as opposed
> not doing so. Especially they accrue regarding achieving loose coupling
> between units while at the same time gaining highly focused role coherence
> within code units. These contribute to systems and programs that have the
> chararcteristics of being optimally flexible, and robust, as wells as
> high in scalableness.
Correct, but I would say it a little simpler - The public interface supports
the abstraction. Everything else is private/encapsulated.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
> So when you use the term encapsulation, you mean hiding the data... OK,
> then see below. :-)
That's part of it. You also hide "internal" methods that are not part of the
abstraction.
Also, while not part of the common definition of OO encapsulation, you also
can/do encapsulate:
* creation/deletion
* allocation/deallocation
* modality
* lower-level layers of functionality
* creation of specific instances from a generality
* cloning
* persistence
* etc
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Topmind
> > :-) Useful OO programs can be written in C as well, but providing
> > certain basic OO tools in the programming language itself makes it a lot
> > easier and safer.
>
> Easier and safer, is not more OO. Hiding data so that changes to it can
> be tracked is a good thing to do, no matter the language or paradigm.
>
Then use a database with good view management tools, triggers,
and logging of changes.
The advantage of this over OO is that *every* language and paradigm
that uses the DB is subject to the same gate-keeper.
-T-
Jesper Nordenberg
>
> Thanks for the feedback and kind words.
>
> > Whatever we end up calling this
> > approach to developing software, it is clear that simply focusing on
> > object-oriented programming with its emphasis on inheritance and
> > polymorphism, is a bit too narrow a focus to include all the possible
> > collaborations and relationships possible between software objects.
>
> Yes, and I see this narrow focus distorting training. It is a well-known
> phenomenon that new OO programmers overuse inheritance and underuse
> associations. This comes from excessive emphasis on "the big three."
I agree. I can only speak from my own learning experience, but I think
most people (including myself) start at the "wrong end". We first
learn about variables, for-loops, "data" etc., but over time we
realize that these are not the most important parts of a program. The
things that should be taught to a new programmer is interfaces (and
specialization of these), composition, delegation, encapsulation,
design patterns, refactoring etc. There is no need to concentrate on
objects, they are just a necessity for providing the implementation of
interfaces. They should never be the center of the design. Also, there
is no need to learn about for-loops, switches, if-statements in the
beginning. They are mostly useful when implementing algorithms, and we
already have good implementations of most algorithms.
Hybrid OO programming languages like Java and C++ doesn't help to
teach the right methodologies, because they let you escape to C style
programming instead of thinking about the OO design. We need better
tools and languages that makes "correct" OO programming easier. The
tools should enforce good OO practices, if possible.
/Jesper Nordenberg
Alfredo Novoa
> No (or not quite) .
> The creators of Simula used the impl of a block-structured prog lang (Algol)
> as the basis of the impl for a prog lang (Simula) that was intended to be
> used for systems simulation. This prog lang was devised to deal with sets of
> *entities* with behavioural properties.
Probably they wanted to do something revolutionary, but I don't think
what they did was really revolutionary.
OO can be easily integrated in the Algol structured body.
Regards,
Alfredo
Alfredo Novoa
> I see OO as a "revolutionary" leap as opposed to merely prosaic
> evolutionary extension of the Structure paradigm.
I don't think you are using the words "paradigm" and "revolutionary"
in the same sense as Kuhn did in "Structure of Scientific Revolutions"
Regards,
Alfredo
Alfredo Novoa
> I dont agree. If you want to compare programming languages, yes, but if
> your new to programming I think it's better to start with OO concepts
> like interfaces, design patterns, refactoring etc. No need to learn
> stuff that you shouldn't use in OO programming.
If you want to learn design patterns and refactoring you must know
first what a type and a variable are.
> > Variables are objects.
>
> What do you mean with "variable"? Typically a variable is a handle to a
> value.
A placeholder for a value.
> The variable can change it's value, that's why it's called a
Correct.
> variable. An object is a value, not a variable.
An inmutable object is a value, a mutable object is a variable.
Object(value) and object(variable) are two homonym words, and homonym
words are very dangerous.
> >>>Most OO languages are 100% procedural.
> >>
> >>Now you are going off the deep end.
> >
> > Are not Java, and C++ procedural?
>
> Yes, but an OO language don't necessarily have to be procedural.
Thats why I said 'most'.
Regards,
Alfredo
Alfredo Novoa
> > Are not Java, and C++ procedural?
>
> Of course not.
Discussing with you is a waste of time.
I feel sorry for your students.
Regards
Daniel T.
> "Daniel T." <t_le...@knilhtrae.ten> wrote:
>
> > The point I'm trying to make is that without polymorphism, you simply
> > aren't doing OO. All the "objects" in the world doesn't make a program
> > an OO program.
>
> Not true. You have fallen into a common trap.
>
> OO contains many tools. Each is used if and where appropriate for the
> abstraction/problem/solution.
>
> You don't have to use the whole alphebet for a sentence to be valid. The
> same is true w/ OO techniques and OO programs.
>
> A language or environment MUST support encapsulation, inheritance and
> polymrophism to be labeled OO. You don't have to use all of these, or all of
> the rest of OO techniques in every program. There is no "bar" between
> object-based programs and OO programs as there is for languages and
> environments.
I guess we will have to agree to disagree. As I said before, inheritance
is wholly unnecessary, and encapsulation is nothing more than a
conceptual tool (or to put it another way, it is something so
fundamental to programming, that every language supports it, even
assembly.)
I believe that a program written without polymorphism is simply not an
OO program, you think that some of these non polymorphic programs can be
called OO. I guess the question then is, how do you know when a program
has been written in an OO style? Simply by whether the language it is
written in is an "OO language"?
--
My email address is reversed. Fix it if you want to email me.
S Perryman
news:e4330f45.03020...@posting.google.com...
> "S Perryman" <q...@q.com> wrote in message
news:<b1m4gi$13b6pc$1...@ID-75294.news.dfncis.de>...
> > The creators of Simula used the impl of a block-structured prog lang
(Algol)
> > as the basis of the impl for a prog lang (Simula) that was intended to
be
> > used for systems simulation. This prog lang was devised to deal with
sets of
> > *entities* with behavioural properties.
> Probably they wanted to do something revolutionary, but I don't think
> what they did was really revolutionary.
They wanted to do something for simulation systems.
I suspect that they were not considering their work as revolutionary.
However, the realisation of what they had actually done, the thing we now
call OO, is *very* revolutionary. A whole new way of developing s/w
arose. The greatest minds in the CS field (Dijkstra etc) stated that Simula
took and inspired them in new directions.
> OO can be easily integrated in the Algol structured body.
Because the creators of Simula decided to use the impl of Algol as the
basis of their impl for Simula, is precisely why "OO can be easily
integrated in the Algol structured body" .
You are attempting to use an "after the fact" thing to argue that something
is/was possible "before the fact" . If they had decided to use PL/1, or
Lisp,
then to assert your claim then you would have to implement Simula from
scratch, using Algol, all by yourself.
And we know "after the fact" that it took a team of smart bods 6-7 yrs
to do this ...
Regards,
Steven Perryman
S Perryman
> I believe that a program written without polymorphism is simply not an
> OO program, you think that some of these non polymorphic programs can be
> called OO. I guess the question then is, how do you know when a program
> has been written in an OO style? Simply by whether the language it is
> written in is an "OO language"?
- How do I know when a program has been written in an ADT style ??
Because it has the traits of ADTs (interface/impl separation, information
hiding) .
- How do I know when a program has been written in an object-based style ??
Because it has the constructs needed to support object-based programming
(first example, the CLU prog lang) .
- How do I know when a program has been written in an OO style ??
Because it is object-based, and uses inheritance.
- How do I know when a program has been written using polymorphism ??
When specific entities (types, ops etc) exist in *more than one form*
(interface +/- implementation) .
The usual mess, with people mixing up ADTs, object-based, encapsulation,
information hiding, inheritance, type substitutabilty etc and getting into
all
sorts of trouble.
Get your definitions straight, and all these debates vanish.
Regards,
Steven Perryman
Warren Zeigler
news:e4330f45.03020...@posting.google.com...
Your bias shows in every posting.
> I feel sorry for your students.
Gee, and so many professional have recently evaluated my course and said
otherwise. (You will see a few announcements of purchase over the next 6
months. Major.)
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
news:9c838fb.03020...@posting.google.com...
> I agree. I can only speak from my own learning experience, but I think
> most people (including myself) start at the "wrong end". We first
> learn about variables, for-loops, "data" etc., but over time we
> realize that these are not the most important parts of a program. The
> things that should be taught to a new programmer is interfaces (and
> specialization of these), composition, delegation, encapsulation,
> design patterns, refactoring etc. There is no need to concentrate on
> objects, they are just a necessity for providing the implementation of
> interfaces. They should never be the center of the design. Also, there
> is no need to learn about for-loops, switches, if-statements in the
> beginning. They are mostly useful when implementing algorithms, and we
> already have good implementations of most algorithms.
>
> Hybrid OO programming languages like Java and C++ doesn't help to
> teach the right methodologies, because they let you escape to C style
> programming instead of thinking about the OO design. We need better
> tools and languages that makes "correct" OO programming easier. The
> tools should enforce good OO practices, if possible.
Good thoughts, but hard to implement.
One of the most common failings of training (formal or self) is for the
student (and sometimes teacher) to just understand a few elements and think
"I got it!"
The things you would like to not emphasis are necessary preliminaries. (You
also need to add collections and data structures for the collections.)
My course Understanding Objects ( see www.UnderstandingObjects.com ) gets
through the basics and the more advanced concepts. I also recommend study of
a language and a methodology. THEN it will take a few months practice -
hopefully with access to a mentor - to gain any level of proficiency.
Simply put, OO has many elements. It requires the creation and
initialization of an infrastructure (as illustrated by the static diagrams),
then its use. This infrastructure utilizes several concepts, basic and
advanced, that must be understood - not just well enough to read code, not
just well enough to write code, but well enough to creatively design. Simply
learning control flow or object construction doesn't hack it. People learn
this, are placed on the bench, then spend months to years learning the
things they could have been taught in class. Sad.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
> I guess we will have to agree to disagree. As I said before, inheritance
> is wholly unnecessary, and encapsulation is nothing more than a
> conceptual tool (or to put it another way, it is something so
> fundamental to programming, that every language supports it, even
> assembly.)
>
> I believe that a program written without polymorphism is simply not an
> OO program, you think that some of these non polymorphic programs can be
> called OO. I guess the question then is, how do you know when a program
> has been written in an OO style? Simply by whether the language it is
> written in is an "OO language"?
Inheritance is code AND interface reuse - conceptually extening both type
and abstraction.
Encapsulation simplifies design, debuging, enables modification, and
preserves the abstraction as expressed in the public interface.
Polymorphism is working with abstraction commonalities as expressed through
the interface.
They are all separate tools, used by professionals for use.
Just because you don't have commonalities does not mean you don't have OO.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
news:MPG.18a900b63...@news.earthlink.net...
> Then use a database with good view management tools, triggers,
> and logging of changes.
>
> The advantage of this over OO is that *every* language and paradigm
> that uses the DB is subject to the same gate-keeper.
Gee, I did that on a program and had the database take 45 minutes at times.
It seems that there were 8 sets of data that had to be "ANDED," and with
certain user input the time grew from an acceptable few seconds to nearly an
hour.
For the operation I unloaded the data into collections and performed the
operation in memory using standard OO techniques. 45 minutes turned into 2
1/2 seconds. The product (shrink-wrapped) could be shipped.
"For everything there is a season, and a time for every purpose under
heaven."
--
Warren Zeigler
wzei...@UnderstandingObjects.com
S Perryman
news:cf333042.03020...@posting.google.com...
> "S Perryman" <q...@q.com> wrote in message
news:<b1lmkq$1453nl$1...@ID-75294.news.dfncis.de>...
> > Inheritance builds a type that *acquires the properties of the type that
> > it inherits from* . This process does not require or enforce the
> > inheriting type to be an extension.
> You're right of course, and the term ``inheritance'' is used in all
> kinds of contexts that don't even involve OO. E.g. a ``This parse tree
> node inherits the attributes of its children.'' or ``an object created
> in the Unix filesystem inherits the setgid bit of the directory''.
Indeed.
We live with the multi-use imprecise formats of our written human
languages.
> If properties are inherited by a type, but no type substitutability
> results, I would not call that inheritance in the object-oriented
> sense. To avoid confusion, I would call it something else.
Inheritance + (Simula) type substitutability rules ?? :-)
> If type substituability does not result, then the inheritance is
> incomplete, in fact.
If Simula did not introduce its type substitutability rules, then
inheritance as a pure property acquisition scheme would be nice,
but have limited use (exercise for the reader to show exactly
how limited :-) ) .
What I have come to accept on all these matters is that the
most important thing we desire when building ADT-based s/w
is in fact type substitutability. Whether it comes in OO (inheritance)
flavour, or others, is a moot point IMHO.
Regards,
Steven Perryman
Universe
Right.
And the thing that unites everything in the OO paradigm, used and unused
at any instance, is the use of the object as the core granule of modelling
abstraction--each with coherent role responsibility--and the creation,
managing, and thus leveraging of object collaboration networks.
Is there any doubt?
Universe
> "Universe" <univ...@radixundo.net> wrote in message
>> Many very good and positive things accrue from such a practice as opposed
>> not doing so. Especially they accrue regarding achieving loose coupling
>> between units while at the same time gaining highly focused role coherence
>> within code units. These contribute to systems and programs that have the
>> chararcteristics of being optimally flexible, and robust, as wells as
>> high in scalableness.
> Correct, but I would say it a little simpler - The public interface supports
> the abstraction. Everything else is private/encapsulated.
But the fact that code units mainly rely upon public interfaces vs.
innards is the key to the primary goals and benefits of encapsulation.
>> ...Especially they accrue regarding achieving loose coupling
>> between units while at the same time gaining highly focused role coherence
>> within code units. These contribute to systems and programs that have the
>> chararcteristics of being optimally flexible, and robust, as wells as
>> high in scalableness.
Elliott
H. S. Lahman
>>>>>* With procedural, you simply "do."
>>>>
>>>>Most OO languages are 100% procedural.
>>>
>>>Now you are going off the deep end.
>>
>>Are not Java, and C++ procedural?
>
>
> Of course not.
While not 100%, there are dominantly procedural because they employ
procedural message passing. That's because procedural message passing
is pretty much the only game in town at the 3GL level. One of the
problems with trying to understand OT when starting at the OOPL level is
working around this and other compromises they make with computing
paradigms.
Note that the original C++ was just a preprocessor for C.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH
soft-eng
> "Robert Mark Bram" <relax...@removethis.optushome.com.au> wrote in message news:<3e3c95a9$0$7812$afc3...@news.optusnet.com.au>...
> > Howdy all!
> >
> > Below is a response I gave to a first year Java programming student of mine
> > who asked the question "what is object oriented programming?" This student
> > has done some programming in Java and Unix shell scripting. I post my answer
> > to the group because I welcome feedback. :)
>
> Your answer is skewed toward programming languages whose object
> systems descent from Simula-67.
>
> In reality, there are three principles at the heart of object-oriented
> programming.
>
> The first is this: the insertion of a simple pattern matching layer
> between a function call and its destination. That pattern matching
> layer selects a destination for the call based on unifying the
> attributes (mostly the type) of the arguments against the attributes
> of the collection of candidate methods. This pattern matching layer
> gives rise to generic programming, which allows unlike objects to be
> substitutable for each other in the same syntax, and special-case
> behaviors to be coded to make it all work.
>
> This pattern-matching dispatch is supported by another feature of
> object oriented programming: defining new types that are called
> classes, and building them up using inheritance. Inheritance builds an
> extension of a type which is substitutable for that type. This allows
> existing methods to apply, while allowing the programmer to
> selectively code ones which provide a more specific pattern match for
> the extended type. In decent OO programming systems, type
> substitutability is not restricted to inheritance. A method parameter
> can be specialized to types which are not related by inheritance, like
> string or integer.
>
> Lastly, these class objects can be subject to destructive
> manipulation: they hold state which is stored in slots (a.k.a data
> members, member variables, instance variables). This allows objects to
> have state-dependent behaviors, though object-oriented programming
> over immutable objects is also possible.
...
As far as teaching is concerned, I think this response will
confuse freshman, because it focuses on the mechanisms rather
than the overview.
The POV should be freshman's POV, rather than
the compiler writer's POV.
An "object" is a "thing". Examples of things are
"computers", "chair", "table", "blackboard".
Things have properties. Animals have 4 legs. So we
need some information storage for an object, e.g.
int numLegs = 4;
(This is still implementation detail, but this is implementation detail
from the freshman's pov, rather than the compiler's pov.)
We operate on objects, e.g.
animal.feed( foodObject );
Operations on objects may return results. E.g.
FoodType animal.getFavoriteFood();
Objects are grouped in "classes" and each "class"
may have "sub-classes", e.g. "Animals",
"Herbivores", "Cows", "Madcows"...
Sub-classes inherit from super-classes.
cow.getNumberOfLegs();
can just use
animal.getNumberOfLegs();
instead of providing its own implementation.
Sub-classes can be polymorphic, and can change
a certain inherited behavior.
madcow.isHerbivore();
may override
cow.isHerbivore();
and return a "false" result.
OOP should be easier to teach than earlier
design methodologies, not harder. Initially
people thought that OOP would be useful
for simulation only. But later, they
found that mental concepts also fall
neatly into "things". A doubly-linked list
is a sub-class of linked-list, a swing
panel is a sub-class of a generalized
component, and so on...
OOP concepts are already built-into
the mind of the student. It's a natural
programming style. All the teacher needs
to do is connect these built-in concepts
to the mechanical details of translation
into the programming language. Which,
with an OOP language, should not be a
very difficult translation.
H. S. Lahman
> Encapsulation: In order for polymorphism to work, one must be able to
> extract abstract concepts from complex data types, otherwise, there is
> no polymorphism because there aren't multiple algorithms for the system
> to choose between. IE we must encapsulate our complex data type in such
> a way that several will expose a common interface. Again, we find that
> encapsulation's purpose is to support polymorphism, without
> polymorphism, encapsulation is unnecessary.
I think this is too strong. Polymorphism is enabled by encapsulation
but one could also argue it is enabled by dynamic relationship
instantiation, inheritance, and abstraction.
I think encapsulation is about modularity. In particular, the OO spin
on encapsulation is aimed at ensuring cohesion and providing decoupling
at the scale of logically indivisible program units that capture
*related* state and behavior (objects). That is a rather unique view of
encapsulation compared to other software development approaches.
As far as polymorphism itself is concerned, I would agree it is pretty
hard to develop a good OO application without some form of it. But the
same could be said for good procedural programs and all functional
programs because they make extensive use of parametric polymorphism.
In fact, the form of polymorphism uniquely associated with OT, inclusion
polymorphism, is actually pretty rare in OOA solutions because most
problem spaces outside computing don't rely on implicit behavior
substitution (i.e., one explicitly switches roles driven by context).
OTOH, it is very common at the OOP level because it is an excellent
means of managing dependencies that affect code maintainability. (A
similar situation exists for overload polymorphism at the OOP level.)
Parametric polymorphism is very important to OT and OT explicitly
facilitates it (e.g., specification objects and dynamic relationships),
but it is also very common in other development paradigms so one can't
really regard it is a signature characteristic of OT.
However, I think one could argue that OT is unique in the sense that it
encourages all forms of polymorphism in an egalitarian fashion. B-)
Joona I Palaste
on comp.lang.java.programmer:
>> Are not Java, and C++ procedural?
> Of course not.
I would call Java and C++ procedural. Procedurality and OO do not
exclude each other. A procedural language defines the program flow as
procedures calling each other. In an OO procedural language these
procedures live in objects, so the caller of the procedure might not
know or even care about what implements the procedure and how it
implements it. In a non-OO procedural language the calling procedure
and the called procedure are more tightly coupled.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I am lying."
- Anon
Daniel T.
> "Daniel T." <t_le...@knilhtrae.ten> wrote:
>
> > I guess we will have to agree to disagree. As I said before, inheritance
> > is wholly unnecessary, and encapsulation is nothing more than a
> > conceptual tool (or to put it another way, it is something so
> > fundamental to programming, that every language supports it, even
> > assembly.)
> >
> > I believe that a program written without polymorphism is simply not an
> > OO program, you think that some of these non polymorphic programs can be
> > called OO. I guess the question then is, how do you know when a program
> > has been written in an OO style? Simply by whether the language it is
> > written in is an "OO language"?
>
> Inheritance is code AND interface reuse - conceptually extening both type
> and abstraction.
Only in certain languages. In some languages inheritance can be for just
code reuse, in others it can be for just interface reuse. In all
languages that I know of including Python, C++, Java, Eiffel, and
Smalltalk, inheritance is unnecessary for code reuse, and only the
static-typed languages require it for interface reuse.
> Encapsulation simplifies design, debugging, enables modification, and
> preserves the abstraction as expressed in the public interface.
Agreed. This is why functions have a single well defined entry point for
example. This is a form of encapsulation... Encapsulation is not a
hallmark, nor even an indicator of OO.
> Polymorphism is working with abstraction commonalities as expressed through
> the interface.
Now we're talking OO!
> They are all separate tools, used by professionals for use.
>
> Just because you don't have commonalities does not mean you don't have OO.
Just because professionals use the tool, doesn't automatically make the
tool an OO tool.
My question still stands. I think everyone on comp.object agrees that
one can "do OO programing" in C, and one can "do procedural programming"
in Java. So language issues aren't at the forefront. What identifies a
program as an "OO program" if not polymorphism?
Universe
> ...
> In fact, the form of polymorphism uniquely associated with OT, inclusion
> polymorphism, is actually pretty rare in OOA solutions because most
> problem spaces outside computing don't rely on implicit behavior
> substitution (i.e., one explicitly switches roles driven by context).
Banks and many of their clients aren't faced with 1 of Many kinds of
related accounts? Say a handful of commonly similar yet variably
different savings accounts. Checking accounts. Certificate of Deposit
accounts.
Home electrical stores don't sell numerous lines of commonly similar yet
variably different light fixtures? Light switches. Fuse boxes.
Ericsson doesn't sell lines of commonly similar, yet variably different
cell phones?
When you pull up to the pump, at least in the US, on can get 97, 93, or 89
octane petrol.
Messr. Lahman lives in a very strange non-polymorphic world indeed.
Universe
The list of examples of real world polymorphism and their extension by any
reasonable to person to an infinite plethora of other real world cases of
polymorphism seem to me to be at 1 very key, or major, reason for
creating, managing and leveraging polymorphism in the OO paradgim.
Real world object interaction exhibits real world polymorphism. Why
shouldn't they be present in OO, a modelling paradigm that models via role
responsible objects their collaborating networks?
Elliott
Warren Zeigler
news:3E401920...@verizon.net...
> While not 100%, there are dominantly procedural because they employ
> procedural message passing. That's because procedural message passing
> is pretty much the only game in town at the 3GL level. One of the
> problems with trying to understand OT when starting at the OOPL level is
> working around this and other compromises they make with computing
> paradigms.
Message passing as you call it (using the assembly CALL) has nothing to do
with procedural vs OO.
OO was origionally intended for each object to be in a separate thread,
hence "message passing". This is not the case in most situations, nor is it
often desirable.
You can program procedurally w/ messages, and OO w/ calls. They are
different layers, not tied together.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
news:b1pbja$bed$1...@oravannahka.helsinki.fi...
> I would call Java and C++ procedural. Procedurality and OO do not
> exclude each other. A procedural language defines the program flow as
> procedures calling each other. In an OO procedural language these
> procedures live in objects, so the caller of the procedure might not
> know or even care about what implements the procedure and how it
> implements it. In a non-OO procedural language the calling procedure
> and the called procedure are more tightly coupled.
You are creating knots in your logic by tying layers together.
OO vs Procedural has NOTHING to do w/ calls vs messages.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
news:9fa75d42.03020...@posting.google.com...
In your explination, you got through a few basic concepts, but have not
backed out enough for the big picture.
> OOP concepts are already built-into
> the mind of the student. It's a natural
> programming style. All the teacher needs
> to do is connect these built-in concepts
> to the mechanical details of translation
> into the programming language. Which,
> with an OOP language, should not be a
> very difficult translation.
This is more true for Europeans than Americans due to the language. Also,
programmers trained in another paradigm have learned concepts that confuse
the object view. You need to back out further than you have to communicate
sucessfully with them.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
> My question still stands. I think everyone on comp.object agrees that
> one can "do OO programing" in C, and one can "do procedural programming"
> in Java. So language issues aren't at the forefront. What identifies a
> program as an "OO program" if not polymorphism?
You are stuck on one point.
What identifies OO more than anything else? Probably instantiation and
references. These are the only things common in all object programs.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
> And the thing that unites everything in the OO paradigm, used and unused
> at any instance, is the use of the object as the core granule of modelling
> abstraction--each with coherent role responsibility--and the creation,
> managing, and thus leveraging of object collaboration networks.
Now THAT's a good definition!
This is one of the main benifits of these discussions - to find better ways
of expressing these concepts.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
> But the fact that code units mainly rely upon public interfaces vs.
> innards is the key to the primary goals and benefits of encapsulation.
On the surface we appear to be saying different things, but think about it.
I think we are really saying the same thing.
Code units only call the public interface because they represent an
instantiation of the abstraction.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
"Universe" <univ...@radixundo.net> wrote in message
news:b1p2p7$rqp$2...@news1.radix.net...
Warren Zeigler
> Messr. Lahman lives in a very strange non-polymorphic world indeed.
It is difficult to say a sentence that does not contain a generality that,
translated to OO cannot be expressed polymorphically.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
"Universe" <univ...@radixundo.net> wrote in message
news:b1pjbe$7jd$1...@news1.radix.net...
Uncle Bob (Robert C. Martin)
might not) have written this on (or about) Sun, 2 Feb 2003 14:51:15
+1100, :
>Every programming language ever used has one thing in common: variables.
Well... Then there are languages like Forth, that don't really have
named variables. In Forth values are manipulated on the stack. It is
true that there are storage locations that can be manipulated, but
they don't have names.
Then there are languages like Prolog. These languages have named
storage locations, but you can't change their values -- so they aren't
really variables.
Functional languages are similar. They have named storage locations,
but the values can only be initialized, not changed.
I suppose there are even more bizarre examples.
Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |
"...a member of my local hiking club is a
nudist. I once asked him if he ever hiked in the nude. He responded
that he was a nudist, he wasn't nuts."
-- Daniel Parker
Uncle Bob (Robert C. Martin)
might not) have written this on (or about) Sun, 2 Feb 2003 14:51:15
+1100, :
>Object oriented ideas came about as we began to understand more about the
>potential advantages of storing data *with* process. It is easier to think
>of a Product object with methods and its own data (given when the object is
>made) as it is to think about a set of Product functions that always have to
>be given an array of product data before they can do anything...
>
>Basically, Object Oriented Programming is about expanding the concept of
>"data types" to allow types of data that include behaviour..
While there is some truth to this, it is not what motivated the
beginnings of OO. OO was motivated in the late 60s when some computer
scientists (namely Ole Johan Dahl, C.A.R. Hoare, E.W. Dijkstra, and
Kristian Nygaard) were playing around with the block structured
language Algol. They noted that a block was a data structure that had
variables and functions within it. They also noted that this data
structure lived on the stack, and could therefore only live as long as
the function that created it. They wondered what would happen if this
data structure were decoupled from the lifetime of the function that
created it. And thus, objects were born. (See "Structured
Programming", Academic Press, 1972.)
Uncle Bob (Robert C. Martin)
written this on (or about) Sun, 2 Feb 2003 23:50:55 +0000 (UTC), :
>I wasn't so much asking for evidence,
>as saying that "Bullshit" isn't really much of an argument, more of an
>immature response to a perfectly resonable statement.
Agreed.
Chris Smith
> Message passing as you call it (using the assembly CALL) has nothing to do
> with procedural vs OO.
>
> OO was origionally intended for each object to be in a separate thread,
> hence "message passing". This is not the case in most situations, nor is it
> often desirable.
Hmm... Since OO languages are significantly older than the concept of
threads, I find this unlikely. The use of message passing rather than
"calling" as a metaphor in object-oriented languages has more to do with
assigning the receiving/target object responsibility for dispatch,
rather than the caller... that is, polymorphism, one of the most
important aspects of the definition of OO.
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Uncle Bob (Robert C. Martin)
have written this on (or about) 2 Feb 2003 14:44:35 -0800, :
>The beauty of OO is the way the people thinks in real-world.
I sincerely doubt that. People think in lots of different ways. I
don't think it's fair to say that all people think in an "OO" way.
Indeed, I find it difficult to define what "thinking in an OO way"
might mean.
People sometimes think in terms of procedures. They sometimes think
in terms of truths. They sometimes think in terms of motivations and
values. They sometimes think in pictures, sounds, or smells. They
sometimes think in terms of desires. It is, frankly, not often that
they think of sending messages to objects.
In my humble opinion the argument that "OO is similar to the way
people think in the real world" was invented by some marketeer who was
asked by an executive to explain what OO was. The marketeer realized
that he couldn't explain about dependency management to the executive
so he made up some sugar coated pill that sounded great and had
nothing to do with the issue at all.
Warren Zeigler
message > In my humble opinion the argument that "OO is similar to the way
> people think in the real world" was invented by some marketeer who was
> asked by an executive to explain what OO was. The marketeer realized
> that he couldn't explain about dependency management to the executive
> so he made up some sugar coated pill that sounded great and had
> nothing to do with the issue at all.
I remember a lot of research by IBM (and others) on this topic. It is a well
proven fact that people think more like OO than procedural, and it does
somewhat depend on their native language.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
> variables and functions within it. They also noted that this data
> structure lived on the stack, and could therefore only live as long as
> the function that created it. They wondered what would happen if this
> data structure were decoupled from the lifetime of the function that
> created it. And thus, objects were born.
As I have been saying: Instantiation of the data - the core of objects.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Joona I Palaste
Then please provide your opinion on OO vs Procedural. If it has nothing
to do with calls vs messages, then what does it have to do with?
You're not making much progress in this debate by only attacking other
people's opinions instead of explaining your own.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"This is a personnel commuter."
- Train driver in Scientific American
A Bag Of Memes
> vikrama...@hotmail.com (Vikrama Sanjeeva) might (or might not)
> have written this on (or about) 2 Feb 2003 14:44:35 -0800, :
>
> >The beauty of OO is the way the people thinks in real-world.
>
> I sincerely doubt that. People think in lots of different ways. I
> don't think it's fair to say that all people think in an "OO" way.
> Indeed, I find it difficult to define what "thinking in an OO way"
> might mean.
>
> People sometimes think in terms of procedures. They sometimes think
> in terms of truths. They sometimes think in terms of motivations and
> values. They sometimes think in pictures, sounds, or smells. They
> sometimes think in terms of desires. It is, frankly, not often that
> they think of sending messages to objects.
A large percentage of human thought consists of predictions about social
interactions. Evolution of language and consciousness may have been driven
by social success. Most of what people say to each other is gossip. Object
oriented modeling bears a striking resemblance to this mode of
consciousness. It is common to anthropomorphize objects and speak of them
"telling" each other things, "asking" for results, "listening" to events,
"killing" each other and so forth. (CRC sessions make this concrete by
letting individuals play the role of objects.)
I think this is the key advantage to object oriented software development.
It helps the developer to easily imagine myriad special purpose agents and
their interactions. Our brains evolved just this sort of imagination to
deal with the dangers of living in groups.
Donald Roby
<r...@zedat.fu-berlin.de> wrote:
> "Warren Zeigler" <warren...@attbi.com> writes:
>>Me course Understanding Objects ( see www.UnderstandingObjects.com )
>>gets
>
> "each student will receive a copy of Design Patterns"
>
> Let f be the fee/price of the course. Then f = f0 + f1, where f1 is
> the partial price for the copy of Design Patterns. We have two deals
>
> d0 - buy a course for f0
> d1 - buy a book for f1
>
> and a business rule: "for each d0 there must be a d1."
>
> Isn't this an example of unnecessary High Coupling?
>
> What if someone wanted to attend the course twice, already owns a copy
> or simply does not wanted to buy a copy for other reasons?
>
Sometimes the famous OnceAndOnlyOnce is wrong. ;-)
This is a good enough book that having two copies would be useful... I
have only one, and I've loaned it out.
Or of course you could always sell it.
I agree I'd rather have the option.
S Perryman
news:Ef00a.84631$G83.1258@sccrnsc04...
> "H. S. Lahman" <h.la...@verizon.net> wrote in message
> news:3E401920...@verizon.net...
> > While not 100%, there are dominantly procedural because they employ
> > procedural message passing. That's because procedural message passing
> > is pretty much the only game in town at the 3GL level. One of the
> > problems with trying to understand OT when starting at the OOPL level is
> > working around this and other compromises they make with computing
> > paradigms.
> Message passing as you call it (using the assembly CALL) has nothing to do
> with procedural vs OO.
> OO was origionally intended for each object to be in a separate thread,
> hence "message passing". This is not the case in most situations, nor is
it
> often desirable.
1. OO was not intended to be like a procedural prog lang.
The basis of what is known as "discrete event" simulation is the notion of
entities responding to an event stimulus occurring. A stimulus much akin to
message passing.
2. Simula had pseudo-concurrency.
Objects inheriting from class Process have properties allowing them to
seek/release use of the thread of control in a program unit (use of the
detach/resume primitives etc) .
Regards,
Steven Perryman
S Perryman
> "Robert Mark Bram" <relax...@removethis.optushome.com.au> might (or
> might not) have written this on (or about) Sun, 2 Feb 2003 14:51:15
> +1100, :
> >Object oriented ideas came about as we began to understand more about the
> >potential advantages of storing data *with* process. It is easier to
think
> >of a Product object with methods and its own data (given when the object
is
> >made) as it is to think about a set of Product functions that always have
to
> >be given an array of product data before they can do anything...
> >Basically, Object Oriented Programming is about expanding the concept of
> >"data types" to allow types of data that include behaviour..
> While there is some truth to this, it is not what motivated the
> beginnings of OO. OO was motivated in the late 60s when some computer
> scientists (namely Ole Johan Dahl, C.A.R. Hoare, E.W. Dijkstra, and
> Kristian Nygaard) were playing around with the block structured
> language Algol. They noted that a block was a data structure that had
> variables and functions within it. They also noted that this data
> structure lived on the stack, and could therefore only live as long as
> the function that created it. They wondered what would happen if this
> data structure were decoupled from the lifetime of the function that
> created it. And thus, objects were born. (See "Structured
> Programming", Academic Press, 1972.)
The big lie of OO.
http://java.sun.com/people/jag/SimulaHistory.html
This tells us that rather than playing with Algol, and then discovering OO,
they had many of the ideas first for their desired prog lang, and then
choose Algol as the basis for the *impl* of said prog lang.
Regards,
Steven Perryman
ghl
> vikrama...@hotmail.com (Vikrama Sanjeeva) might (or might not)
> have written this on (or about) 2 Feb 2003 14:44:35 -0800, :
>
> >The beauty of OO is the way the people thinks in real-world.
>
> I sincerely doubt that. People think in lots of different ways. I
> don't think it's fair to say that all people think in an "OO" way.
> Indeed, I find it difficult to define what "thinking in an OO way"
> might mean.
Well, Aristotle thought in an OO way. It would appear that the understanding
of reality is OO.
Aristotle taught that all things that exist have a set of "properties" (he
called them aspects or attributes, I think) that form an "extension" of the
object. Each of these properties gives the thing an aspect that represents
one abstractions of the thing. An example would be the color of a thing ("It
is red"). His claim is that if you know ALL the properties of a thing, you
understand it completely. It is also true that no two separate things have
the same extension of properties, since one of the properties is the thing's
location. This leads to the old "no two things can be in the same place at
the same time" rule.
His logic also includes the behaviors of things, i.e. the activity the thing
can perform. In total, the whole things looks a lot like data members and
method members to me!
He also allows for things existing in two states: existential -- really in
this world, touchable, and useable; and intentional -- things you can
abstract the properties and behaviors for but which do not really exist. And
example would be the idea of a unicorn, which I believe don't really exist
extentially but do exist in the mind, i.e. intentionally.
Anyway, when we design an object for Java (say) we are abstracting those
properties that we are interested in simulating in the computer and ignoring
the rest.
So, OO thinking goes back a long way and one could argue that it is natural
for humans to think that way.
--
--
Gary
ghl
I should think that the distinction is between procedural and structured,
rather than between procedural and OO.
In fact, I could make the argument that a COBOL program is an OO program
which has one giant procedural method and a large set of public data
members. It is, in fact, possible to structure a Java program in such a way
that it is nothing more than a COBOL-like program in Java by using all
static members, all public, and one method (main). Or am I missing
something?
The program could still use structured concepts, using deeply nested
if-then-else and while loops. I once tried this (back in 1966 or so) and the
program got so complicated because of having flags and more flags to control
the inner loops that is wan't debuggable or maintainable.
--
--
Gary
Isaac Kuo
> "Topmind" <top...@technologist.com> wrote in message
> news:MPG.18a900b63...@news.earthlink.net...
> > Then use a database with good view management tools, triggers,
> > and logging of changes.
> Gee, I did that on a program and had the database take 45 minutes at times.
> It seems that there were 8 sets of data that had to be "ANDED," and with
> certain user input the time grew from an acceptable few seconds to nearly an
> hour.
This is a very bizarre result, for a database which fits
entirely in memory. I can see how it might happen if
someone was not familiar with how to use relational
databases and decided to do something in a pathologically
strange way. For example, creating 8 sets of data
independently and then using some sort of full join (this
can result in an exponential ballooning of temporary
database size). This requires some twisted
misunderstandings of relational database usage.
I've had more than my share of stupendously time consuming
database queries, but never on something that fit in memory.
> For the operation I unloaded the data into collections and performed the
> operation in memory using standard OO techniques. 45 minutes turned into 2
> 1/2 seconds. The product (shrink-wrapped) could be shipped.
Generally, a database can do queries much faster than
OO or procedural code, because the database manager can
keep a global picture of what is requested and take
advantage of this global picture to optimize how to go
about calculating the query.
With 3rd generation languages, large problems get split
up into smaller problems in ways such that global
optimization isn't so easy. For example, a method will
typically do a "big" problem by calling several other
methods to do "smaller" problems interleaved with code
to process the intermediate results. Each method has a
myopic view of what to do based on only what's been
passed to them and the next level downward in what methods
they call. If there are several ways to solve a problem,
a method can't easily figure out which way will be the
fastest because it doesn't typically have information
about how fast the methods it would call would be.
Encapsulation enforces this myopism, trading potential
optimizations away in favor of safety/ease of
debugging/development.
With database 4th generation languages, large problems
like a complex query aren't split up like that. Sure,
the implementation of the database manager will in fact
split up any big problem into smaller problems--but it
will do so in a way which can retain a global view. If
there are several ways to solve a problem, the database
manager can typically estimate very accurately which
way will be the fastest because it has complete monolithic
control over the implementation of calculating the query
all the way down to relatively low level file access.
Now, a programmer using a 3rd generation language can
do much the same thing, but it's a mostly manual process
that has to be done specifically for each application.
The advantage of a relational database manager is that
an incredible amount of optimization effort and expertise
can be taken advantage of by everyone for almost any
application. Working within the restrictions of the
inflexible data structure of a relational database is
worth it because you'll never make something so fast
on your own.
I guess really the point is that the best tools in the
world won't do you much good if you don't know how to
use them effectively. A half-decent database is
FAST--that's their big advantage over OOP (which is far
more flexible). But it does take some getting used to
figuring out how to use them efficiently. Unfortunately,
the syntax of SQL hinders understanding more than it helps.
Something more algebraic in syntax would theoretically be
much better, but like it or not SQL is the only standard.
Personally, I'm not a huge fan of OOP--I learned ADTs in
college and ever since then haven't really seen how OOP's
other major features are so great. I love encapsulation,
but I wouldn't miss inheritance and polymorphism that much.
Of course, I'm a database programmer by trade. I'm used
to the idea of only having a handful of "classes" but for
those few object types to be heavily optimized.
Isaac Kuo