I read Object-Oriented Analysis and Design with Applications Notes written by Grady Booch. In the book there is a sentence:

There are three important parts to this definition: (1) Object-oriented programming uses objects, not algorithms, as its fundamental logical building blocks (the “part of” hierarchy we introduced in Chapter 1); (2) each object is an instance of some class; and (3) classes may be related to one another via inheritance relationships (the “is a” hierarchy we spoke of in Chapter 1). A program may appear to be object-oriented, but if any of these elements is missing, it is not an object-oriented program. Specifically, programming without inheritance is distinctly not objectoriented; that would merely be programming with abstract data types.

I want to know this is right?If we don't have inheritance' our program is not object oriented?

closed as primarily opinion-based by Nemanja Trifunovic, Doval, GlenH7, Bart van Ingen Schenau, Blrfl Jan 20 '15 at 21:25

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Plenty of languages have no concept of classes and still support OOP. This definition seems to ignore languages that are not class-based (hint: MDN calls JavaScript "object-oriented to its core" but there are no classes as of ES5, Lua explicitly supports OOP but there are no classes, etc.). – Hey Jan 20 '15 at 19:24
  • 3
    @pleasedeleteme An object is just a bundle of functions which can all access the same variables and can be passed around as a single value. – Doval Jan 20 '15 at 19:47
  • 4
    Because being object oriented is about objects, not classes. If I can attach a function to an object somehow, and call that function, and inside the body of the function some identifier exists that is a reference to the object (like self or this), I would consider that to be enough for OOP. – Hey Jan 20 '15 at 19:47
  • 1
    @pleasedeleteme I think of the three things that author lists, only #1 is accurate. I think OOP is about being able to get a reference to the object to which a function is attached from within the function without having to explicitly pass that reference in (or you could bypass the reference and allow non-lexically scoped identifiers to access the rest of the members of that object, like some class-based languages allow). That's just my opinion, but I don't see how this definition could be accurate given languages that are commonly accepted as supporting OOP but don't have classes. – Hey Jan 20 '15 at 20:10
  • 1
    It says it "may" be, not that it is. If you look at the design of Java and C#, every object you have inherits from the base object class, so even though you may not have explicitly use inheritance, some inheritance is happening. – ravibhagw Jan 20 '15 at 21:01

If we don't have inheritance our program is not object oriented?

Umm, no.

I expect that a majority of programmers would still consider a program with traditional objects (bundles of related state and functions) as objected oriented, even if there is no inheritance. In the past handful of years, it has become widely accepted that inheritance of concrete objects is something to be used cautiously if not avoided outright.

Regardless, you're asking about terminology. There's no rules for what Object Oriented is really. It's a name used loosely to help communicate concepts; concepts that are decreasingly useful in helping programmers solve problems.

  • If you want to get really pedantic, then like Booch says, Java/C# classes - especially without implementation inheritance - correspond to abstract data types, not objects. You can do this kind of abstract data type-oriented programming in C with pointers to incomplete types (see: pretty much every C API). Java/C# interfaces are objects, and you can "inherit" interfaces (and interfaces can inherit other interfaces), but Booch's quote gives the impression that he's talking specifically about implementation inheritance. – Doval Jan 20 '15 at 19:19
  • 3
    If you're doing it right, the vast majority of the time you are not using inheritance (unless you want to count the inheritance that, say, the .NET Framework does under the hood for Stream objects, for example). – Robert Harvey Jan 20 '15 at 19:25
  • 2
    @Doval I'd phrase it as “OOP is not about inheritance, but about subtyping”. Or more precisely, OOP (the theoretical concept) is about dynamic dispatch. The big advantages of OOP (the practical design paradigm) are not a result of this, but rather that OOP subsumes modular programming as a paradigm and encourages a data-oriented view. – amon Jan 20 '15 at 20:18
  • @amon Not so sure about the modular programming bit, since objects (i.e. interfaces) can only expose the "lowest common denominator" shared by its implementations and can't make any assumptions about their implementation. For example, an interface for custom numeric types is almost useless because the basic operations on numbers takes two arguments and there's no guarantee that two INumbers have the same implementation. – Doval Jan 20 '15 at 20:36

Alan Kay, who coined the phrase object-oriented programming has remarked here and in other places, that object-oriented programming is more about messages than objects. The key is that programs are designed as a set of objects that communicate through messages (in many languages a message is referred to as a polymorphic method call).

In Smalltalk (the language Alan Kay was working on) when a message is sent to an object, the receiver of the object determines how the object will respond. In a class-based language, the typical behaviour is:

  1. Check if the object has a method matching the message's signature, if so invoke that.
  2. Otherwise, check (recursively) if any of the object's base classes contains a method matching the method signature. When a class inherits another class, it means that the methods of the base class are available for object's of the derived class, but may be overridden to provide different behaviour.

However, other languages such as Self and JavaScript, objects are not instance of classes. In place of inheritance, a pattern known as delegation is used. When a object receives a message it does not understand, it can delegate its response to another object known as a prototype.

In all the languages mentioned so far, unlike most mainstream languages such as Java, C++ and C#, any object can implement a message for any message. C++ derived a different (and more restrictive) model from Simula, where a message is defined on a base class and can be overridden by a derived class, but no other classes can respond to the method.

Self demonstrated, by including in images a Smalltalk subsystem, that using the prototype-based model a class-based model can be implemented as a pattern of programming, so in this sense the prototype-based model is more descriptive. The converse would require implementing a new object system from scratch (e.g. a class called PrototypicalObject, with behaviour entirely distinct from normal Smalltalk objects).

At its core, OOP is about objects and messages (method calls), where various objects can implement different responses to the same message. The details of inheritance and delegation can help create those objects, but are simply variants of the standard model.


Inheritance is another form of containment even if the inheritance is interface implementation. Without leveraging inheritance, you lose a lot of the strength of object-oriented programming.

Inheritance allows you to substitute implementations of a class without impacting the client of the class. Think of a UI framework (like MFC or WPF). A lot of the framework depends on the fact that a Button, TextBox, Label, and Combobox are all subclasses of the same base class Control. If there weren't this common interface or base class, there would be a huge proliferation of code to do the same thing for the specific instances of these classes.

In that case you might as well be using basic C.

  • 4
    Inheritance allows you to substitute implementations of a class without impacting the client of the class. You can do that in C trivially. The real trick is that the client can add a new subclass without relying on the class's author. – Doval Jan 20 '15 at 19:30

Most OO principles depend on inheritance, abstraction and interfaces. So inheritance and interface implementation plays major role in object oriented software design.

You may want to read about SOLID and other object oriented design principles.

Of course it is possible to write programs in object oriented languages without using inheritance (and more specifically interfaces and specializations of those interfaces) but you will end up with more tightly coupled code.

  • 1
    We don't talk about design. – user78203 Jan 20 '15 at 19:45
  • 1
    Well... yes we do. OOP involve analysis and design (as well as all known paradigms) and the source code is the implementation of that design. – Lyuben Blagoev Jan 20 '15 at 19:50
  • Yes but completely different. – user78203 Jan 20 '15 at 19:52
  • 3
    Why different? Those are the decisions that you make before writting any piece of code. Object orientation comes with principles, pattens and different way of thinking than procedural and functional programming. If you use OO language but don't change your way of thinkng and the way you use it to attack problems, and you continue to use the same style of programming that you use when using procedural programming language then you are not writting object oriented code at all. – Lyuben Blagoev Jan 20 '15 at 20:03
  • 2
    "...but you will end up with more tightly coupled code" - I guess in lots of cases where inheritance is used, one would end up with less tightly coupled code by avoiding inheritance. That's because inheritance is often used, lets say, in a suboptimal way. – Doc Brown Jan 20 '15 at 22:02