The Codest
  • O nás
  • Služby
    • Vývoj softwaru
      • Vývoj frontendů
      • Vývoj backendu
    • Staff Augmentation
      • Vývojáři frontendů
      • Vývojáři backendu
      • Datoví inženýři
      • Cloudoví inženýři
      • Inženýři QA
      • Další
    • To Advisory
      • Audit a poradenství
  • Odvětví
    • Fintech a bankovnictví
    • E-commerce
    • Adtech
    • Healthtech
    • Výroba
    • Logistika
    • Automobilový průmysl
    • IOT
  • Hodnota za
    • CEO
    • CTO
    • Manažer dodávek
  • Náš tým
  • Case Studies
  • Vědět jak
    • Blog
    • Setkání
    • Webové semináře
    • Zdroje
Kariéra Spojte se s námi
  • O nás
  • Služby
    • Vývoj softwaru
      • Vývoj frontendů
      • Vývoj backendu
    • Staff Augmentation
      • Vývojáři frontendů
      • Vývojáři backendu
      • Datoví inženýři
      • Cloudoví inženýři
      • Inženýři QA
      • Další
    • To Advisory
      • Audit a poradenství
  • Hodnota za
    • CEO
    • CTO
    • Manažer dodávek
  • Náš tým
  • Case Studies
  • Vědět jak
    • Blog
    • Setkání
    • Webové semináře
    • Zdroje
Kariéra Spojte se s námi
Šipka zpět ZPĚT
2016-09-10
Vývoj softwaru

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 kód. 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 🙂

Související články

Ilustrace zdravotnické aplikace pro chytré telefony s ikonou srdce a rostoucím zdravotním grafem, označená logem The Codest, která představuje digitální zdraví a řešení HealthTech.
Vývoj softwaru

Softwarové vybavení pro zdravotnictví: a případy použití

Nástroje, na které se dnes zdravotnické organizace spoléhají, se v ničem nepodobají papírovým kartám z doby před desítkami let. zdravotnický software dnes podporuje zdravotnické systémy, péči o pacienty a moderní poskytování zdravotní péče v klinických a...

NEJKRÁSNĚJŠÍ
Abstraktní ilustrace klesajícího sloupcového grafu se stoupající šipkou a zlatou mincí symbolizující efektivitu nákladů nebo úspory. V levém horním rohu se zobrazuje logo The Codest se sloganem "In Code We Trust" na světle šedém pozadí.
Vývoj softwaru

Jak rozšířit tým vývojářů bez ztráty kvality produktu

Zvětšujete svůj vývojový tým? Zjistěte, jak růst, aniž byste museli obětovat kvalitu produktu. Tento průvodce se zabývá příznaky, že je čas na škálování, strukturou týmu, najímáním zaměstnanců, vedením a nástroji - a také tím, jak může The Codest...

NEJKRÁSNĚJŠÍ
Vývoj softwaru

Vytváření webových aplikací odolných vůči budoucnosti: postřehy týmu odborníků The Codest

Zjistěte, jak společnost The Codest vyniká při vytváření škálovatelných, interaktivních webových aplikací pomocí nejmodernějších technologií, které poskytují bezproblémové uživatelské prostředí na všech platformách. Zjistěte, jak naše odborné znalosti podporují digitální transformaci a obchodní...

NEJKRÁSNĚJŠÍ
Vývoj softwaru

10 nejlepších lotyšských společností zabývajících se vývojem softwaru

V našem nejnovějším článku se dozvíte o nejlepších lotyšských společnostech zabývajících se vývojem softwaru a jejich inovativních řešeních. Zjistěte, jak mohou tito technologičtí lídři pomoci pozvednout vaše podnikání.

thecodest
Podniková a škálovací řešení

Základy vývoje softwaru v jazyce Java: A Guide to Outsourcing Successfully

Prozkoumejte tuto základní příručku o úspěšném vývoji softwaru outsourcing Java, abyste zvýšili efektivitu, získali přístup k odborným znalostem a dosáhli úspěchu projektu s The Codest.

thecodest

Přihlaste se k odběru naší znalostní databáze a získejte aktuální informace o odborných znalostech z oblasti IT.

    O nás

    The Codest - Mezinárodní společnost zabývající se vývojem softwaru s technologickými centry v Polsku.

    Spojené království - ústředí

    • Kancelář 303B, 182-184 High Street North E6 2JA
      Londýn, Anglie

    Polsko - Místní technologická centra

    • Kancelářský park Fabryczna, Aleja
      Pokoju 18, 31-564 Krakov
    • Brain Embassy, Konstruktorska
      11, 02-673 Varšava, Polsko

      The Codest

    • Home
    • O nás
    • Služby
    • Case Studies
    • Vědět jak
    • Kariéra
    • Slovník

      Služby

    • To Advisory
    • Vývoj softwaru
    • Vývoj backendu
    • Vývoj frontendů
    • Staff Augmentation
    • Vývojáři backendu
    • Cloudoví inženýři
    • Datoví inženýři
    • Další
    • Inženýři QA

      Zdroje

    • Fakta a mýty o spolupráci s externím partnerem pro vývoj softwaru
    • Z USA do Evropy: Proč se americké startupy rozhodly přesídlit do Evropy?
    • Srovnání technických vývojových center v zahraničí: Tech Offshore Evropa (Polsko), ASEAN (Filipíny), Eurasie (Turecko)
    • Jaké jsou hlavní výzvy CTO a CIO?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Copyright © 2026 by The Codest. Všechna práva vyhrazena.

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