The key features of encapsulation are as follows:

The major features of polymorphism are as follows:

In the following example, strings, tuples, or lists can all be accessed with an integer index. This shows how Python demonstrates polymorphism in built-in types:

a = "John"
b = (1,2,3)
c = [3,4,6,8,9]
print(a[1], b[0], c[2])

The following points help us understand the inheritance process better:

In the following code example, class A is the base class and class B derives its features from class A. So, the methods of class A can be accessed by the object of class B:

class A:
    def a1(self):
        print("a1")

class B(A):
    def b(self):
        print("b")


b = B()
b.a1()

The key features of abstraction are as follows:

In the following example, internal details of the Adder class are abstracted with the add() method:

class Adder:
    def __init__(self):
        self.sum = 0
    def add(self, value):
        self.sum += value

acc = Adder()
for i in range(99):
    acc.add(i)


print(acc.sum)

Composition refers to the following points:

In the following example, the object of class A is composited under class B:

class A(object):
    def a1(self):
        print("a1")

class B(object):
    def b(self):
        print("b")
        A().a1()


objectB = B()
objectB.b()

The open/close principle states that classes or objects and methods should be open for extension but closed for modifications.

What this means in simple language is, when you develop your software application, make sure that you write your classes or modules in a generic way so that whenever you feel the need to extend the behavior of the class or object, then you shouldn't have to change the class itself. Rather, a simple extension of the class should help you build the new behavior.

For example, the open/close principle is manifested in a case where a user has to create a class implementation by extending the abstract base class to implement the required behavior instead of changing the abstract class.

Advantages of this design principle are as follows:

The inversion of control principle states that high-level modules shouldn't be dependent on low-level modules; they should both be dependent on abstractions. Details should depend on abstractions and not the other way round.

This principle suggests that any two modules shouldn't be dependent on each other in a tight way. In fact, the base module and dependent module should be decoupled with an abstraction layer in between.

This principle also suggests that the details of your class should represent the abstractions. In some cases, the philosophy gets inverted and implementation details itself decide the abstraction, which should be avoided.

Advantages of the inversion of control principle are as follows:

As the interface segregation principle states, clients should not be forced to depend on interfaces they don't use.

This principle talks about software developers writing their interfaces well. For instance, it reminds the developers/architects to develop methods that relate to the functionality. If there is any method that is not related to the interface, the class dependent on the interface has to implement it unnecessarily.

For example, a Pizza interface shouldn't have a method called add_chicken(). The Veg Pizza class based on the Pizza interface shouldn't be forced to implement this method.

Advantages of this design principle are as follows:

As the single responsibility principle states, a class should have only one reason to change.

This principle says that when we develop classes, it should cater to the given functionality well. If a class is taking care of two functionalities, it is better to split them. It refers to functionality as a reason to change. For example, a class can undergo changes because of the difference in behavior expected from it, but if a class is getting changed for two reasons (basically, changes in two functionalities), then the class should be definitely split.

Advantages of this design principle are as follows:

The substitution principle states that derived classes must be able to completely substitute the base classes.

This principle is pretty straightforward in the sense that it says when application developers write derived classes, they should extend the base classes. It also suggests that the derived class should be as close to the base class as possible so much so that the derived class itself should replace the base class without any code changes.

The advantages of design patterns are as follows:

Not every piece of code or design can be termed as a design pattern. For example, a programming construct or data structure that solves one problem can't be termed as a pattern. Let's understand terms in a very simplistic way below:

To use design patterns efficiently, application developers must be aware of the context where design patterns apply. We can classify the context into the following main categories:

The following are the properties of Creational patterns:

An example of a creational pattern is the Singleton pattern.

The following are the properties of Structural patterns:

An example of a behavior pattern is the Adapter pattern.

The following are the properties of Behavioral patterns:

An example of a behavioral pattern is the Observer pattern.