window.pipedriveLeadboosterConfig = { base: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(function () { var w = window if (w.LeadBooster) { console.warn('LeadBooster already exists') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() TO HAVE OR TO BE? - The Codest
The Codest
  • About us
  • Services
    • Software Development
      • Frontend Development
      • Backend Development
    • Staff Augmentation
      • Frontend Developers
      • Backend Developers
      • Data Engineers
      • Cloud Engineers
      • QA Engineers
      • Other
    • It Advisory
      • Audit & Consulting
  • Industries
    • Fintech & Banking
    • E-commerce
    • Adtech
    • Healthtech
    • Manufacturing
    • Logistics
    • Automotive
    • IOT
  • Value for
    • CEO
    • CTO
    • Delivery Manager
  • Our team
  • Case Studies
  • Know How
    • Blog
    • Meetups
    • Webinars
    • Resources
Careers Get in touch
  • About us
  • Services
    • Software Development
      • Frontend Development
      • Backend Development
    • Staff Augmentation
      • Frontend Developers
      • Backend Developers
      • Data Engineers
      • Cloud Engineers
      • QA Engineers
      • Other
    • It Advisory
      • Audit & Consulting
  • Value for
    • CEO
    • CTO
    • Delivery Manager
  • Our team
  • Case Studies
  • Know How
    • Blog
    • Meetups
    • Webinars
    • Resources
Careers Get in touch
Back arrow GO BACK
2016-09-10
Software Development

TO HAVE OR TO BE?

Katarzyna Jaruga

While learning object-oriented programming, and after mastering the basics of objects, fields and methods, one spends most of the time on inheritance. Inheritance means that we acquire some part of the implementation from a base class. You just have to create a subclass of a base class i order to inherit every non-private field and method.

A car and a plane are vehicles so it is obvious that both of these classes should be expanded from their common base class called Vehicle. This is a typical academic example but while deciding about binding these classes with the inheritance relation, we should be aware of some consequences.

Fig. 1 Implementation of inheritance relation.

In this case the classes are closely linked to each other – this means that the changes in the behavior of every class can be achieved by making changes to the base class code. This can be an advantage as well as disadvantage – it depends on what kind of behavior we expect. If the inheritance is applied at the wrong time, the process of adding a new function may encounter some implementation difficulties because it won’t fit the created class model. We will have to choose between duplicating the code and reorganizing our model – and it can be a really time-consuming process. We can call the code that executes the inheritance relation as “open-closed” -this means that it is open for extensions but closed for modification. Assuming that in the Vehicle class there is a general, defined engine operation, of every vehicle, the moment we’d want to add an engineless vehicle (e.g. bike) model to our class hierarchy, we’d have to make some serious changes to our classes.

class Vehicle
  def start_engine
  end

  def stop_engine
  end
end

class Plane < Vehicle
  def move
    start_engine
    …
    stop_engine
  end
end

Composition

If we’re only interested in some part of the behavior of the existing class, a good alternative for inheritance is to use composition. Instead of creating subclasses that inherit every behavior (the ones we need and the ones we don’t need at all), we can isolate the functions we need, and equip our objects in references to them. In such a way, we give up the thought that object is a type of a base object, in favor of the assertion that it contains only some parts of its properties.

Fig. 2 Using the composition

Following this approach we can isolate the code that is responsible for the engine operation to the autonomous class called Engine and place reference to it only in the classes that represent vehicles with engines. Isolating the functions with the use of composition will make the Vehicle class structure simpler and will strengthen the encapsulation of individual classes. Now, the only way the vehicles can have an effect on the engine is to use its public interface, because they won’t have information about its implementation no more. What’s more, it will allow to use different types of engines in different vehicles, and even allow their exchange while the program is running. Of course, using composition is not flawless – we are creating a loosely connected class set, which can be easily extended and is open for modification. But, at the same time, each class is connected to many other classes, and must have information regarding their interfaces.

class Vehicle
end

class Engine
  def start
  end

  def stop
  end
end

class Plane < Vehicle
  def initialize
    @engine = Engine.new
  end

  def move
    @engine.start
    @engine.stop
  end

  def change_engine(new_engine)
    @engine = new_engine
  end
end

The choice

Both described approaches have advantages and disadvantages, so how to choose between them? Inheritance is a specialization, so it’s best to apply them only for problems, in which there are “is-a” type relations – so we deal with the real hierarchy of types. Because inheritance tightly links classes together, firstly, we should always consider whether to use composition or not. Composition should be applied for problems in which there are “has-a” type relations – so the class has many parts but it is something more than a set of classes. A plane consists of parts but alone it is something more – it has additional abilities, such as flight. Going further with this example, individual parts can occur in different specialist variants, and then it is a good moment to use inheritance.

Inheritance as well as composition are only tools that the programmers have at their disposal, so choosing the right tool for a particular problem requires experience. So let’s practice and learn from our mistakes 🙂

Related articles

Software Development

Build Future-Proof Web Apps: Insights from The Codest’s Expert Team

Discover how The Codest excels in creating scalable, interactive web applications with cutting-edge technologies, delivering seamless user experiences across all platforms. Learn how our expertise drives digital transformation and business...

THECODEST
Software Development

Top 10 Latvia-Based Software Development Companies

Learn about Latvia's top software development companies and their innovative solutions in our latest article. Discover how these tech leaders can help elevate your business.

thecodest
Enterprise & Scaleups Solutions

Java Software Development Essentials: A Guide to Outsourcing Successfully

Explore this essential guide on successfully outsourcing Java software development to enhance efficiency, access expertise, and drive project success with The Codest.

thecodest
Software Development

The Ultimate Guide to Outsourcing in Poland

The surge in outsourcing in Poland is driven by economic, educational, and technological advancements, fostering IT growth and a business-friendly climate.

TheCodest
Enterprise & Scaleups Solutions

The Complete Guide to IT Audit Tools and Techniques

IT audits ensure secure, efficient, and compliant systems. Learn more about their importance by reading the full article.

The Codest
Jakub Jakubowicz CTO & Co-Founder

Subscribe to our knowledge base and stay up to date on the expertise from the IT sector.

    About us

    The Codest – International software development company with tech hubs in Poland.

    United Kingdom - Headquarters

    • Office 303B, 182-184 High Street North E6 2JA
      London, England

    Poland - Local Tech Hubs

    • Fabryczna Office Park, Aleja
      Pokoju 18, 31-564 Kraków
    • Brain Embassy, Konstruktorska
      11, 02-673 Warsaw, Poland

      The Codest

    • Home
    • About us
    • Services
    • Case Studies
    • Know How
    • Careers
    • Dictionary

      Services

    • It Advisory
    • Software Development
    • Backend Development
    • Frontend Development
    • Staff Augmentation
    • Backend Developers
    • Cloud Engineers
    • Data Engineers
    • Other
    • QA Engineers

      Resources

    • Facts and Myths about Cooperating with External Software Development Partner
    • From the USA to Europe: Why do American startups decide to relocate to Europe
    • Tech Offshore Development Hubs Comparison: Tech Offshore Europe (Poland), ASEAN (Philippines), Eurasia (Turkey)
    • What are the top CTOs and CIOs Challenges?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Copyright © 2025 by The Codest. All rights reserved.

    en_USEnglish
    de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek en_USEnglish