Beyond Object-Oriented Programming

The complexity of a software project affects how difficult it is to develop, implement, and maintain the project. The procedural approach, or procedural programming paradigm, might be used to create a straightforward calculator, but a bank account management system would be too difficult to develop in this way.

The object-oriented programming (OOP) paradigm, which is supported by C++, is based on breaking down entities into objects that coexist in a web of close intercommunication. Imagine a simple situation where you use the remote to switch the TV station in the real world. The remote control, the TV, and, most importantly, you, are all involved in this activity. To express real-world objects and their relationship using a programming language, we aren’t forced to use classes, class inheritance, abstract classes, interfaces, virtual functions, and so on. While not necessary, the aforementioned capabilities and concepts make the process...

Technical requirements

The g++ compiler with the -std=c++20 option is used to compile the examples throughout this chapter.

You can find the source files for this chapter at https://github.com/PacktPublishing/Expert-C-2nd-edition/tree/main/Chapter02.

An introduction to OOP and the C++ object model

When writing a book about C++, you just have to talk about OOP because a) C++ is an object-oriented language, and b) OOP is at the heart of C++, which is also known by its original name – “C with classes.” OOP is one of the many paradigms that exist in the programming world. Its main purpose is to make the life of a programmer easier by allowing them to represent everything that exists in the real world with the help of objects.

Understanding objects

The majority of the time, we work with a set of data grouped together with a name, thus creating an abstraction. When viewed separately, variables such as is_military, speed, and seats don’t make much sense. We see the information stored in the variables differently when we group them together under the term spaceship. The multiple variables that are packed together are now referred to as one object. In order to accomplish this, we employ abstraction, which...

Under the hood of inheritance and polymorphism

Inheritance and polymorphism are two of the four main principles that OOP has. The four principles are as follows:

• Abstraction
• Encapsulation
• Inheritance
• Polymorphism

We have already talked about the first two principles, and now it is time to dive deeper into the final two – inheritance and polymorphism.

Inheritance

Classes can be reused, thanks to the programming notion of inheritance. Different programming languages offer various inheritance implementations, but the underlying principle is always the same – the class relationship should answer the is-a question. For instance, Car is Vehicle; hence, we can inherit Car from Vehicle:

class Vehicle {public:
    void move();
};
class Car : public Vehicle {
public:
    Car();
// ...
};

Car now has the move() member function derived from Vehicle. The relationship between generalization and specialization...

Classical design patterns

Design patterns are powerful tools for programmers to use. They enable us to find beautiful and tried-and-true solutions to design problems. A well-known design pattern can help you when you are attempting to create the optimal layout for your classes and the relationships between them.

Reusing effective designs and architectures is made simpler by design patterns. It is easier for developers of new systems to use proven techniques when they are expressed as design patterns. Design patterns assist you in selecting design options that enhance reusability and avoiding those that do not. Even documentation and maintenance of current systems can be enhanced by design patterns. Design patterns, in other words, facilitate the creation of “correct” designs more quickly.

“Who created design patterns?” is a question you might ask, and the answer is both no one and everyone. It is no one because there is no specific person to whom we...

Design principles

You can use a variety of principles and design techniques while creating your project. While keeping the design basic is usually preferable, there are certain fundamental rules that apply to practically all projects. For instance, SOLID is composed of five principles, all of which – or parts of them – can be beneficial to a design.

SOLID stands for the following principles:

• Single responsibility
• Open-closed
• Liskov substitution
• Interface segregation
• Dependency inversion

Let’s discuss each principle with examples.

The single responsibility principle

The idea of one object and one job is what the single responsibility principle asserts. Try to simplify the functionality of your objects and the intricacy of their relationships. Even if breaking down a large object into smaller, simpler components isn’t always simple, give each object a single task. Single responsibility is a context-bound concept. It...

More UML in project design

Developers should agree upon and adhere to a shared set of standards and norms, some of which should be applicable to modeling when working on a software project. Models that use a standard notation and adhere to efficient style rules are simpler to comprehend and keep up with. These models will enhance communication both inside your team and with your partners and consumers, which will lessen the likelihood of expensive misunderstandings. By reducing the number of aesthetic options you must choose from, modeling guidelines help you save time so you can concentrate on what you do best – develop software. The first step in implementing modeling standards and rules within your company is to choose a common notation. The best one to choose is probably UML, as it depicts everything that the OOP paradigm suggests.

We have already shown the UML diagrams that depict the relationships between classes and objects, and in this part of the chapter, we will...

Summary

In this chapter, we discussed the fundamental concepts of OOP. We touched on the low-level details of classes and the compiler implementation of the C++ object model. Knowing how to design and implement classes without actually having classes helps a lot in using the classes the right way.

We also discussed the need for inheritance and tried to employ composition instead of inheritance, wherever it might be applicable. C++ supports three types of inheritance – public, private, and protected. All of these types have their applications in particular class designs. Finally, we understood the use and power of polymorphism by introducing an example that drastically increases the convenience of the client code.

We also talked about design patterns and the difference between two structural design patterns – composite and decorator.

And finally, we finished the chapter by diving into one of the advanced UML diagrams, providing a sequence diagram for our example...

Questions

1. What are the three properties of objects?
2. What’s the advantage of moving objects instead of copying them?
3. What’s the difference between aggregation and composition relations?
4. What’s the difference between private and protected inheritance?
5. List the differences between composite and decorator design patterns.
6. Draw a sequence diagram that will be based on some interaction between a student and a university.

Further reading

• Grady Booch – Object-Oriented Analysis and Design: https://www.amazon.com/Object-Oriented-Analysis-Design-Applications-3rd/dp/020189551X
• Stanley Lippman – Inside the C++ Object Model: https://www.amazon.com/Inside-Object-Model-Stanley-Lippman/dp/0201834545/ref=sr_1_1?keywords=Inside+the+C%2B%2B+Object+Model&qid
=1662479088&s=books&sr=1-1
• Martina Seidl, Marion Scholz, and Christian Huemer – UML @ Classroom: An Introduction to Object-Oriented Modeling: https://www.amazon.com/UML-Classroom-Introduction-Object-Oriented-Undergraduate/dp/3319127411