Object-oriented programming is one such paradigm, where the code is organized as objects.

It is used to develop desktop and mobile applications or more complex web or enterprise applications.

Using object-oriented programming, you can build modular and scalable software that is easy to maintain.

In this article, you will learn about the principles of object-oriented Programming that lay the foundation for building robust systems.

We will use Java as the programming language for the examples provided below.

What is Object-Oriented Programming?

Object-Oriented Programming is a programming methodology that models real-world entities in the form of objects.

These objects are instances of classes.

A class can be thought of as a blueprint and each class can contain fields, which define the attributes of the object, and methods, which describe the object's behavior. Each class can be developed, tested, and debugged independently.

Now that you have an understanding of the basic definition of object-oriented programming, let us jump right in and learn about its core principles.

There are four core principles, or pillars, in the object-oriented Programming paradigm. They are:

• Abstraction
• Encapsulation
• Inheritance
• Polymorphism

What do they mean? Let us explore further with a simple explanation followed by an example for each of them in the following sections.

What is Abstraction?

Abstraction is defined as the concept of hiding the details of implementation and exposing only the necessary functionalities of the object to the user.

The keywords that you need to keep in mind here are: 'Implementation hiding'.

Abstraction in Java can be achieved through Interfaces and Abstract classes.

abstract class Animal {
    public abstract void makeSomeNoise();
}

class Dog extends Animal {
    public void makeSomeNoise() {
        System.out.println("Bark");
    }
}

public class Main {
    public static void main(String[] args) {
        Dog myDog = new Dog();
        myDog.makeSomeNoise(); // Output - Bark
    }
}

In the above example, abstraction is achieved with the help of an abstract class named Animal.

Here, only the necessary functionality of the class is exposed via the makeSomeNoise() method.

The details of implementation are hidden in the abstract class and they are only provided in the concrete class Dog, which extends the Animal class.

Note that you will learn more about the extends keyword while we discuss Inheritance.

What is Encapsulation?

Encapsulation refers to the concept of encapsulating or wrapping up the member variables (data) and the methods (behavior) of an object into a single unit, such as a class.

The internal information of the object is hidden so that we can prevent unintended modifications and allow only controlled access. The keywords that you need to keep in mind here are: 'Information hiding'.

Encapsulation in Java is achieved through access modifiers. We mark the fields as private and make them accessible via public setter and getter methods.

public class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    public void display() {
        System.out.println("Name: " + name + ", Age: " + age);
    }
}

public class Main {
    public static void main(String[] args) {
        Person person = new Person("Raj", 30);
        person.display(); // Output - Name: Raj, Age: 30

        person.setName("Kumar");
        person.setAge(25);
        person.display(); // Output - Name: Kumar, Age: 25
    }
}

In the above example, the fields and methods are encapsulated within a class named Person.

You declare the fields name and age as private and provide public setter and getter methods getName(), setName(), getAge(), and setAge() to modify the values as needed.

What is Inheritance?

Inheritance establishes a hierarchical relationship between two classes.

In this concept, one class inherits the fields (properties) and methods (behavior) of another class, while having properties and behavior of its own.

The class that inherits from another is called a subclass, derived class, or child class. The class from which the subclass inherits is known as the superclass, base class, or parent class.

In Java, inheritance is achieved using the extends keyword.

class Animal {
    public void makeSomeNoise(){
        System.out.println("Make some animal noise");
    }
}

class Dog extends Animal {
    public void makeSomeNoise() {
        System.out.println("Bark");
    }
    public void doSomething(){
        System.out.println("Play with ball");
    }
}

public class Main {
    public static void main(String[] args) {
        Dog myDog = new Dog();
        myDog.makeSomeNoise(); // Output - Bark
        myDog.doSomething(); // Output - Play with ball
    }
}

In the above example, the extends keyword indicates that the Dog class is the subclass of the Animal class.

The Dog class inherits the makeSomeNoise() method from the Animal class. This allows the Dog class to reuse the method and provide its own implementation without having to rewrite it completely.

You can also note that the Dog class has its own behavior through the doSomething() method.

Inheritance defines an "IS-A" relationship between the two classes. In our example, Dog IS-A Animal.

Note that Java supports multi-level inheritance. For example, class Labrador inherits from class Dog, which in turn inherits from class Animal. However, it does not support multiple inheritance. That is, a class is not allowed to inherit from two or more parent classes.

What is Polymorphism?

Poly (many), morph (forms).

Polymorphism defines the capability of an object to be represented in different forms.

In Java, polymorphism can be categorized into two types: compile-time polymorphism and runtime polymorphism.

Compile-time polymorphism is achieved through method overloading – multiple methods have the same name but different type or number of parameters.

class MathOperation {
    public int add(int a, int b) {
        return a + b;
    }

    public int add(int a, int b, int c) {
        return a + b + c;
    }
}

public class Main {
    public static void main(String[] args) {
        MathOperation math = new MathOperation();
        System.out.println(math.add(95, 5));       // Output - 100
        System.out.println(math.add(75, 5, 20));   // Output - 100
    }
}

In the above example, we have overloaded the add() method. There are two methods with the same name add but they have different number of parameters.

During compilation, based on the number of parameters passed to the method, the appropriate call is made.

Runtime polymorphism is achieved through method overriding – a subclass has a method with the same name and same set of parameters as that of its superclass method. However, it provides its own implementation of the method.

Here, the method resolution happens at runtime.

class Animal {
    public void makeSomeNoise() {
        System.out.println("Make some animal noise");
    }
}

class Dog extends Animal {
    @Override
    public void makeSomeNoise() {
        System.out.println("Barks");
    }
}

class Cat extends Animal {
    @Override
    public void makeSomeNoise() {
        System.out.println("Meows");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal myAnimal; 

        myAnimal = new Dog(); 
        myAnimal.makeSomeNoise(); // Output - Barks

        myAnimal = new Cat(); 
        myAnimal.makeSomeNoise(); // Output - Meows
    }
}

In the above example, the makeSomeNoise() method of the Animal class is overridden by the Dog and Cat subclasses and they provide their own implementation of this method.

During object creation, the Animal variable holds a Dog or Cat object and when the makeSomeNoise() method is called, the appropriate overridden method is called based on the actual object type.

Conclusion

In this article, we explored the fundamental principles of Object-Oriented Programming (OOP).

Familiarity with these concepts is crucial for building robust, maintainable, and scalable software systems.

Other pillars of object-oriented programming include encapsulation, polymorphism, and abstraction.

In this article, we will learn about inheritance in C# and the various types of inheritance we have in OOP.

What is Inheritance?

Inheritance is one of the key features of object-oriented programming (OOP). It is simply the process by which one class (the child or derived class) acquires the properties, methods, and fields of another class (the base, parent, or super class).

Inheritance in object-oriented programming means that you're creating classes that can pass down their properties to other classes without having to explicitly define the properties in new classes.

Inheritance does not only ensure the reusability of the codebase, but it also reduces your code’s complexity.

Types of Inheritance in C

Inheritance allows you to build families of related classes. The base/parent class defines the common data for the child class to inherit it. You use the colon operator (:) to show inheritance between two classes.

using System;

namespace LearningInheritance
{
    class ParentClass
    {
        //...
    }
    class ChildClass:ParentClass
    {
        //..
    }
}

There are different types of inheritance in C#. We'll discuss them now.

Single Inheritance in C

Single inheritance usually occurs between two classes – the base class, and the derived class. It occurs when a class is inherited from a single-parent class.

Below is a code sample that shows single inheritance in C#:

using System;

namespace LearningInheritance
{
    class ParentClass
    {
        public string name;
        public int Id = 9;

        public void displayParentClassDetails()
        {
            Console.WriteLine($"I am {name}");
            Console.WriteLine($"ID : {Id}");
        }
    }

    class ChildClass : ParentClass
    {
        public void getIdFromParentClass()
        {
            Console.WriteLine($"This is my ID : {Id}");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            //accessing the inherited members from the child class
            ChildClass child = new ChildClass();
            child.getIdFromParentClass();
        }
    }
}

In the above code, we derived a subclass (ChildClass) from a super class (ParentClass). The ChildClass now has access to the fields and properties of the ParentClass through inheritance. We could easily access the inherited members from the ChildClass as seen above.

Hierarchical Inheritance in C

Hierarchical inheritance occurs when more than one derived class is created from a single-parent class.

namespace LearningInheritance
{
    class ParentClass
    {
        public string name;
        public int Id = 9;

        public void displayParentClassDetails()
        {
            Console.WriteLine($"I am {name}");
            Console.WriteLine($"ID : {Id}");
        }
    }

    class ChildClass : ParentClass
    {
        public void getIdFromParentClass()
        {
            Console.WriteLine("Displaying from my Child Class");
            Console.WriteLine($"This is my ID : {Id}.");
        }
    }

    class AnotherChildClass : ParentClass
    {
        public void getIdFromParentClass()
        {
            Console.WriteLine("Displaying from my other Child Class");
            Console.WriteLine($"This is my ID : {Id}");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            //accessing the inherited members in the parent class (from the child class)
            ChildClass child = new ChildClass();
            child.getIdFromParentClass();

            //accessing the inherited members in the parent class (from the other child class)
            AnotherChildClass anotherChild = new AnotherChildClass();
            anotherChild.getIdFromParentClass();
        }
    }
}

In the above code, we showed that we can derive more than one child class from a single parent class.

The ChildClass and AnotherChildClass both inherit the fields and methods of the base class, ParentClass. This is called Hierarchical inheritance. The two child classes can therefore access the fields and methods of the parent class.

Multi-level Inheritance in C

Multi-level inheritance occurs when a class is derived from another derived class. It is simply a situation where a derived class is created and used as a base class for another class.

namespace LearningInheritance
{
    class ParentClass
    {
        public string name;
        public int Id = 9;

        //...
    }

    class ChildClass : ParentClass
    {
        //...
        //The Child class is the derived class in this case
    }

    class ThirdClass : ChildClass
    {
        //...
        //The ChildClass is the base class for the ThirdClass
    }

    class Program
    {
        static void Main(string[] args)
        {
            //...
        }
    }
}

In the above code, we also derived a subclass (ChildClass) from a super class (ParentClass). The ChildClass then acts as a base class for a sub-child class which was named ThirdClass.

Multiple Inheritances – Interfaces in C

Multiple inheritances are not supported in C#. But you can achieve it by using interfaces.

Multiple inheritances allow a derived class to be inherited from multiple parent classes. You can see an example of how a child class can inherit from multiple interfaces that act like a parent class below:

namespace LearningInheritance
{    
    class Program
    {
        interface InterfaceA
        {
            //...
        }

        interface InterfaceB
        {
            //...
        }     

        class NewClass: InterfaceA, InterfaceB
        {
            //...            
        }

        static void Main(string[] args)
        {
            //...
        }
    }
}

Conclusion

Inheritance is important because it helps keep your code clean. It makes it easier to build families of related classes. The child class can inherit all the fields, properties, and methods that are contained in the parent class except those classes that are declared as a private class.

Through this article, I hope you have gained some insight about inheritance in C#.

Happy Coding.

Over the past few decades, many programming languages have risen in popularity. You can see how popular languages are ranked in this real time ranking chart here.

While new languages are being created, existing ones are always being updated to make them better.

Although most programming languages have some similarities, each one has specific rules and methods which makes it unique.

One concept that is common among many programming languages is Object Oriented Programming.

When I first came across this term, it was a bit confusing. It took me some time to really understand it's importance in programming. But this also doubled as an opportunity for me to learn its key concepts, and know how important it is for a developer's career and being able to solve challenges.

In this article we will go over Object Oriented Programming (OOP) as a whole, without relying on a particular language. You'll learn what it is, why it's so popular as a programming paradigm, its structure, how it works, its principles, and more.

Let's get started.

What is Object-Oriented Programming?

If you were to conduct a fast internet search on what object-oriented programming is, you'll find that OOP is defined as a programming paradigm that relies on the concept of classes and objects.

Now, for a beginner, that might be a little bit confusing – but no need to worry. I will try to explain it in a simplest way possible, just like the famous phrase "Explain it to me like I'm 5".

Here's a brief overview of what you can achieve with OOP: you can use it to structure a software program into simple, reusable code blocks (in this case usually called classes), which you then use to create individual instances of the objects.

So let's find an easier definition of object-oriented programming and learn more about it.

Explain OOP Like I'm 5

The word object-oriented is a combination of two terms, object and oriented.

The dictionary meaning of an object is "an entity that exists in the real world", and oriented means "interested in a particular kind of thing or entity".

In basic terms, OOP is a programming pattern that is built around objects or entities, so it's called object-oriented programming.

To better understand the concept, let's have a look at commonly used software programs: A good example to explain this would be the use of a printer when you are printing a document.

The first step is initiating the action by clicking on the print command or using keyboard shortcuts. Next you need to select your printer. Afterwards you will wait for a response telling you if the document was printed or not.

Behind what we can't see, the command you clicked interacts with an object (printer) to accomplish the task of printing.

Perhaps you might wonder, how exactly did OOP become so popular?

How OOP Became Popular

The concepts of OOP started to surface back in the 60s with a programming language called Simula. Even though back in the day, developers didn't completely embrace the first advances in OOP languages, the methodologies continued to evolve.

Fast forward to the 80s, and an editorial written by David Robinson was one of the first introductions to OOP, as many developers didn't know it existed.

By now languages like C++ and Eiffel had become more popular and mainstream among computer programmers. The recognition continued to grow during the 90s, and with the arrival of Java, OOP attracted a huge following.

In 2002 in conjunction with the release of the .NET Framework, Microsoft introduced a brand new OOP language called C# – which is often described as the most powerful programming language

It's interesting that, generations later, the concept of organizing your code into meaningful objects that model the parts of your problem continues to puzzle programmers.

Many folks who haven't any idea how a computer works find the thought of object-oriented programming quite natural. In contrast, many folks who have experience with computers initially think there's something strange about object oriented systems.

Structure of OOP

Imagine that you are running a pet shop, with lots of different breeds and you have to keep track of the names, age, days attended to, and other common upkeep details. How would you design reusable software to handle this?

Keep in mind we have many breeds, so writing code for each would be tiresome. But we can group related information together so that we can produce shorter and more reusable code.

That's where the building blocks come in to help us do this by using Classes, Objects, Methods and Attributes.

Let's take a deep dive and understand what exactly these building blocks are:

• Classes - these are user-defined data types that act as the blueprint for objects, attributes, and methods.

• Objects - These are instances of a class with specifically defined data. When a class is defined initially, the description is the only object that is defined.

• Methods - These are functions that are defined inside a class that describe the behavior of an object. They are useful for re-usability or keeping functionality encapsulated inside one object at a time. Code re-usability is a great benefit when debugging.

• Attributes - These are defined in the class template and represent the state of an object. Objects contain data stored in the attribute field.

Principles of OOP

In order for us to know how to write good OOP code, we need to understand the 4 pillars of OOP we should adhere to:

• Encapsulation
• Abstraction
• Inheritance
• Polymorphism

Let's dive in and better understand what exactly each of these mean.

Encapsulation

This is the concept that binds data together. Functions manipulate the info and keep it safe. No direct access is granted to the info in case it's hidden. If you wish to gain access to the info, you need to interact with the article in charge of the info.

If you're employed in a company, chances are high that you've had experience with encapsulation.

Think about a human resources department. The human resources staff members encapsulate (hide) the data about employees. They determine how this data will be used and manipulated. Any request for the worker data or request to update the info must be routed through them.

By encapsulating data, you make the information of your system safer and more reliable. You're also able monitor how the information is being accessed and what operations are performed on it. This makes program maintenance easier and simplifies the debugging process.

Abstraction

Abstraction refers to using simple classes to represent complexity. Basically, we use abstraction to handle complexity by allowing the user to only see relevant and useful information.

A good example to explain this is driving an automatic car. When you have an automatic car and want to get from point A to point B, all you need to do is give it the destination and start the car. Then it'll drive you to your destination.

What you don't need to know is how the car is made, how it correctly takes and follows instructions, how the car filters out different options to find the best route, and so on.

The same concept is applied when constructing OOP applications. You do this by hiding details that aren't necessary for the user to see. Abstraction makes it easier and enables you to handle your projects in small, managable parts.

Inheritance

Inheritance allows classes to inherit features of other classes. As an example, you could classify all cats together as having certain common characteristics, like having four legs. Their breeds further classify them into subgroups with common attributes, like size and color.

You use inheritance in OOP to classify the objects in your programs per common characteristics and performance. This makes working with the objects and programming easier, because it enables you to mix general characteristics into a parent object and inherit these characteristics within the child objects.

For example, you'll define an employee object that defines all the overall characteristics of employees in your company.

You'll be able to then define a manager object that inherits the characteristics of the employee object but also adds characteristics unique to managers in your company. The manager object will automatically reflect any changes within the implementation of the employee object.

Polymorphism

This is the power of two different objects to reply to one form. The program will determine which usage is critical for every execution of the thing from the parent class which reduces code duplication. It also allows different kinds of objects to interact with the same interface.

Examples of OOP Languages

Technology and programming languages are evolving all the time. We have seen the rise of may langs under the OOP category, but Simula is credited as the first OOP language.

Programming languages that are considered pure OOP treat everything like objects, while the others are designed primarily with some procedural process.

Examples of OOP langs:

• Scala
• Emerald
• Ruby
• JADE
• Java
• Python
• C++
• JavaScript
• Visual Basic .NET
• PHP

And many more.

Benefits of OOP

During the 70s and 80s, procedural-oriented programming languages such as C and Pascal were widely used to develop business-oriented software systems. But as the programs performed more complex business functionality and interacted with other systems, the shortcomings of structural programming methodology began to surface.

Because of this, many software developers turned to object-oriented methodologies and programming languages to solve the encountered problems. The benefits of using this languages included the following:

• Code Re-usability - through inheritance, you can reuse code. This means a team does not have to write the same code multiple times.

• Improved integration with modern operating systems.

• Improved Productivity - developers can construct new programs easily and quickly through the use of multiple libraries.

• Polymorphism enables a single function to adapt to the class it is placed in.

• Easy to upgrade, and programmers can also implement system functionalities independently.

• Through Encapsulation objects can be self-contained. It also makes troubleshooting and collaboration on development easier.

• By the use of encapsulation and abstraction, complex code is hidden, software maintenance is easier, and internet protocols are protected.

Wrapping Up

Today, most languages allow developers to mix programming paradigms. This is often because they will be used for various programming methods.

For instance, take JavaScript – you can use it for both OOP and functional programming. When you're coding object-oriented JS, you have to think carefully about the structure of the program and plan at the start of coding. You might do this by viewing how you'll be able to break the necessities into simple, reusable classes which will be accustomed blueprint instances of objects.

Developers working with OOP typically agree that in general, using it allows for better data structures and re-usability of code. This saves time in the long term.

That's what the four pillars are. They're software design principles to help you write clean Object-Orientated code.

The four pillars of object-oriented programming are:

• Abstraction
• Encapsulation
• Inheritance
• Polymorphism

Let's take a closer look at each of them.

Abstraction in Object-Oriented Programming

To abstract something away means to hide away the implementation details inside something – sometimes a prototype, sometimes a function. So when you call the function you don't have to understand exactly what it is doing.

If you had to understand every single function in a big codebase you would never code anything. It would take months to finish reading through it all.

You can create a reusable, simple to understand, and easily changeable codebase by abstracting away certain details. Let me give you an example:

function hitAPI(type){
    if (type instanceof InitialLoad) {
        // Implementation example
    } else if (type instanceof NavBar) {
        // Implementation example
    } else {
        // Implementation example
    }
}

Can you see in the example how you have to implement exactly what you need for your custom use-case?

Every new API you need to hit needs a new if block, and it's own custom code. This isn't abstracted away as you need to worry about the implementation for every new type you add. It isn't reusable, and is a maintenance nightmare.

How about something like the below?

hitApi('www.kealanparr.com', HTTPMethod.Get)

You now can just pass a URL to your function and what HTTP method you want to use and you're done.

You don't have to worry about how the function works. It's dealt with. This massively helps code reuse! And makes your code a lot more maintainable, too.

That is what Abstraction is all about. Finding things that are similar in your code and providing a generic function or object to serve multiple places/with multiple concerns.

Here's a good final example of Abstraction: imagine if you were creating a machine to make coffee for your users. There could be two approaches:

How to Create it With Abstraction

• Have a button with the title "Make coffee"

How to Create it Without Abstraction

• Have a button with the title "Boil the water"
• Have a button with the title "Add the cold water to the kettle"
• Have a button with the title "Add 1 spoon of ground coffee to a clean cup"
• Have a button with the title "Clean any dirty cups"
• And all the other buttons

It's a very simple example, but the first approach abstracts away the logic into the machine. But the second approach forces the user to understand how to make coffee and essentially make their own.

The next pillar shows us one way we can achieve Abstraction, by using Encapsulation.

Encapsulation in Object-Oriented Programming

The definition of encapsulation is "the action of enclosing something in or as if in a capsule". Removing access to parts of your code and making things private is exactly what Encapsulation is all about (often times, people refer to it as data hiding).

Encapsulation means that each object in your code should control its own state. State is the current "snapshot" of your object. The keys, the methods on your object, Boolean properties and so on. If you were to reset a Boolean or delete a key from the object, they're all changes to your state.

Limit what pieces of your code can access. Make more things inaccessible, if they aren't needed.

Private properties are achieved in JavaScript by using closures. Here's an example below:

var Dog = (function () {

    // Private
    var play = function () {
        // play implementation
    };

    // Private
    var breed = "Dalmatian"

    // Public
    var name = "Rex";

    // Public
    var makeNoise = function () {
         return 'Bark bark!';
    };

     return {
        makeNoise: makeNoise,
        name: name
     };
})();

The first thing we did was create a function that immediately gets called (called an Immediately Invoked Function Expression, or IIFE for short). This created an object that anyone can access but hid away some of the details. You can't call play and you can't access breed as we didn't expose it in the final object with the return.

This particular pattern above is called the Revealing Module Pattern, but it's just an example of how you can achieve Encapsulation.

I want to focus more on the idea of Encapsulation (as it is more important than just learning one pattern and counting Encapsulation as totally complete now).

Reflect, and think more about how you can hide away your data and code, and separate it out. Modularising and having clear responsibilities is key to Object Orientation.

Why should we prefer privacy? Why not just have everything global?

• Lots of unrelated bits of code will become dependent/coupled to one another via the global variable.
• You will likely override the variables if the name get's reused, which can lead to bugs or unpredictable behaviour.
• You will likely end up with Spaghetti Code – code that's hard to reason through and follow what is reading and writing to your variables and changing state.

Encapsulation can be applied by separating out long lines of code into smaller separate functions. Separate out those functions into modules. We hide away the data in a place nothing else needs access to, and cleanly expose what is needed.

That is Encapsulation is a nutshell. Binding your data to something, whether it's a class, object, module or function, and doing your best to keep it as private as you reasonably can.

Inheritance in Object-Oriented Programming

Inheritance lets one object acquire the properties and methods of another object. In JavaScript this is done by Prototypal Inheritance.

Reusability is the main benefit here. We know sometimes that multiple places need to do the same thing, and they need to do everything the same except for one small part. This is a problem inheritance can solve.

Whenever we use inheritance, we try to make it so that the parent and the child have high cohesion. Cohesion is how related your code is. For example, does the Bird type extend from the DieselEngine type?

Keep your inheritance simple to understand and predictable. Don't inherit from somewhere completely unrelated because there's one method or property you need. Inheritance doesn't fix that particular problem well.

When using inheritance, you should require most of the functionality (you don't always need absolutely everything).

Developers have a principle called the Liskov Substitution principle. It states that if you can use a parent class (let's call it ParentType) anywhere you use a child (let's call it ChildType) – and ChildType inherits from the ParentType – then you pass the test.

The main reason you would fail this test, is if the ChildType is removing things from the parent. If ChildType removed methods it inherited from the parent, it'd lead to TypeError's where things are undefined that you are expecting not to be.

The arrows look like they're going the wrong way. But the Animal is the base - the parent.

Inheritance chain is the term used to describe the flow of inheritance from the base object's prototype (the one that everything else inherits from) to the "end" of the inheritance chain (the last type that is inheriting – Dog in the above example).

Do your best to keep your inheritance chains clean and sensible. You can easily end up coding an anti-patterns when using Inheritance (called the Fragile base anti-pattern). This happens where your base prototypes are considered "fragile" because you make a "safe" change to the base object and then start to break all your children.

Polymorphism in Object-Oriented Programming

Polymorphism means "the condition of occurring in several different forms." That's exactly what the fourth and final pillar is concerned with – types in the same inheritance chains being able to do different things.

If you have used inheritance correctly you can now reliably use parents like their children. When two types share an inheritance chain, they can be used interchangeably with no errors or assertions in your code.

From the last diagram, we might have a base prototype that is called Animal which defines makeNoise. Then every type extending from that prototype can override to do their own custom work. Something like this:

// Let's set up an Animal and Dog example
function Animal(){}
function Dog(){}

Animal.prototype.makeNoise = function(){
    console.log("Base noise");
};

// Most animals we code up have 4. This can be overridden if needed
Animal.prototype.legs = 4;

Dog.prototype = new Animal();

Dog.prototype.makeNoise = function(){
    console.log("Woof woof");  
};

var animal = new Animal();
var dog = new Dog();

animal.makeNoise(); // Base noise
dog.makeNoise();    // Woof woof- this was overridden
dog.legs;           // 4! This was inherited

Dog extends from Animal and can make use of the default legs property. But it's also able to do its own implementation of making its own noise.

The real power of polymorphism is sharing behaviours, and allowing custom overrides.

Conclusion

I hope this has explained what the four pillars of object-oriented programming are, and how they lead to cleaner and more robust code.

I share my writing on Twitter if you enjoyed this article and want to see more.

For example, say you have a class Vehicle which defines the basic functionality (methods) and components (object variables) that vehicles have in common.

You cannot create an object of Vehicle because a vehicle is itself an abstract, general concept. Vehicles have wheels and motors, but the number of wheels and the size of motors can differ greatly.

You can, however, extend the functionality of the vehicle class to create a Car or a Motorcycle:

abstract class Vehicle
{
  //variable that is used to declare the no. of wheels in a vehicle
  private int wheels;

  //Variable to define the type of motor used
  private Motor motor;

  //an abstract method that only declares, but does not define the start 
  //functionality because each vehicle uses a different starting mechanism
  abstract void start();
}

public class Car extends Vehicle
{
  ...
}

public class Motorcycle extends Vehicle
{
  ...
}

Remember, you cannot instantiate a Vehicle anywhere in your program – instead, you can use the Car and Motorcycle classes you declared earlier and create instances of those:

Vehicle newVehicle = new Vehicle();    // Invalid
Vehicle car = new Car();  // valid
Vehicle mBike = new Motorcycle();  // valid

Car carObj = new Car();  // valid
Motorcycle mBikeObj = new Motorcycle();  // valid

More information:

• Learn Functional Programming in Java - Full Course
• Getters and Setters in Java Explained
• Inheritance in Java Explained

The languages that use Object Oriented Programming paradigms are known as Object Oriented Programming Languages. They are mostly high level languages such as

1. Java
2. C#
3. Python - Python is both a Scripted/Structured & Object Oriented Language

To program in Object Oriented Programming, concepts called “Object Oriented Concepts” are used. These concepts simplify & add more value to Object Oriented Programming.

Those concepts are

1. Encapsulation
2. Abstraction
3. Polymorphism
4. Inheritance

Before moving into these concepts, we need to know about Class & Objects.

An Object is the basic run-time entity in OOP. In our day-today life we see a lot of objects like a television, mobile phone, dog, humans, cars & other living and non-living objects. These can be portrayed as objects in OOP.

A Class is a blueprint or prototype that defines variables/properties and methods/functions common to all objects of a certain kind. It's a logical component.

Simply said, Class is a user-defined data type. Objects are variables of a Class. Once the Class has been created we can create as many Objects as we want.

For example, take a class named Tree. State/properties of the Tree class are:

• Name of the tree
• Age of the tree
• Type of the tree
• Height of the tree

State/properties are used to define the attributes of an object.

That is, State/properties/attributes all represents the same thing.

Behaviors of the Tree can be:

• Giving fruit
• Falling of leaves
• Absorbing water from roots to the upper parts
• Creating shadows

Then, Mango is a variable of Class Tree. We can store and retrieve all the properties & behaviors we defined for the class Tree by creating an object of Mango.

Syntax for Creating an object of Mango from class Tree:

Tree Mango;

Encapsulation

Have you ever used a tablet/medicine which encapsulated by a colored cover?

Medicines are encapsulated & placed inside the tablet

Inside that medicine is kept safely. We can't find anything with our naked eye. To see what's inside we need to open up that cover....

Similarly, all the data members (variables,attributes/properties) & behaviors(functions/methods) are gathered together and closed. Class is a best example for Encapsulation.

For an instance,

You are going to the pharmacy to buy prescribed medicines for you. You handover the prescription to the pharmacist and then he/she will take the medicine from the store & give you the bill.

In this scenario,

Medicines - act as variables or properties or attributes

Pharmacist - act as member function/method where he/she helps in giving you the medicine

You - external application or another software code

By using Encapsulation, data can be restricted from the usage of the outside world. The function defined in the class only can access the properties. This can be defined at the implementation stage. Programmers can define and specify the accessibility of the member variables while under development rather than making all the variables global like in procedural languages. This controlling of accessibility is also known as Information hiding.

Encapsulation allows to expose the necessary things and hiding the important things from the outside world. So, the hidden parts of a class acts like Encapsulation & the exposed parts acts like Abstraction.

Abstraction

Exposing necessary features of a class without explaining much or details is done by Abstraction.

Today morning I wanted to make a hot tea and I used a water kettle to boil the water. I just turned on the On button to start boil water. I don’t want to know the inner workflow of the kettle where it has high resistance and that resistance produces heat and boils the water. Instead, I have to fulfill my work easily. Therefore, having this On button to boil the water is known as Abstraction.

Similarly, we can take a remote controller which helps in manipulating TV operation using simple keys in the remote.

Data abstraction is a programming technique that depends on the separation of interface and implementation.

This data abstraction can be archived from using 2 different classes while coding using OOP

1. Abstraction class: (0-100)% abstraction
2. Interface class: 100% abstraction

Inheritance

The word itself describe what its functionality. Everyone has their inheritance qualities from their birth. You could have your grandparents/ your parents qualities from your birth. This is what Inheritance does in OOP.

A class can have properties & methods of its parent class. Additionally the class can have its own properties and methods too. The parent class is called as base class. The class that inherits base class is called as derived class. Inheritance is the most powerful feature of OOP.

By using Inheritance effectively we could save a lot of time and reduce the errors in our program. This causes us to increase the quality of work and productivity.

There are different types of Inheritance

1. Single Inheritance
2. Hierarchical Inheritance
3. Multiple Inheritance
4. Multi Level Inheritance

Polymorphism

Polymorphism is a Greek term which refers to the ability of taking more than one form / overloading.

Say for example we all know about functions in programming. They take different arguments inside parenthesis. Polymorphism is nothing but with the same function name, different arguments passed to get the result.

For e.g :- function called sum can take 2 arguments or 3 arguments.

sum(3,4) sum(10,23,56)
Calling these functions by providing suitable number of parameters will give the result according to how the called function has designed.

How the program distinguish which function need to be executed at the above scenario?

There is a feature called Dynamic binding in OOP. This will call the actual function according to the program execution. When the program runs the function with 2 arguments compiler takes the two argument functions to execute the program similarly for 3 arguments too.

Until the run-time, compiler won’t know exactly which function need to be invoked. It depends on the way the program calls the function name. This is also be known as Late binding.

Uses of Object Oriented Concepts

• Data can be hidden from outside using Encapsulation (Information hiding)
• Code can be reused by using Inheritance
• Operators/methods.functions can be overloaded by using Polymorphism. I.e: same function or operator name can be used for multi-tasking
• Data abstraction can be archived from Abstraction.
• Project migrations are easy (can be converted to larger size from smaller size)
• Partitioning the works for same project
• Manageable software complexity

Areas of application of OOP

1. AI and expert systems
2. Enterprise applications
3. Neural Network and parallel programming
4. Office automation systems

Hope you enjoyed a brief introduction to Object Oriented Concepts by reading. I hope to write how can we program Object Oriented Programming in my upcoming posts too.

Please send you feedback about my article to parathan19@gmail.com

LinkedIn | Twitter

What is a Design Pattern?

Design patterns are design level solutions for recurring problems that we software engineers come across often. It’s not code - I repeat, ❌CODE. It is like a description on how to tackle these problems and design a solution.

Using these patterns is considered good practice, as the design of the solution is quite tried and tested, resulting in higher readability of the final code. Design patterns are quite often created for and used by OOP Languages, like Java, in which most of the examples from here on will be written.

Types of design patterns

There are about 26 Patterns currently discovered (I hardly think I will do them all…).

These 26 can be classified into 3 types:

1. Creational: These patterns are designed for class instantiation. They can be either class-creation patterns or object-creational patterns.

2. Structural: These patterns are designed with regard to a class's structure and composition. The main goal of most of these patterns is to increase the functionality of the class(es) involved, without changing much of its composition.

3. Behavioral: These patterns are designed depending on how one class communicates with others.

In this post, we will go through one basic design pattern for each classified type.

Type 1: Creational - The Singleton Design Pattern

The Singleton Design Pattern is a Creational pattern, whose objective is to create only one instance of a class and to provide only one global access point to that object. One commonly used example of such a class in Java is Calendar, where you cannot make an instance of that class. It also uses its own getInstance()method to get the object to be used.

A class using the singleton design pattern will include,

Singleton Class Diagram

1. A private static variable, holding the only instance of the class.
2. A private constructor, so it cannot be instantiated anywhere else.
3. A public static method, to return the single instance of the class.

There are many different implementations of singleton design. Today, I’ll be going through the implementations of;

1. Eager Instantiation

2. Lazy Instantiation

3. Thread-safe Instantiation

Eager Beaver

public class EagerSingleton {
    // create an instance of the class.
    private static EagerSingleton instance = new EagerSingleton();

    // private constructor, so it cannot be instantiated outside this class.
    private EagerSingleton() {  }

    // get the only instance of the object created.
    public static EagerSingleton getInstance() {
        return instance;
    }
}

This type of instantiation happens during class loading, as the instantiation of the variable instance happens outside any method. This poses a hefty drawback if this class is not being used at all by the client application. The contingency plan, if this class is not being used, is the Lazy Instantiation.

Lazy Days

There isn’t much difference from the above implementation. The main differences are that the static variable is initially declared null, and is only instantiated within the getInstance() method if - and only if - the instance variable remains null at the time of the check.

public class LazySingleton {
    // initialize the instance as null.
    private static LazySingleton instance = null;

    // private constructor, so it cannot be instantiated outside this class.
    private LazySingleton() {  }

    // check if the instance is null, and if so, create the object.
    public static LazySingleton getInstance() {
        if (instance == null) {
            instance = new LazySingleton();
        }
        return instance;
    }
}

This fixes one problem, but another one still exists. What if two different clients access the Singleton class at the same time, right to the millisecond? Well, they will check if the instance is null at the same time, and will find it true, and so will create two instances of the class for each request by the two clients. To fix this, Thread Safe instantiation is to be implemented.

(Thread) Safety is Key

In Java, the keyword synchronized is used on methods or objects to implement thread safety, so that only one thread will access a particular resource at one time. The class instantiation is put within a synchronized block so that the method can only be accessed by one client at a given time.

public class ThreadSafeSingleton {
    // initialize the instance as null.
    private static ThreadSafeSingleton instance = null;

    // private constructor, so it cannot be instantiated outside this class.
    private ThreadSafeSingleton() {  }

    // check if the instance is null, within a synchronized block. If so, create the object
    public static ThreadSafeSingleton getInstance() {
        synchronized (ThreadSafeSingleton.class) {
            if (instance == null) {
                instance = new ThreadSafeSingleton();
            }
        }
        return instance;
    }
}

The overhead for the synchronized method is high, and reduces the performance of the whole operation.

For example, if the instance variable has already been instantiated, then each time any client accesses the getInstance() method, the synchronized method is run and the performance drops. This just happens in order to check if the instance variables’ value is null. If it finds that it is, it leaves the method.

To reduce this overhead, double locking is used. The check is used before the synchronized method as well, and if the value is null alone, does the synchronized method run.

// double locking is used to reduce the overhead of the synchronized method
public static ThreadSafeSingleton getInstanceDoubleLocking() {
    if (instance == null) {
        synchronized (ThreadSafeSingleton.class) {
            if (instance == null) {
                instance = new ThreadSafeSingleton();
            }
        }
    }
    return instance;
}

Now onto the next classification.

Type 2: Structural - The Decorator Design Pattern

I’m gonna give you a small scenario to give a better context to why and where you should use the Decorator Pattern.

Say you own a coffee shop, and like any newbie, you start out with just two types of plain coffee, the house blend and dark roast. In your billing system, there was one class for the different coffee blends, which inherits the beverage abstract class. People actually start to come by and have your wonderful (albeit bitter?) coffee. Then there are the coffee newbs that, God forbid, want sugar or milk. Such a travesty for coffee!! ??

Now you need to have those two add-ons as well, both to the menu and unfortunately on the billing system. Originally, your IT person will make a subclass for both coffees, one including sugar, the other milk. Then, since customers are always right, one says these dreaded words:

“Can I get a milk coffee, with sugar, please?”

???

There goes your billing system laughing in your face again. Well, back to the drawing board….

The IT person then adds milk coffee with sugar as another subclass to each parent coffee class. The rest of the month is smooth sailing, people lining up to have your coffee, you actually making money. ??

But wait, there’s more!

The world is against you once again. A competitor opens up across the street, with not just 4 types of coffee, but more than 10 add-ons as well!

You buy all those and more, to sell better coffee yourself, and just then remember that you forgot to update that dratted billing system. You quite possibly cannot make the infinite number of subclasses for any and all combinations of all the add-ons, with the new coffee blends too. Not to mention, the size of the final system.

Time to actually invest in a proper billing system. You find new IT personnel, who actually knows what they are doing and they say,

“Why, this will be so much easier and smaller if it used the decorator pattern.”

What on earth is that?

The decorator design pattern falls into the structural category, that deals with the actual structure of a class, whether is by inheritance, composition or both. The goal of this design is to modify an objects’ functionality at runtime. This is one of the many other design patterns that utilize abstract classes and interfaces with composition to get its desired result.

Let’s give Math a chance (shudder?) to bring this all into perspective.

Take 4 coffee blends and 10 add-ons. If we stuck to the generation of subclasses for each different combination of all the add-ons for one type of coffee. That’s:

(10–1)² = 9² = 81 subclasses

We subtract 1 from the 10, as you cannot combine one add-on with another of the same type, sugar with sugar sounds stupid. And that’s for just one coffee blend. Multiply that 81 by 4 and you get a whopping 324 different subclasses! Talk about all that coding…

But with the decorator pattern it will require only 16 classes in this scenario. Wanna bet?

Decorator Design Pattern Class diagram

Class diagram according to coffee shop scenario

If we map out our scenario according to the class diagram above, we get 4 classes for the 4 coffee blends, 10 for each add-on and 1 for the abstract component and 1 more for the abstract decorator. See! 16! Now hand over that $100.?? (jk, but it will not be refused if given… just saying)

As you can see from above, just as the concrete coffee blends are subclasses of the beverage abstract class, the AddOn abstract class also inherits its methods from it. The add-ons, that are its subclasses, in turn inherit any new methods to add functionality to the base object when needed.

Let’s get to coding, to see this pattern in use.

First to make the Abstract beverage class, that all the different coffee blends will inherit from:

public abstract class Beverage {
    private String description;

    public Beverage(String description) {
        super();
        this.description = description;
    }

    public String getDescription() {
        return description;
    }

    public abstract double cost();
}

Then to add both the concrete coffee blend classes.

public class HouseBlend extends Beverage {
    public HouseBlend() {
        super(“House blend”);
    }

    @Override
    public double cost() {
        return 250;
    }
}

public class DarkRoast extends Beverage {
    public DarkRoast() {
        super(“Dark roast”);
    }

    @Override
    public double cost() {
        return 300;
    }
}

The AddOn abstract class also inherits from the Beverage abstract class (more on this below).

public abstract class AddOn extends Beverage {
    protected Beverage beverage;

    public AddOn(String description, Beverage bev) {
        super(description);
        this.beverage = bev;
    }

    public abstract String getDescription();
}

And now the concrete implementations of this abstract class:

public class Sugar extends AddOn {
    public Sugar(Beverage bev) {
        super(“Sugar”, bev);
    }

    @Override
    public String getDescription() {
        return beverage.getDescription() + “ with Mocha”;
    }

    @Override
    public double cost() {
        return beverage.cost() + 50;
    }
}

public class Milk extends AddOn {
    public Milk(Beverage bev) {
        super(“Milk”, bev);
    }

    @Override
    public String getDescription() {
        return beverage.getDescription() + “ with Milk”;
    }

    @Override  public double cost() {
        return beverage.cost() + 100;
    }
}

As you can see above, we can pass any subclass of Beverage to any subclass of AddOn, and get the added cost as well as the updated description. And, since the AddOn class is essentially of type Beverage, we can pass an AddOn into another AddOn. This way, we can add any number of add-ons to a specific coffee blend.

Now to write some code to test this out.

public class CoffeeShop {
    public static void main(String[] args) {
        HouseBlend houseblend = new HouseBlend();
        System.out.println(houseblend.getDescription() + “: “ + houseblend.cost());

        Milk milkAddOn = new Milk(houseblend);
        System.out.println(milkAddOn.getDescription() + “: “ + milkAddOn.cost());

        Sugar sugarAddOn = new Sugar(milkAddOn);
        System.out.println(sugarAddOn.getDescription() + “: “ + sugarAddOn.cost());
    }
}

The final result is:

P.S. this is in Sri Lankan Rupees

It works! We were able to add more than one add-on to a coffee blend and successfully update its final cost and description, without the need to make infinite subclasses for each add-on combination for all coffee blends.

Finally, to the last category.

Type 3: Behavioral - The Command Design Pattern

A behavioral design pattern focuses on how classes and objects communicate with each other. The main focus of the command pattern is to inculcate a higher degree of loose coupling between involved parties (read: classes).

Uhhhh… What’s that?

Coupling is the way that two (or more) classes that interact with each other, well, interact. The ideal scenario when these classes interact is that they do not depend heavily on each other. That’s loose coupling. So, a better definition for loose coupling would be, classes that are interconnected, making the least use of each other.

The need for this pattern arose when requests needed to be sent without consciously knowing what you are asking for or who the receiver is.

In this pattern, the invoking class is decoupled from the class that actually performs an action. The invoker class only has the callable method execute, which runs the necessary command, when the client requests it.

Let’s take a basic real-world example, ordering a meal at a fancy restaurant. As the flow goes, you give your order (command) to the waiter (invoker), who then hands it over to the chef(receiver), so you can get food. Might sound simple… but a bit meh to code.

The idea is pretty simple, but the coding goes around the nose.

Command Design Pattern Class Diagram

The flow of operation on the technical side is, you make a concrete command, which implements the Command interface, asking the receiver to complete an action, and send the command to the invoker. The invoker is the person that knows when to give this command. The chef is the only one who knows what to do when given the specific command/order. So, when the execute method of the invoker is run, it, in turn, causes the command objects’ execute method to run on the receiver, thus completing necessary actions.

What we need to implement is;

1. An interface Command
2. A class Order that implements Command interface
3. A class Waiter (invoker)
4. A class Chef (receiver)

So, the coding goes like this:

Chef, the receiver

public class Chef {
    public void cookPasta() {
        System.out.println(“Chef is cooking Chicken Alfredo…”);
    }

    public void bakeCake() {
        System.out.println(“Chef is baking Chocolate Fudge Cake…”);
    }
}

Command, the interface

public interface Command {
    public abstract void execute();
}

Order, the concrete command

public class Order implements Command {
    private Chef chef;
    private String food;

    public Order(Chef chef, String food) {
        this.chef = chef;
        this.food = food;
    }

    @Override
    public void execute() {
        if (this.food.equals(“Pasta”)) {
            this.chef.cookPasta();
        } else {
            this.chef.bakeCake();
        }
    }
}

Waiter, the invoker

public class Waiter {
    private Order order;

    public Waiter(Order ord) {
        this.order = ord;
    }

    public void execute() {
        this.order.execute();
    }
}

You, the client

public class Client {
    public static void main(String[] args) {
        Chef chef = new Chef();

        Order order = new Order(chef, “Pasta”);
        Waiter waiter = new Waiter(order);
        waiter.execute();

        order = new Order(chef, “Cake”);
        waiter = new Waiter(order);
        waiter.execute();
    }
}

As you can see above, the Client makes an Order and sets the Receiver as the Chef. The Order is sent to the Waiter, who will know when to execute the Order (i.e. when to give the chef the order to cook). When the invoker is executed, the Orders’ execute method is run on the receiver (i.e. the chef is given the command to either cook pasta ? or bake cake?).

Final Client Output

Quick recap

In this post we went through:

1. What a design pattern really is,
2. The different types of design patterns and why they are different
3. One basic or common design pattern for each type

I hope this was helpful.

Find the code repo for the post, here.

Object-oriented programming (OOP) is a programming paradigm organized around objects. At a high level, OOP is all about being able to structure code so that its functionality can be shared throughout the application. If done properly, OOP can lead to very elegantly written programs that have minimal code duplication.

This is opposed to procedural programming (PP), in which you build programs in sequential order and call methods when you want shared behavior between pages in the application. Common procedural programming languages include C and Go.

In this tutorial, you’ll learn the fundamental concepts of OOP for Ruby, an object-oriented programming language wherein everything is an object. We will be using Ruby since one of its defining attributes — in addition to its elegant syntax and readability — is how it implements OOP techniques. This makes it a great language to start learning OOP with.

We will cover:

• Creating classes
• Instantiating objects
• Initializing arguments
• Working with inheritance, and
• Private and public methods.

In learning these concepts, we will build out our own application: an API connector that communicates dynamically with an application that sends a text message. This will include walking through how to leverage concepts such as inheritance and object instantiation to make our code more scalable and reusable!

This brief tutorial is adapted from Next Tech’s Introduction to Ruby course, which includes an in-browser sandboxed environment and auto-checked interactive tasks to complete.

You can follow along with the code snippets in this tutorial using Next Tech’s sandbox which already has Ruby pre-installed. If you chose to use your own IDE, make sure Ruby is installed by following the instructions on the installation page.

Creating Classes

Before we begin, let’s define what an object is. At its core, an object is a self-contained piece of code that contains data (“attributes”) and behavior (“methods”) and can communicate with other objects. Objects of the same type are created from classes, which act as blueprints that define properties and behavior.

Creating a class in Ruby is fairly easy. To define a class, simply type the class word followed by the name of the class, and end it with the end word. Anything contained between class and end belongs to this class.

Class names in Ruby have a very specific style requirement. They need to start with a letter and if they represent multiple words, each new word needs also to be an uppercase letter — i.e. “CamelCase”.

We’ll start by creating a class called ApiConnector:

Classes in Ruby can store both data and methods. In many traditional OOP languages such as Java, you need to create two methods for each data element you want to be included in the class. One method, the setter, sets the value in the class. The other method, the getter, allows you to retrieve the value.

The process of creating setter and getter methods for every data attribute can be tiresome and leads to incredibly long class definitions. Thankfully Ruby has a set of tools called attribute accessors.

Let’s implement some setters and getters for some new data elements for our class. Since it’s an API connector, it would make sense to have data elements such as title, description, and url. We can add these elements with the following code:

When you merely create a class, it doesn’t do anything — it is simply a definition. In order to work with the class, we need to create an instance of it…we’ll cover that next!

Instantiation

To understand what instantiation is, let’s consider a real-world analogy. Let’s imagine that you’re building a house. The first task is to build a blueprint for the house. This blueprint would contain attributes and features of the house, such as the dimensions for each room, how the plumbing will flow, and so on.

Is the blueprint of the house the actual house? Of course not, it simply lists out the attributes and design elements for how the home will be created. So after the blueprint is completed, the actual home can be built — or, “instantiated”.

As explained in the previous section, in OOP, a class is the blueprint for an object. It simply describes what an object will look like and how it will behave. Therefore, instantiation is the process of taking a class definition and creating an object that you can use in a program.

Let’s create a new instance of our ApiConnector class and store it in a variable called api:

Now that we have an object created, we can use the api variable to work with the class attributes. For example, we can run the code:

[Out:]https://next.tech

In addition to creating attributes, you can also create methods within a class:

To access this method, we can use the same syntax that we utilized with the attribute accessors:

Putting this all together, running the full class code below will result in the url and the test_method message to be printed:

[Out:]"https://next.tech""testing class call"

Initializer Method

One thing you may find handy in Ruby development is the ability to create an initializer method. This is simply a method called initialize that will run every time when you create an instance of your class. In this method, you can give values to your variables, call other methods, and do just about anything that you think should happen when a new instance of that class is created.

Let’s update our ApiConnector to utilize an initializer method:

Within the initialize method, we created an instance variable for each of the parameters so that we can use these variables in other parts of the application as well.

We also removed the attr_accessor method since the new initialize method will take care of this for us. If you need the ability to call the data elements outside of the class, then you would still need to have the attr_accessor call in place.

To test if the initialize method is working, let’s create another method within the class that prints these values out:

Finally, we’ll instantiate the class and test the initialize method:

[Out:]"My title""My cool description""https://next.tech"

Working with optional values

Now, what happens when we want to make one of these values optional? For example, what if we want to give a default value to the URL? To do that, we can update our initialize method with the following syntax:

Now our program will have the same output even if we don’t pass the url value while creating a new instance of the class:

Using named arguments

Though this looks simple, passing arguments can get complex in real-world Ruby applications because some methods may take a large number of arguments. In such cases, it becomes difficult to know the order of arguments and what values to assign to them.

To avoid this confusion, you can utilize named arguments, like this:

You can enter the arguments without having to look at the order in the initialize method, and even change the order of the arguments without causing an error:

Overriding default values

What happens if we want to override a default value? We simply update our instantiation call like this:

This update will override our default value of https://next.tech, and calling api.testing_initializer will now print https://next.xyz as the URL.

Inheritance

Now, we are going to learn about an important object-oriented principle called inheritance. Before going into how it is executed in Ruby, let’s see why it’s important for building applications.

To start with, inheritance means your classes can have a hierarchy. It is best used when different classes have some shared responsibilities, since it would be a poor practice to duplicate code in each class for identical or even similar behavior.

Take our ApiConnector class. Let's say we have different API classes for various platforms, but each class shares a number of common data or processes. Instead of duplicating code in each of the API connector classes, we can have one parent class with the shared data and methods. From there, we can create child classes from this parent class. With the way that inheritance works, each of the child classes will have access to the components provided from the parent class.

For example, say we have three APIs: SmsConnector, PhoneConnector, and MailerConnector. If we wrote code individually for each of these classes, it would look like this:

As you can see, we are simply repeating the same code across different classes. This is considered a poor programming practice that violates the DRY (Don’t Repeat Yourself) principle of development. Instead, we can make an ApiConnector parent class, and each of the other classes can inherit the common functionality from this class:

By leveraging inheritance, we were able to cut all of the duplicate code throughout our classes.

The syntax for using inheritance is to define the child class name, followed by the &lt; symbol, then the parent class name — i.e. our SmsConnector, MailerConnector, and PhoneConnector classes inherit from the ApiConnector class .

Each of these child classes now has access to the full set of elements provided in the parent ApiConnector class. For example, if we create a new instance of SmsConnector with the following parameters, we can call the send_sms method:

[Out:]Sending SMS message with the title 'Hi there!' and description 'I'm an SMS message'.

A rule of thumb in OOP is to ensure that a class performs a single responsibility. For example, the ApiConnector class should not send SMS messages, make phone calls, or send emails since that would be three core responsibilities.

Private and Public Methods

Before we dive into private and public methods, let’s first go back to our original ApiConnector class and create a SmsConnector class that inherits from ApiConnector. In this class, we will create a method called send_sms that will run a script that contacts an API:

This method will send a title and url to an API, which will in turn send an SMS message. Now we can instantiate the SmsConnector class and call the send_sms message:

Running this code will contact the SMS API and send the message. You can go to the bottom of this page to see your message!

Now, using this example, let’s discuss the types of methods provided by classes.

The send_sms method is a public method. This means that anyone working on our class can communicate with this method. This may not seem like a big deal if you are working on an application that no one else is working on. However, if you build an API or code library that is open sourced for others to use, it's vital that your public methods represent elements of functionality that you actually want other developers to use.

Public methods should rarely, if ever, be altered. This is because other developers may be relying on your public methods to be consistent, and a change to a public method may break components of their programs.

So, if you can’t change public methods, how can you work on a production application? That’s where private methods come in. A private method is a method that is only accessed by the class that it is contained in. It should never be called by outside services. This means that you can alter their behavior, assuming that these changes don’t have a domino effect and alter the public methods that they may be called from.

Usually private methods are placed at the end of the file after all the public methods. To designate private methods, we use the private word above the list of methods. Let’s add a private method to our ApiConnector class:

Notice how we’re calling this method from the inside of the initialize method of the ApiConnector class? If we run this code, it will give the following output:

[Out:]A secret message from the parent class

Now child classes have access to methods in the parent class, right? Well, not always. Let’s remove the secret_method method from the initialize method in ApiConnector and try to call it from our SmsConnector child class, as shown here:

[Out:]Traceback (most recent call last):main.rb:29:in `<main>': private method `secret_method' called for #SmsConnector:0x000056188cfe19b0> (NoMethodError)

This is because the SmsConnector class only has access to the public methods from the parent class. The private methods are, by their nature, private. This means that they can only be accessed by the class that they are defined in.

So a good rule of thumb is to create private methods when they should not be used outside the class and public methods when they have to be available throughout the application or used by outside services.

Wrapping up

I hope you enjoyed this quick tutorial on the fundamental concepts of object-oriented programming in Ruby! We covered creating classes, attribute accessors, instantiation, initialization, inheritance, and private and public methods.

Ruby is a powerful object-oriented language used by popular applications, including our own here at Next Tech. With this foundational knowledge of OOP, you’re well on your way to developing your own Ruby apps!

If you’re interested in learning more about programming with Ruby, check out our Introduction to Ruby course here! In this course we cover core programming skills, such as variables, strings, loops, and conditionals, more advanced OOP topics, and error handling.

Here’s a neat Python trick you might just find useful one day. Let’s look at how you can dynamically define classes, and create instances of them as required.

This trick makes use of Python’s object oriented programming (OOP) capabilities, so we’ll review those first.

Classes and objects

Python is an object-oriented language, meaning it lets you write code in the object oriented paradigm.

The key concept in this programming paradigm is classes. In Python, these are used to create objects which can have attributes.

Objects are specific instances of a class. A class is essentially a blueprint of what an object is and how it should behave.

Classes are defined with two types of attribute:

• Data attributes — variables available to a given instance of that class
• Methods — functions available to an instance of that class

The classic OOP example usually involves different types of animal, or food. Here, I’ve gone more practical with a simple data visualization theme.

First, define the class BarChart.

class BarChart:
    def __init__(self, title, data):
        self.title = title
        self.data = data
       def plot(self):
        print("\n"+self.title)
        for k in self.data.keys():
            print("-"*self.data[k]+" "+k)

The __init__ method lets you set attributes upon instantiation. That is, when you create a new instance of BarChart, you can pass arguments that provide the chart’s title and data.

This class also has a plot() method. This prints a very basic bar chart to the console when it is called. It could feasibly do more interesting things in a real application.

Next, instantiate an instance of BarChart:

data = {"a":4, "b":7, "c":8}bar = BarChart("A Simple Chart", data)

Now you can use the bar object in the rest of your code:

bar.data['d'] = bar.plot()

A Simple Chart
---- a
------- b
-------- c
----- d

This is great, because it allows you to define a class and create instances dynamically. You can spin up instances of other bar charts in one line of code.

new_data = {"x":1, "y":2, "z":3}
bar2 = BarChart("Another Chart", new_data)
bar2.plot()

Another Chart
- x
-- y
--- z

Say you wanted to define several classes of chart. Inheritance lets you define classes which “inherit” properties from base classes.

For example, you could define a base Chart class. Then you can define derived classes which inherit from the base.

class Chart:
    def __init__(self, title, data):
        self.title = title
        self.data = data
    def plot(self):
        pass

class BarChart(Chart):
    def plot(self):
        print("\n"+self.title)
        for k in self.data.keys():
            print("-"*self.data[k]+" "+k)

class Scatter(Chart):
    def plot(self):
        points = zip(data['x'],data['y'])
        y = max(self.data['y'])+1
        x = max(self.data['x'])+1
        print("\n"+self.title)
        for i in range(y,-1,-1):
            line = str(i)+"|"
            for j in range(x):
                if (j,i) in points:
                    line += "X"
                else:
                    line += " "
            print(line)

Here, the Chart class is a base class. The BarChart and Scatter classes inherit the __init__() method from Chart. But they have their own plot() methods which override the one defined in Chart.

Now you can create scatter chart objects as well.

data = {'x':[1,2,4,5], 'y':[1,2,3,4]}
scatter = Scatter('Scatter Chart', data)
scatter.plot()

Scatter Chart
4|     X
3|      X 
2|  X
1| X
0|

This approach lets you write more abstract code, giving your application greater flexibility. Having blueprints to create countless variations of the same general object will save you unnecessarily repeating lines of code. It can also make your application code easier to understand.

You can also import classes into future projects, if you want to reuse them at a later time.

Factory methods

Sometimes, you won’t know the specific class you want to implement before runtime. For example, perhaps the objects you create will depend on user input, or the results of another process with a variable outcome.

Factory methods offer a solution. These are methods that take a dynamic list of arguments and return an object. The arguments supplied determine the class of the object that is returned.

A simple example is illustrated below. This factory can return either a bar chart or a scatter plot object, depending on the style argument it receives. A smarter factory method could even guess the best class to use, by looking at the structure of the data argument.

def chart_factory(title, data, style):
    if style == "bar":
        return BarChart(title, data)
    if style == "scatter":
        return Scatter(title, data)
    else:
        raise Exception("Unrecognized chart style.")

chart = chart_factory("New Chart", data, "bar")
chart.plot()

Factory methods are great when you know in advance which classes you want to return, and the conditions under which they are returned.

But what if you don’t even know this in advance?

Dynamic definitions

Python lets you define classes dynamically, and instantiate objects with them as required.

Why might you want to do this? The short answer is yet more abstraction.

Admittedly, needing to write code at this level of abstraction is generally a rare occurrence. As always when programming, you should consider if there is an easier solution.

However, there may be times when it genuinely proves useful to define classes dynamically. We’ll cover a possible use-case below.

You may be familiar with Python’s type() function. With one argument, it simply returns the “type” of the object of the argument.

type(1) # <type 'int'>
type('hello') # <type 'str'>
type(True) # <type 'bool'>

But, with three arguments, type() returns a whole new type object. This is equivalent to defining a new class.

NewClass = type('NewClass', (object,), {})

• The first argument is a string that gives the new class a name
• The next is a tuple, which contains any base classes the new class should inherit from
• The final argument is a dictionary of attributes specific to this class

When might you need to use something as abstract as this? Consider the following example.

Flask Table is a Python library that generates syntax for HTML tables. It can be installed via the pip package manager.

You can use Flask Table to define classes for each table you want to generate. You define a class that inherits from a base Table class. Its attributes are column objects, which are instances of the Col class.

from flask_table import Table, Col
class MonthlyDownloads(Table):
    month = Col('Month')
    downloads = Col('Downloads')

data = [{'month':'Jun', 'downloads':700},
        {'month':'Jul', 'downloads':900},
        {'month':'Aug', 'downloads':1600},
        {'month':'Sep', 'downloads':1900},
        {'month':'Oct', 'downloads':2200}]

table = MonthlyDownloads(data)print(table.__html__())

You then create an instance of the class, passing in the data you want to display. The __html__() method generates the required HTML.

Now, say you’re developing a tool that uses Flask Table to generate HTML tables based on a user-provided config file. You don’t know in advance how many columns the user wants to define — it could be one, it could be a hundred! How can your code define the right class for the job?

Dynamic class definition is useful here. For each class you wish to define, you can dynamically build the attributes dictionary.

Say your user config is a CSV file, with the following structure:

Table1, column1, column2, column3
Table2, column1
Table3, column1, column2

You could read the CSV file line-by-line, using the first element of each row as the name of each table class. The remaining elements in that row would be used to define Col objects for that table class. These are added to an attributes dictionary, which is built up iteratively.

for row in csv_file:
    attributes = {}
    for column in row[1:]:
        attributes[column] = Col(column)
        globals()[row[0]] = type(row[0], (Table,), attributes)

The code above defines classes for each of the tables in the CSV config file. Each class is added to the globals dictionary.

Of course, this is a relatively trivial example. FlaskTable is capable of generating much more sophisticated tables. A real life use-case would make better use of this! But, hopefully, you’ve seen how dynamic class definition might prove useful in some contexts.

So now you know…

If you are new to Python, then it is worth getting up to speed with classes and objects early on. Try implementing them in your next learning project. Or, browse open source projects on Github to see how other developers make use of them.

For those with a little more experience, it can be very rewarding to learn how things work “behind-the-scenes”. Browsing the official docs can be illuminating!

Have you ever found a use-case for dynamic class definition in Python? If so, it’d be great to share it in the responses below.

In many programming languages, classes are a well-defined concept. In JavaScript that is not the case. Or at least that wasn’t the case. If you search for O.O.P. and JavaScript you will run into many articles with a lot of different recipes on how you can emulate a class in JavaScript.

Is there a simple, K.I.S.S. way to define a class in JavaScript? And if so, why so many different recipes to define a class?

Before answering to those questions, let’s understand better what a JavaScript Object is.

Objects in JavaScript

Let’s begin with a very simple example:

const a = {};
a.foo = 'bar';

In the above code snippet an object is created and enhanced with a property foo. The possibility of adding things to an existing object is what makes JavaScript different from classic languages like Java.

More in detail, the fact that an object can be enhanced makes it possible to create an instance of an “implicit” class without the need to actually create the class. Let’s clarify this concept with an example:

function distance(p1, p2) {
  return Math.sqrt(
    (p1.x - p2.x) ** 2 + 
    (p1.y - p2.y) ** 2
  );
}

distance({x:1,y:1},{x:2,y:2});

In the example above, I didn’t need a Point class to create a point, I just extended an instance of Object adding x and y properties. The function distance doesn’t care if the arguments are an instance of the class Point or not. Until you call distance function with two objects that have an x and y property of type Number, it will work just fine. This concept is sometimes called duck typing.

Up to now, I’ve only used a data object: an object containing only data and no functions. But in JavaScript it is possible to add functions to an object:

const point1 = {
  x: 1,
  y: 1,
  toString() {
    return `(${this.x},${this.y})`;
  }
};

const point2 = {
  x: 2,
  y: 2,
  toString() {
    return `(${this.x},${this.y})`;
  }
};

This time, the objects representing a 2D point have a toString() method. In the example above, the toString code has been duplicated, and this is not good.

There are many ways to avoid that duplication, and, in fact, in different articles about objects and classes in JS you will find different solutions. Have you ever heard of the “Revealing module pattern”? It contains the words “pattern” and “revealing”, sounds cool, and “module” is a must. So it must be the right way to create objects… except that it isn’t. Revealing module pattern can be the right choice in some cases, but it is definitely not the default way of creating objects with behaviors.

We are now ready to introduce classes.

Classes in JavaScript

What is a class? From a dictionary: a class is “a set or category of things having some property or attribute in common and differentiated from others by kind, type, or quality.”

In programming languages we often say “An object is an instance of a class”. This means that, using a class, I can create many objects and they all share methods and properties.

Since objects can be enhanced, as we’ve seen earlier, there are may ways to create objects sharing methods and properties. But we want the simplest one.

Fortunately ECMAScript 6 provides the keyword class, making it very easy to create a class:

class Point {
  constructor(x, y) {
    this.x = x;
    this.y = y;
  }

  toString() {
    return `(${this.x},${this.y})`;
  }
}

So, in my opinion, that is the best way of declaring classes in JavaScript. Classes are often related to inheritance:

class Point extends HasXY {
  constructor(x, y) {
    super(x, y);
  }

  toString() {
    return `(${this.x},${this.y})`;
  }
}

As you can see in the example above, to extend another class it is enough to use the keyword extends .

You can create an object from a class using the new operator:

const p = new Point(1,1);
console.log(p instanceof Point); // prints true

A good object oriented way of defining classes should provide:

• a simple syntax to declare a class
• a simple way to access to the current instance, a.k.a. this
• a simple syntax to extend a class
• a simple way to access the super class instance, a.k.a. super
• possibly, a simple way of telling if an object is an instance of a particular class. obj instanceof AClass should return true if that object is an instance of that class.

The new class syntax provides all the points above.

Before the introduction of the class keyword, what was the way to define a class in JavaScript?

In addition, what really is a class in JavaScript? Why do we often speak about prototypes?

Classes in JavaScript 5

From Mozilla MDN page about classes:

JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript’s existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript.

The key concept here is prototype-based inheritance. Since there is a lot of misunderstanding on what that kind of inheritance is, I will proceed step by step, moving from class keyword to function keyword.

class Shape {}
console.log(typeof Shape);
// prints function

It seems that class and function are related. Is class just an alias for function ? No, it isn’t.

Shape(2);
// Uncaught TypeError: Class constructor Shape cannot be invoked without 'new'

So, it seems that the people who introduced class keyword wanted to tell us that a class is a function that must be called using the new operator.

var Shape = function Shape() {} // Or just function Shape(){}
var aShape = new Shape();
console.log(aShape instanceof Shape);
// prints true

The example above shows that we can use function to declare a class. We cannot, however, force the user to call the function using the new operator. It is possible to throw an exception if the new operator wasn’t used to call the function.

Anyway I suggest you don’t put that check in every function that acts as a class. Instead use this convention: any function whose name begins with a capital letter is a class and must be called using the new operator.

Let’s move on, and find out what a prototype is:

class Shape {
  getName() {
    return 'Shape';
  }
}
console.log(Shape.prototype.getName);
// prints function getName() ...

Each time you declare a method inside a class, you actually add that method to the prototype of the corresponding function. The equivalent in JS 5 is:

function Shape() {}
Shape.prototype.getName = function getName() {
  return 'Shape';
};
console.log(new Shape().getName()); // prints Shape

Sometimes the class-functions are called constructors because they act like constructors in a regular class.

You may wonder what happens if you declare a static method:

class Point {
  static distance(p1, p2) {
    // ...
  }
}

console.log(Point.distance); // prints function distance
console.log(Point.prototype.distance); // prints undefined

Since static methods are in a 1 to 1 relation with classes, the static function is added to the constructor-function, not to the prototype.

Let’s recap all these concepts in a simple example:

function Point(x, y) {
  this.x = x;
  this.y = y;
}

Point.prototype.toString = function toString() {
  return '(' + this.x + ',' + this.y + ')';
};
Point.distance = function distance() {
  // ...
}

console.log(new Point(1,2).toString()); // prints (1,2)
console.log(new Point(1,2) instanceof Point); // prints true

Up to now, we have found a simple way to:

• declare a function that acts as a class
• access the class instance using the this keyword
• create objects that are actually an instance of that class (new Point(1,2) instanceof Point returns true )

But what about inheritance? What about accessing the super class?

class Hello {
  constructor(greeting) {
    this._greeting = greeting;
  }

  greeting() {
    return this._greeting;
  }
}

class World extends Hello {
  constructor() {
    super('hello');
  }

  worldGreeting() {
    return super.greeting() + ' world';
  }
}

console.log(new World().greeting()); // Prints hello
console.log(new World().worldGreeting()); // Prints hello world

Above is a simple example of inheritance using ECMAScript 6, below the same example using the the so called prototype inheritance:

function Hello(greeting) {
  this._greeting = greeting;
}

Hello.prototype.greeting = function () {
  return this._greeting;
};

function World() {
  Hello.call(this, 'hello');
}

// Copies the super prototype
World.prototype = Object.create(Hello.prototype);
// Makes constructor property reference the sub class
World.prototype.constructor = World;

World.prototype.worldGreeting = function () {
  const hello = Hello.prototype.greeting.call(this);
  return hello + ' world';
};

console.log(new World().greeting()); // Prints hello
console.log(new World().worldGreeting()); // Prints hello world

This way of declaring classes is also suggested in the Mozilla MDN example here.

Using the class syntax, we deduced that creating classes involves altering the prototype of a function. But why is that so? To answer this question we must understand what the new operator actually does.

New operator in JavaScript

The new operator is explained quite well in the Mozilla MDN page here. But I can provide you with a relatively simple example that emulates what the new operator does:

function customNew(constructor, ...args) {
  const obj = Object.create(constructor.prototype);
  const result = constructor.call(obj, ...args);

  return result instanceof Object ? result : obj;
}

function Point() {}
console.log(customNew(Point) instanceof Point); // prints true

Note that the real new algorithm is more complex. The purpose of the example above is just to explain what happens when you use the new operator.

When you write new Point(1,2)what happens is:

• The Point prototype is used to create an object.
• The function constructor is called and the just created object is passed as the context (a.k.a. this) along with the other arguments.
• If the constructor returns an Object, then this object is the result of the new, otherwise the object created from the prototype is the result.

So, what does prototype inheritance mean? It means that you can create objects that inherit all the properties defined in the prototype of the function that was called with the new operator.

If you think of it, in a classical language the same process happens: when you create an instance of a class, that instance can use the this keyword to access to all the functions and properties (public) defined in the class (and the ancestors). As opposite to properties, all the instances of a class will likely share the same references to the class methods, because there is no need to duplicate the method’s binary code.

Functional programming

Sometimes people say that JavaScript is not well suited for Object Oriented programming, and you should use functional programming instead.

While I don’t agree that JS is not suited for O.O.P, I do think that functional programming is a very good way of programming. In JavaScript functions are first class citizens (e.g. you can pass a function to another function) and it provides features like bind , call or apply which are base constructs used in functional programming.

In addition RX programming could be seen as an evolution (or a specialization) of functional programming. Have a look to RxJs here.

Conclusion

Use, when possible, ECMAScript 6 class syntax:

class Point {
  toString() {
    //...
  }
}

or use function prototypes to define classes in ECMAScript 5:

function Point() {}
Point.prototype.toString = function toString() {
  // ...
}

Hope you enjoyed the reading!

Have you noticed how the same cliche questions always get asked at job interviews — over and over again?

I’m sure you know what I mean.

For example:

Where do you see yourself in five years?

or, even worse:

What do you consider to be your greatest weakness?

Ugh…give me a break. I consider answering this question a great weakness! Anyway, not my point.

As trivial as questions like these may be, they are important because they give clues about you. Your current state of mind, your attitude, your perspective.

When answering, you should be careful, as you may reveal something you later regret.

Today I want to talk about a similar type of question in the programming world:

What are the main principles of Object-Oriented Programming?

I’ve been on both sides of this question. It’s one of those topics that gets asked so often that you can’t allow yourself to not know.

Junior and entry-level developers usually have to answer it. Because it’s an easy way for the interviewer to tell three things:

1. Did the candidate prepare for this interview?
   Bonus points if you hear an answer immediately — it shows a serious approach.
2. Is the candidate past the tutorial phase?
   Understanding the principles of Object-Oriented Programming (OOP) shows you’ve gone beyond copy and pasting from tutorials — you already see things from a higher perspective.
3. Is the candidate’s understanding deep or shallow?
   The level of competence on this question often equals the level of competence on most other subjects. Trust me.

How an entry-level developer looks like after nailing this question!

The four principles of object-oriented programming are encapsulation, abstraction, inheritance, and polymorphism.

These words may sound scary for a junior developer. And the complex, excessively long explanations in Wikipedia sometimes double the confusion.

That’s why I want to give a simple, short, and clear explanation for each of these concepts. It may sound like something you explain to a child, but I would actually love to hear these answers when I conduct an interview.

Encapsulation

Say we have a program. It has a few logically different objects which communicate with each other — according to the rules defined in the program.

Encapsulation is achieved when each object keeps its state private, inside a class. Other objects don’t have direct access to this state. Instead, they can only call a list of public functions — called methods.

So, the object manages its own state via methods — and no other class can touch it unless explicitly allowed. If you want to communicate with the object, you should use the methods provided. But (by default), you can’t change the state.

Let’s say we’re building a tiny Sims game. There are people and there is a cat. They communicate with each other. We want to apply encapsulation, so we encapsulate all “cat” logic into a Cat class. It may look like this:

You can feed the cat. But you can’t directly change how hungry the cat is.

Here the “state” of the cat is the private variables mood, hungry and energy. It also has a private method meow(). It can call it whenever it wants, the other classes can’t tell the cat when to meow.

What they can do is defined in the public methods sleep(), play() and feed(). Each of them modifies the internal state somehow and may invoke meow(). Thus, the binding between the private state and public methods is made.

This is encapsulation.

Abstraction

Abstraction can be thought of as a natural extension of encapsulation.

In object-oriented design, programs are often extremely large. And separate objects communicate with each other a lot. So maintaining a large codebase like this for years — with changes along the way — is difficult.

Abstraction is a concept aiming to ease this problem.

Applying abstraction means that each object should only expose a high-level mechanism for using it.

This mechanism should hide internal implementation details. It should only reveal operations relevant for the other objects.

Think — a coffee machine. It does a lot of stuff and makes quirky noises under the hood. But all you have to do is put in coffee and press a button.

Preferably, this mechanism should be easy to use and should rarely change over time. Think of it as a small set of public methods which any other class can call without “knowing” how they work.

Another real-life example of abstraction?
Think about how you use your phone:

Cell phones are complex. But using them is simple.

You interact with your phone by using only a few buttons. What’s going on under the hood? You don’t have to know — implementation details are hidden. You only need to know a short set of actions.

Implementation changes — for example, a software update — rarely affect the abstraction you use.

Inheritance

OK, we saw how encapsulation and abstraction can help us develop and maintain a big codebase.

But do you know what is another common problem in OOP design?

Objects are often very similar. They share common logic. But they’re not entirely the same. Ugh…

So how do we reuse the common logic and extract the unique logic into a separate class? One way to achieve this is inheritance.

It means that you create a (child) class by deriving from another (parent) class. This way, we form a hierarchy.

The child class reuses all fields and methods of the parent class (common part) and can implement its own (unique part).

For example:

A private teacher is a type of teacher. And any teacher is a type of Person.

If our program needs to manage public and private teachers, but also other types of people like students, we can implement this class hierarchy.

This way, each class adds only what is necessary for it while reusing common logic with the parent classes.

Polymorphism

We’re down to the most complex word! Polymorphism means “many shapes” in Greek.

So we already know the power of inheritance and happily use it. But there comes this problem.

Say we have a parent class and a few child classes which inherit from it. Sometimes we want to use a collection — for example a list — which contains a mix of all these classes. Or we have a method implemented for the parent class — but we’d like to use it for the children, too.

This can be solved by using polymorphism.

Simply put, polymorphism gives a way to use a class exactly like its parent so there’s no confusion with mixing types. But each child class keeps its own methods as they are.

This typically happens by defining a (parent) interface to be reused. It outlines a bunch of common methods. Then, each child class implements its own version of these methods.

Any time a collection (such as a list) or a method expects an instance of the parent (where common methods are outlined), the language takes care of evaluating the right implementation of the common method — regardless of which child is passed.

Take a look at a sketch of geometric figures implementation. They reuse a common interface for calculating surface area and perimeter:

Triangle, Circle, and Rectangle now can be used in the same collection

Having these three figures inheriting the parent Figure Interface lets you create a list of mixed triangles, circles, and rectangles. And treat them like the same type of object.

Then, if this list attempts to calculate the surface for an element, the correct method is found and executed. If the element is a triangle, triangle’s CalculateSurface() is called. If it’s a circle — then circle’s CalculateSurface() is called. And so on.

If you have a function which operates with a figure by using its parameter, you don’t have to define it three times — once for a triangle, a circle, and a rectangle.

You can define it once and accept a Figure as an argument. Whether you pass a triangle, circle or a rectangle — as long as they implement CalculateParamter(), their type doesn’t matter.

I hope this helped. You can directly use these exact same explanations at job interviews.

If you find something still difficult to understand — don’t hesitate to ask in the comments below.

What’s next?

Being prepared to answer one of the all-time interview question classics is great — but sometimes you never get called for an interview.

Next, I’ll focus on what employers want to see in a junior developer and how to stand out from the crowd when job hunting.

Stay tuned.

Did you like the read? If you'd like to support me, you can buy me a coffee :)

Demonstrated by implementing a Role-Playing Game’s classes

_[Zeppelin by Richard Wright](https://www.artstation.com/artwork/rO8e6" rel="noopener" target="blank" title=")

Introduction

Most modern programming languages support and encourage object-oriented programming (OOP). Even though lately we seem to be seeing a slight shift away from this, as people start using languages which are not heavily influenced by OOP (such as Go, Rust, Elixir, Elm, Scala), most still have objects. The design principles we are going to outline here apply to non-OOP languages as well.

To succeed in writing clear, high-quality, maintainable and extendable code you will need to know about design principles that have proven themselves effective over decades of experience.

Disclosure: The example we are going to be going through will be in Python. Examples are there to prove a point and may be sloppy in other, obvious ways.

Object Types

Since we are going to be modelling our code around objects, it would be useful to differentiate between their different responsibilities and variations.

There are three type of objects:

1. Entity Object

This object generally corresponds to some real-world entity in the problem space. Say we’re building a role-playing game (RPG), an entity object would be our simple Hero class:

These objects generally contain properties about themselves (such as health or mana) and are modifiable through certain rules.

2. Control Object

Control objects (sometimes also called Manager objects) are responsible for the coordination of other objects. These are objects that control and make use of other objects. A great example in our RPG analogy would be the Fight class, which controls two heroes and makes them fight.

Encapsulating the logic for a fight in such a class provides you with multiple benefits: one of which is the easy extensibility of the action. You can very easily pass in a non-player character (NPC) type for the hero to fight, provided it exposes the same API. You can also very easily inherit the class and override some of the functionality to meet your needs.

3. Boundary Object

These are objects which sit at the boundary of your system. Any object which takes input from or produces output to another system — regardless if that system is a User, the internet or a database — can be classified as a boundary object.

These boundary objects are responsible for translating information into and out of our system. In an example where we take User commands, we would need the boundary object to translate a keyboard input (like a spacebar) into a recognizable domain event (such as a character jump).

Bonus: Value Object

Value objects represent a simple value in your domain. They are immutable and have no identity.

If we were to incorporate them into our game, a Money or Damage class would be a great fit. Said objects let us easily distinguish, find and debug related functionality, while the naive approach of using a primitive type — an array of integers or one integer — does not.

They can be classified as a subcategory of **Entity** objects.

Key Design Principles

Design principles are rules in software design that have proven themselves valuable over the years. Following them strictly will help you ensure your software is of top-notch quality.

Abstraction

Abstraction is the idea of simplifying a concept to its bare essentials in some context. It allows you to better understand the concept by stripping it down to a simplified version.

The examples above illustrate abstraction — look at how the Fight class is structured. The way you use it is as simple as possible — you give it two heroes as arguments in instantiation and call the fight() method. Nothing more, nothing less.

Abstraction in your code should follow the rule of least surprise. Your abstraction should not surprise anybody with needless and unrelated behavior/properties. In other words — it should be intuitive.

Note that our Hero#take_damage() function does not do something unexpected, like delete our character upon death. But we can expect it to kill our character if his health goes below zero.

Encapsulation

Encapsulation can be thought of as putting something inside a capsule — you limit its exposure to the outside world. In software, restricting access to inner objects and properties helps with data integrity.

Encapsulation black-boxes inner logic and makes your classes easier to manage, because you know what part is used by other systems and what isn’t. This means that you can easily rework the inner logic while retaining the public parts and be sure that you have not broken anything. As a side-effect, working with the encapsulated functionality from the outside becomes simpler as you have less things to think about.

In most languages, this is done through the so-called access modifiers (private, protected, and so on). Python is not the best example of this, as it lacks such explicit modifiers built into the runtime, but we use conventions to work around this. The _ prefix to the variables/methods denote them as being private.

For example, imagine we change our Fight#_run_attack method to return a boolean variable that indicates if the fight is over rather than raise an exception. We will know that the only code we might have broken is inside the Fight class, because we made the method private.

Remember, code is more frequently changed than written anew. Being able to change your code with as clear and little repercussions as possible is flexibility you want as a developer.

Decomposition

Decomposition is the action of splitting an object into multiple separate smaller parts. Said parts are easier to understand, maintain and program.

Imagine we wanted to incorporate more RPG features like buffs, inventory, equipment and character attributes on top of our Hero:

I assume you can tell this code is becoming pretty messy. Our Hero object is doing too much stuff at once and this code is becoming pretty brittle as a result of that.

For example, one stamina point is worth 5 health. If we ever want to change this in the future to make it worth 6 health, we’d need to change the implementation in multiple places.

The answer is to decompose the Hero object into multiple smaller objects which each encompass some of the functionality.

A cleaner architecture

Now, after decomposing our Hero object’s functionality into HeroAttributes, HeroInventory, HeroEquipmentand HeroBuff objects, adding future functionality will be easier, more encapsulated and better abstracted. You can tell our code is way cleaner and clearer on what it does.

There are three types of decomposition relationships:

• association — Defines a loose relationship between two components. Both components do not depend on one another but may work together.

Example: Hero and a Zone object.

• aggregation — Defines a weak “has-a” relationship between a whole and its parts. Considered weak, because the parts can exist without the whole.

Example: HeroInventory and Item.
A HeroInventory can have many Items and an Item can belong to any HeroInventory(such as trading items).

• composition — A strong “has-a” relationship where the whole and the part cannot exist without each other. The parts cannot be shared, as the whole depends on those exact parts.

Example: Hero and HeroAttributes.
These are the Hero’s attributes — you cannot change their owner.

Generalization

Generalization might be the most important design principle — it is the process of extracting shared characteristics and combining them in one place. All of us know about the concept of functions and class inheritance —both are a kind of generalization.

A comparison might clear things up: while abstraction reduces complexity by hiding unnecessary detail, generalization reduces complexity by replacing multiple entities which perform similar functions with a single construct.

In the given example, we have generalized our common Hero and NPC classes’ functionality into a common ancestor called Entity. This is always achieved through inheritance.

Here, instead of having our NPC and Hero classes implement all the methods twice and violate the DRY principle, we reduced the complexity by moving their common functionality into a base class.

As a forewarning — do not overdo inheritance. Many experienced people recommend you favor composition over inheritance.

Inheritance is often abused by amateur programmers, probably because it is one of the first OOP techniques they grasp due to its simplicity.

Composition

Composition is the principle of combining multiple objects into a more complex one. Practically said — it is creating instances of objects and using their functionality instead of directly inheriting it.

An object that uses composition can be called a composite object. It is important that this composite is simpler than the sum of its peers. When combining multiple classes into one we want to raise the level of abstraction higher and make the object simpler.

The composite object’s API must hide its inner components and the interactions between them. Think of a mechanical clock, it has three hands for showing the time and one knob for setting — but internally contains dozens of moving and inter-dependent parts.

As I said, composition is preferred over inheritance, which means you should strive to move common functionality into a separate object which classes then use — rather than stash it in a base class you’ve inherited.

Let’s illustrate a possible problem with over-inheriting functionality:

We just added movement to our game.

As we learned, instead of duplicating the code we used generalization to put the move_right and move_left functions into the Entity class.

Okay, now what if we wanted to introduce mounts into the game?

a good mount :)

Mounts would also need to move left and right but do not have the ability to attack. Come to think of it — they might not even have health!

I know what your solution is:

Simply move the move logic into a separate MoveableEntity or MoveableObject class which only has that functionality. The Mount class can then inherit that.

Then, what do we do if we want mounts that have health but cannot attack? More splitting up into subclasses? I hope you can see how our class hierarchy would begin to become complex even though our business logic is still pretty simple.

A somewhat better approach would be to abstract the movement logic into a Movement class (or some better name) and instantiate it in the classes which might need it. This will nicely package up the functionality and make it reusable across all sorts of objects not limited to Entity.

Hooray, composition!

Critical Thinking Disclaimer

Even though these design principles have been formed through decades of experience, it is still extremely important that you are able to think critically before blindly applying a principle to your code.

Like all things, too much can be a bad thing. Sometimes principles can be taken too far, you can get too clever with them and end up with something that is actually harder to work with.

As an engineer, your main trait is to critically evaluate the best approach for your unique situation, not blindly follow and apply arbitrary rules.

Cohesion, Coupling & Separation of Concerns

Cohesion

Cohesion represents the clarity of responsibilities within a module or in other words — its complexity.

If your class performs one task and nothing else, or has a clear purpose — that class has high cohesion. On the other hand, if it is somewhat unclear in what it’s doing or has more than one purpose — it has low cohesion.

You want your classes to have high cohesion. They should have only one responsibility and if you catch them having more — it might be time to split it.

Coupling

Coupling captures the complexity between connecting different classes. You want your classes to have as little and as simple connections to other classes as possible, so that you can swap them out in future events (like changing web frameworks). The goal is to have loose coupling.

In many languages this is achieved by heavy use of interfaces —they abstract away the specific class handling the logic and represent a sort of adapter layer in which any class can plug itself in.

Separation of Concerns

Separation of Concerns (SoC) is the idea that a software system must be split into parts that do not overlap in functionality. Or as the name says — concern — A general term about anything that provides a solution to a problem — must be separated into different places.

A web page is a good example of this — it has its three layers (Information, Presentation and Behavior) separated into three places (HTML, CSS and JavaScript respectively).

If you look again at the RPG Hero example, you will see that it had many concerns at the very beginning (apply buffs, calculate attack damage, handle inventory, equip items, manage attributes). We separated those concerns through decomposition into more cohesive classes which abstract and encapsulate their details. Our Hero class now acts as a composite object and is much simpler than before.

Payoff

Applying such principles might look overly complicated for such a small piece of code. The truth is it a must for any software project that you plan to develop and maintain in the future. Writing such code has a bit of overhead at the very start but pays off multiple times in the long run.

These principles ensure our system is more:

• Extendable: High cohesion makes it easier to implement new modules without concern of unrelated functionality. Low coupling means that a new module has less stuff to connect to therefore it is easier to implement.
• Maintainable: Low coupling ensures a change in one module will generally not affect others. High cohesion ensures a change in system requirements will require modifying as little number of classes as possible.
• Reusable: High cohesion ensures a module’s functionality is complete and well-defined. Low coupling makes the module less dependent on the rest of the system, making it easier to reuse in other software.

Summary

We started off by introducing some basic high-level object types (Entity, Boundary and Control).

We then learned key principles in structuring said objects (Abstraction, Generalization, Composition, Decomposition and Encapsulation).

To follow up we introduced two software quality metrics (Coupling and Cohesion) and learned about the benefits of applying said principles.

I hope this article provided a helpful overview of some design principles. If you wish to further educate yourself in this area, here are some resources I would recommend.

Further Readings

Design Patterns: Elements of Reusable Object-Oriented Software —Arguably the most influential book in the field. A bit dated in its examples (C++ 98) but the patterns and ideas remain very relevant.

Growing Object-Oriented Software Guided by Tests — A great book which shows how to practically apply principles outlined in this article (and more) by working through a project.

Effective Software Design — A top notch blog containing much more than design insights.

Software Design and Architecture Specialization — A great series of 4 video courses which teach you effective design throughout its application on a project that spans all four courses.

If this overview has been informative to you, please consider giving it the amount of claps you think it deserves so that more people can stumble upon it and gain value from it.