What are the schools of OOP ?

Question

Are there philosophical differences between Smalltalk OOP and Simula OOP ?

This is a question related to Java & C# vs C++ indirectly. As I understand, C++ is based on Simula but Java and C# are more or less from the Smalltalk family.

Answer 1

I'd put Java and C# in the Simula camp as well:

• Smalltalk, being dynamically typed, is quite apart of the four other languages you cite.

• Smalltalk is structurally typed (alias duck typing) while the other four are nominally typed.

(What Java and C# have in common with Smalltalk is being mainly based on a VM, but there is little influence on the programming style).

Answer 2

I would say statically typed and dynamically typed OOP are two separate disciplines within the same school of OOP.

Answer 3

Java, C#, and C++ all follow a similar OOP strategy. It is based on function calls that are bound at compile time. Depending ont he call, either the direct function call or an offset into a vtable is fixed when compilation happens. By contrast Smalltalk's OOP is based on message passing. Conceptually every method call is a message to the receiving object asking whether it has a method called "Foo."

Smalltalk has no concept of interfaces. It only has similar looking methods. In the C++ group of languages, everything is bound to interfaces. One cannot implement AddRef and Release without also implementing QueryInterface (even if it is just a stub) because they are all part of the IUnknown interface. In Smalltalk, there is no IUnknown. There is only a collection of 3 functions, any of which could be implemented or not.

Answer 4

Java and C# are definitely not from the Smalltalk family. Alan Kay even said that when he created OOP he did not have anything like Java or C++ in mind. Java, C#, and C++ all interpret OOP in pretty much the same way.

Languages like Smalltalk and Ruby have a radically different model that is based on message passing. In C++ classes are essentially namespaces for methods and state. Method invocations are bound at compile time. Smalltalk does not bind a "method call" until runtime. The result of this is that in C++

foo->bar

is compiled to mean "call the bar method on the foo object." If bar is non virtual, I'd imagine that the address of the bar method is specifically referenced.

In Smalltalk

foo bar

means "send the message bar to the foo object." foo can do whatever it wants with this message when it arrives. The default behavior is to call the method named bar, but that is not required. This property is exploited in Ruby for ActiveRecord column accessors. When you have an ActiveRecord object and you send it the name of a column in its database table as a message, if there is no method with that name defined, it checks to see if there is a column by that name on the table and if there is returns the value.

Message passing might seem like a tiny, irrelevant detail, but out of it, the rest of OOP easily flows.

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." -- Alan Kay, creator of Smalltalk

Answer 5

Eiffel is a statically typed, compiled, multiple inheritance pure OOP language.

http://dev.eiffel.com

Answer 6

Of the modern (and I use the term lightly) OO programming languages Objective C is the most like smalltalk.

Messaages:

In C++,C# and Java: messages are bound at compile time.
You can think of a method call as a message being sent to the object.

In Objective C,Smalltalk: messages are bound at run time.

Answer 7

I'd say there is also a pretty big difference, conceptually, between class-based OOP (of which Smalltalk, Simula, C# and Java are all examples) and prototype-based OOP (which started with Self and is most widespread in JavaScript).

Answer 8

Several key 'differences in 'Style' within the broader OOP banner.

In all cases a statement about a static or dynamic type system means predominately one or the other, the issue is far from clear cut or clearly defined. Also many languages choose the blur the line between the choices so this is not a list of binary choices by any means.

Polymorphic late binding

or "what does foo.Bar(x) mean?"

1. Hierarchy of types is flattened to a specific implementation per instance (often done via a vtable) and often allowing explicit reference to the base classes implementation.
   • Conceptually you look at the most specific type that foo is at the callsite. If it has an implementation of Bar for the parameter x that is called, if not the parent of foo is chosen and the process repeated.
   • Examples: C++/Java/C#, "Simula style" is often used.
2. Pure message passing. The code in foo which handles messages 'named' "Bar" is asked to accept the x. Only the name matters, not any assumptions the call site may have had about exactly what Bar was meant to be. Contrast with the previous style in which the method in question was Bar known to be something defined on whatever was known about the type hierarchy defined at compile time (though the precise place in the hierarchy is left till runtime).
   • Examples: Objective-C/Ruby, "Smalltalk style" is often used.

1 is often used within statically typed frameworks where it is an error, checked at compile time for no such implementation to exist. Further the languages often differentiate between Bar(x) and Bar(y) if x and y are different types. This is method overloading and the resulting methods with the same name are viewed as entirely different.

2 is often used in dynamic languages (which tend to avoid method overloading) as such it is possible that, at runtime the type of foo has no 'handler' for the message named 'Bar', different languages handle this in different ways.

Both can be implemented behind the scenes in the same fashion if desired (often the default for the second, Smalltalk style is to invoke a function but this is not made a defined behaviour in all cases). Since the former method can frequently be easily implemented as simple pointer offset function calls it can, more easily, be made relatively fast. This does not mean that the other styles cannot also be made fast, but more work may be required to ensure that the greater flexibility is not compromised when doing so.

Inheritance/Reuse

or "Where do babies come from?"

1. Class based
   • Method implementations are organized into groups called classes. When implementation inheritance is desired a class is defined which extends the parent class. In this way it gains all exposed aspects of the parent (both fields and methods) and can choose to alter certain/all of those aspects but cannot remove any. You can add and update but not delete.
   • Examples: C++/Java/C# (note both SmallTalk and Simula use this)
2. Prototype based
   • Any instance of an object is simply a collection of identified methods (normally identified by name) and state in the form of (again named) fields. Whenever a new instance of this 'type' is desired an existing instance can be used to clone a new one. This new class retains a copy of the state and methods of the previous class but can then be modified to remove, add or alter existing named fields and methods.
   • Examples: Self/JavaScript

Again 1 tends to happen in static languages, 2 in dynamic though this is by no means a requirement they simply lend themselves to the style.

Interface or Class based

or "what or how?"

1. Interfaces list the methods that are required. They are a contract
   • Examples: VB6
2. Classes list methods that are required but may optionally supply their implementation
   • Examples: Simula

This is very much not a binary choice. Most class based languages allow the concept of abstract methods (ones with no implementation yet). If you have a class where all methods are abstract (called pure virtual in C++) then what the class amounts to is pretty much an interface, albeit one that may have also defined some state (fields). An true Interface should have no state (since it defines only what is possible, not how it happens.

Only older OOP languages tend to rely solely on one or the other.
VB6 has only on interfaces and have no implementation inheritance.
Simula let you declare pure virtual classes but you could instantiate them (with runtime errors on use)

Single or Multiple Inheritance

or "Who is the daddy?"

1. Single
   • Only one type can be a parent to another. In the Class based form above you can extend (take implementation from) only one type. Typically this form includes the concept of interfaces as first class aspects of the language to make up for this.
   • advantages include cleaner metadata and introspection, simpler language rules.
   • complications include making it harder to bring useful methods into scope (things like MixIns and Extension methods seek to mitigate this sort of problem)
   • Examples: C#/java
2. Multiple - you can extend multiple classes
   • advantages include certain structures are easier to model and design
   • complications include complex rules for collision resolution, especially when overloaded methods exist which could take either parent type.
   • Examples: C++/Eiffel

This question provokes considerable debate, especially as it is a key differentiator between C++'s OOP implementation and many of the modern statically typed languages perceived as possible successors like c# and java.

Mutability

or "what do you want to do to me?"

1. Mutable
   • Objects, once created can have their state changed.
2. Imutable
   • Objects, once created cannot be changed.

Frequently this is not an all or nothing it is simply a default (most commonly used OOP languages default to mutable by default). This can have a great deal of affect on how the language is structured. Many primarily functional languages which have included OOP features default the objects to have immutable state.

'Pureness' of their OOP

or "Is everything an Object?"

1. Absolutely everything in the system is viewed as an object (possibly even down to the methods themselves which are simply another kind of object and can be interacted with in the same way other objects can be).
   • Examples: SmallTalk
2. Not everything is an object, you cannot pass messages to everything (though the system might jump through hoops to make it seem like you can)
   • Examples: C++/C#/Java (see note)_

This is quite complex since techniques like auto boxing of primitives make it seem like everything is but you will find that several boundary cases exist where this 'compiler magic' is discovered and the proverbial wizard of Oz is found behind the curtain resulting is problems or errors. In languages with immutability as a default this is less likely to happen, since the key aspect of objects (that they contain both methods and state) means that things that are similar to objects but not quite have less possibility for complications.

• In regards to Java/C# the autoboxing(or in c#) system lets you treat, syntactically any variable as if it was an object but, in actuality this is not the case and this is exhibited in areas such as attempting to lock on an autoboxed object (rejected by the compiler as it would be an obvious bug).

Static or Dynamic

or "Who do you think you are?"

A far more pervasive aspect of language design and not one to get into here but the choices inherent in this decision impact many aspects of OOP as mentioned earlier.

Just aspects of the polymorphic late binding can depend on:

• The type of the object to whom the message is being passed (at compile time/run time)
• The type of the parameter(s) which are being passed (at compile time/run time)

The more dynamic a language gets the more complex these decisions tend to become but conversely the more input the language user, rather than the language designer has in the decision. Giving examples here would be some what foolhardy since statically typed languages may be modified to include dynamic aspects (like c# 4.0).