Tag: OOP

behavioral pattern, Java, OOP, Strategy

Design Patterns: Strategy

The Strategy design pattern belongs to Behavioral family. It helps us to change behavior at runtime. The definition from Gang of Four book is following.
[quote name=”Gang of Four”]Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from client that use it.[/quote]

When do we have to use it

  • We use Strategy pattern when we need to hide the implementation of an algorithm.
  • When we have many related classes which differ in their behavior providing a way to configure another class with one of many behaviors.
  • Using Strategy we avoid to expose the complexity of an algorithm.
  • If you have many conditionals in front of you, and each one contains different behaviors of a class, then it is time to use Strategy pattern.

How do I use it

The Strategy design pattern is really easy to use. We just need to provide an Interface. This Interface is going to be used creating multiple implementations of different algorithms.
After implementing our algorithms we just need to create a context (Composition) which is going to use our interface gaining access to algorithms.

Example

Supposing that we develop a game, there is a character and has two or many special powers to use.

Let’s start with the interface and its implementations.

Now we are going to create the context class.

Let’s run an example.

Output:

You can download the source code from GitHub.

Design Patterns, Flyweight, Java, OOP, structural design patterns

Design Patterns: Flyweight

In this article, we are going to delve into another Structural Pattern and it is called Flyweight. Let’s start with the definition from Gang of Four Book.

[quote name=”GoF”]Facilitates the reuse of many fine-grained objects, making the utilization of large numbers of objects more efficient.[/quote]

Flyweight pattern is used to reduce the number of objects that are created. So, memory usage is decreased as well. Apart from that, a new keyword is not needed in order to create the same object again and again.

Every time that an object is created, it is stored, and if the same object is asked, then Flyweight gives it back to you. Otherwise, a new object is created and stored for future usage.

This pattern uses intrinsic and extrinsic properties.

What are intrinsic and extrinsic properties

Intrinsic properties help us make the object unique, whereas extrinsic properties are set by the client to perform a specific operation.

When do we have to use Flyweight Pattern

In case that we need to create many objects that are very similar and these objects cost a lot to be generated, it is a very good opportunity to reduce memory and increase performance by using the Flyweight Pattern.

Example

Let’s suppose that we are making a platform game. The star of the game has to kill all the enemies. Enemies are generated at the run time and they are very similar.

Using the new keyword in order to create a new enemy at the run time is too expensive. Our game is going to lack in memory and become slow if we are not careful.

It is time to create some enemies with the Flyweight design pattern.

We start with the Enemy interface.

The Next class implements the Enemy interface.

Let’s create different types of weapons.

It is time to create a Factory class. This class returns an existing enemy if an enemy of a given type exists. Otherwise, it creates a new enemy, stores it in hashTable for future usage, and returns it.

Let’s run an example.

Output:

You can download the source code from GitHub.

composite, Design Patterns, Java, OOP, structural design patterns

Design Patterns: Composite

The Composite is another design pattern that belongs to the Structural Patterns family. We use this pattern when we want to group components inside a larger component. In other words, we can build a hierarchy of objects.

A definition by GoF:
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

A basic structure of Composite pattern:
Component

  • Declares an interface for objects in the composition.
  • Implements the default behavior for the interface common to all classes.

Leaf

  • It implements the behavior for objects in the composition.

Composite

  • It stores child components and defines the behavior for components having children.

Client

  • Manipulates objects in composition through the Component interface.

Structure

A composite pattern is made easily. We just create an interface or abstract class which is going to contain all methods for “Composite” and “Leaf” classes. Then, we just need to implement our classes which are going to contain some operations of Component.

When we use Component Pattern

We use it when we want to represent hierarchies of objects.

Example

Let’s get an example with a real hierarchy. We are going to represent the pride of lions. It is a perfect example that we can see how the hierarchy works.

So, we have an interface “Panthera” and three classes that are going to implement the Panthera interface. These classes are going to implement only some operations of the Panthera interface each time.
MaleLion and FemaleLion classes are “composite” and have children in their hierarchy.

CubLion class is a “Leaf” class because it implements only the behavior for objects in composition and it doesn’t have children objects.

Let’s start with the Panthera interface.

MaleLion FemaleLion and CubLion classes are following.

Now we are ready to build our first pride of lions.

Output:

You can download the source code from GitHub.

facade, Java, OOP, structural design pattern

Design Patterns: Facade

The facade design pattern is known as a structural design pattern.

The facade pattern is used to reduce complexity among classes. One way to achieve this goal is by providing a simplified interface to implement general facilities among objects.

That means we can use the facade in order to describe and implement the actions of objects. We can write a complex piece of code that performs an explicit task using some objects, and we are able to use this code again and again through facade without writing the same code all the time.

It is ideal to use it when we have some complex libraries which take effort to use. It provides us with a simpler interface to use those libraries without being concerned about how these libraries work internally.

Using facade, objects are decoupled, each promoting independence. It’s something like an entry point to our objects and also we are able to establish communication among them solely through the facade. That is how we can achieve decoupling.

The facade is a very easy design pattern to learn and that’s why you need to be careful using it. It is really easy to diverge from the right usage. This pattern has to be used not as a layer which handles data and takes decisions, but as a very high layer of the interface that just helps us simplify objects. For example, we need to execute a complex task that a person wants to book a flight and a hotel. If we don’t use facade, we have to implement every single task like date availability, destination, payment methods, and so on. On the other hand, using the facade, we are able to call only one method of facade class that performs all these actions for us.

How to use it

We can create an interface that is going to keep different implementations of our complex objects. Then we can communicate with these objects through the facade’s interface and the only thing that we need to be aware is to know the different implementations the interface offers us.

Example

Let’s see a real-world example. We have a web service that a user can log in and read some articles only if he has paid the subscription.

Let’s start with the user’s class.

The class which checks user’s credentials so as to give permissions to a user in the platform is the following.

The class checks if the user has paid his subscription and he is valid.

The class checks if the user has access to a specific article page.

Now the interface for the facade.

The implementation of the interface.

Facade pattern testing:

Output:

You can download the source code from GitHub.

behavioral pattern, Java, observer pattern, OOP, Programming, Software Engineering

Design Patterns: Observer

An observer is a pattern that falls under Behavioral Patterns. It is used when there is one-to-many relationships between objects. So, when an object’s state is changed then all its dependent objects are notified automatically.

When do you have to use Observer

  • When a change to one object requires to notify other objects.
  • We don’t need to be aware of how many objects need to be changed.
  • We don’t want these objects tightly coupled.

How to use it

The concept behind the Observer pattern is simple. We have a subject that is going to keep track of the observers. Every time this subject changes, all its observers are notified automatically. The subject contains some methods that allow observers to be registered or unregistered.

When the state of the subject changes then the subject has to notify all the observers which are registered.

This pattern is so flexible that sometimes we want to change this behavior and let observers ask the subject for the state and if it is changed, then the observer acts appropriately.

Example

Let’s suppose that we are at a university and we want to update every student who is registered in a course. If the student is registered in a specific course then every time the state of the course is changed, registered students will receive a notification.

Start with the Subject interface

We will implement the Subject interface.

Let’s create one more interface named Observer

StudentObserver class is going to implement the interface above.

Last but not least StudentObserver we have one more class named Email, and as you can imagine we are going to use this class so as to send emails to students.

Now we are ready to use these classes.

Output:

You can download the source code from GitHub.

Decorator, Design Patterns, Java, OOP, structural patterns

Design Patterns: Decorator

Hi guys, one more design pattern, and today I am going to continue with a Structural Pattern. In particular, I will introduce you to the Decorator design pattern. Sometimes this pattern is also known as Wrapper.

A decorator is a pattern that adds new features to an existing object without altering anything from the original object.

When do you have to use a Decorator?

  1. When we want to add functionalities in an object but not to an entire class dynamically and transparently.
  2. When we want to add functionalities that are not common to every object.
  3. When it doesn’t need to extend from a class because we don’t want to inherit a bunch of useless methods.

How to use it

Maybe the first way that comes to everyone’s mind in order to add new functions is through inheritance. The truth is that it is not the best option because you inherit a whole class that maybe you don’t need. You cannot control very well how and when you need a decorator.

A decorator offers a better solution to this problem. It gives us the ability to enclose an object that we want to add more functionalities to, to another object which is going to append the desire features. The decorator conforms to the interface of the object that we want to enhance.

Why the Decorator Pattern?

I have already given you some very important reasons why you have to use this pattern and how. There is one more thing. This pattern is an excellent example of the open/closed principle.

The open/closed principle says an object must be open for extensions but closed for modifications.

Example

It is time to get an example. I am going to create a sword, it is a common word and I want to decorate this sword with some magical powers. So, I am going to transform a common sword to an Excalibur sword.

I start with an interface named Sword.

Let’s implement this interface.

If we run this code and call the attributes() method we get the following output.

Now let’s try to decorate this object with new features and giving it the magical power. I start with an abstract class named SwordDecorator that implements the Sword interface.

As you can see this abstract class not only implements the Sword but has-a sword so as to append new actions in the desire object.
Let’s continue with ExcaliburSword that extends SwordDecorator.

So, this class takes as an argument a common sword and transforms it into an Excalibur sword by adding a magical power which is to blind its enemies and its power is increased from 1 which is a common sword to 10!

Let’s run this code

Output:

You can download the source code from GitHub.

Other useful resources:

code.tutsplus.com

Design Patterns, Game Development, Java, OOP, Programming, Software Engineering

Design Patterns: Dependency Injection

What Dependency Injection is. Let’s imagine an object that does a specific function. Now let’s imagine a second object that takes the first object as an argument. This object cannot function or can function partially without the first one. When this happens, it’s called Dependency Injection.

Dependency Injection is a design pattern and we want to use it when an object is dependent on another object. Doing that, we are able to enhance our code with new functionalities without changing the existing code. So, our code is maintainable and extendable while allowing our program to be loosely coupled.

There are 3 ways to perform dependency injection.

The first one is called Constructor Injection. In this case, the class takes the dependent object through the constructor.

Sample Code:

Next is Setter Injection. In this case, a class that needs an external object to work takes it from a setter method. Thus, we can pass the dependent object as an argument only if there is a need for that. Dependency Injection is optional in this case.

Sample Code:

The third one is called Interface Injection. In this case, we create an interface class that has a function that takes as argument an object.

Sample Code:

Sample Code

It would be better if we continued with an example of how to use dependency injection.

We are going to create a character for a game who is modular and we can change various things like hair color, t-shirts, head size, etc. In our case, we will see only the head size as an example. So, the user will be able to change the character’s head to a big one or a regular one.

Let’s start with our interface class which is named Head.

The next two classes will implement the Head interface creating either a big head or a regular head.

The next step is to create a player who is going to take an object of BigHead or RegularHead classes as an argument.

Let’s start with the Player interface.

The class above implements the Player interface and it creates a player either with a big head or with a regular one, depending on the class that it will take as an argument.

Finally, we will create one more interface that we will use in order to implement Dependency Injection.

As we can see, each one of the two classes above creates a Player object depending on the argument.

The last method does a print in our screen.

Output:
Hi, I am the player with a big head !
Hi, I am the player with a regular head !

You can download the source code from GitHub.

Some Other Useful Resources

http://fabien.potencier.org/what-is-dependency-injection.html
https://www.martinfowler.com/articles/injection.html
http://www.procata.com/talks/phptek-may2007-dependency.pdf

http://www.javacreed.com/why-should-we-use-dependency-injection/
http://tutorials.jenkov.com/dependency-injection/dependency-injection-containers.html

creational patterns, Design Patterns, Factory, Game Developer, Game Development, Java, OOP, Programming, Software Engineering

Design Patterns: Factory

The factory is one more design pattern that comes under creational patterns. Thus, this pattern is able to make our code less complex and it gives us the opportunity to get an object without using the “new” operator. The factory is quite simple in use.

The factory is used when there is a need to hide the way that an object instantiated and it’s complex or many dependencies are needed.

Also, as Head First: Design Patterns book refers

[quote name=””]Instantiation is an activity that shouldn’t always be done in public and can often lead to coupling problems.[/quote]

You can read more about this subject in the resources below.

javaworld.com

Head First: Design Patterns

Design Patterns: Elements of Reusable Object-Oriented Software

In other words, using the factory, different types of objects can be created and returned without using the “new” operator or be interested in how this object can be instantiated.

Through factory class, an instance of another class can be taken.

Sample Code

Let’s start analyzing the code below. We are going to create a character who is able to use a gun or his punches. So, we will start implementing these classes. At first, we will create an abstract class for Gun.

Next 2 classes extend from Gun abstract class. ShotGun and Punch classes.

Now we are ready to create our character with ActionFigure class.

In case that, we use constructor without any argument then our character is going to use Punch class.

Last but not least, we will create factory class that returns the desirable figure to us.

This class contains 2 functions, the first returns an instance of ActionFigure without a gun and the second with a gun.

Also, this design pattern is called Static Factory due to the static functions in factory. The advantage is that we don’t have to instantiate the factory in order to use createFigurePunch() and createFigureShotGun() functions.

The drawback is that we are not able to subclass and change createFigurePunch() and createFigureShotGun() functions behavior.

In continuing, we call and get desirable instances from factory using the code below.

Output:

Action figure without gun created!

Figure is shooting : Punch

figure is shooting 3 times :

Punch

Punch

Punch

Action figure with gun created!

Figure with gun is shooting : Gun is shooting. Left Boolets 2

Figure with gun is shooting 3 times: Gun is shooting. Left Boolets 1

Gun is shooting. Left Boolets 0

Gun is empty!

Figure with gun is shooting : Gun is empty!

Figure with gun reloads gun: Figure with a gun is shooting: Gun is shooting. Left Boolets 2

Conclusion

To sum up, factory is a design pattern easy in use and simplifies the code’s complexity a lot. Using “new” operator is definitely a bad approach and we have to avoid using it. Factory helps to write a more clear code with less bugs.

You can download the source code from GitHub.

Android, Game Developer, Game Development, Java, LibGDX, OOP, Programming

LibGDX: AssetManager

Assets are one of the most significant and demanding things in a game. Images, music, sounds, fonts, skins are only some of the reasons that a game may respond slow and have bad behavior if they are not set up correctly.

It is acceptable to have a small delay while the assets are loading before the game starts, but from the time that the game has started, we do not want to have a lag or a delay. If so, then we face the danger of losing our users because the game becomes frustrating to them.

So, we must be very careful on how to handle our assets in our game. It’s not the only thing that we have to take into account when we develop a game but it’s sure a very important one.

It is a heavy process creating new objects at run-time, so, if we need to create new assets and dispose of some others then we face the danger of having lags or our game freezing.

We have to be very careful when we use the keyword “new” at run-time. For example, the LibGDX framework loads an image with the code below

Creating new objects is costly and has negative consequences in run-time gaming. Generally speaking, it is a good habit to evade having big constructors, synchronization calls during object construction. Instead, we can use Weak References.

Also, there are some design patterns like object pooling and prototype which we can use in order to avoid using new” keyword so as to generate new instances. You can take a look at these design patterns here and here.

Back to our subject, LibGDX provides us with the right tools to handle and use assets as efficiently as possible.

One of these tools (class) is AssetManager. It’s only a very useful class that helps us handle our assets. Every single one of the assets is loaded in memory once and we can use them as many times as we want.

It’s the best way to handle images, music, sounds, and more. Also, you can read why and how to use AssetManager in LibGDX documentation.

  • Loading of most resources is done asynchronously, so you can display a reactive loading screen while things load.
  • Assets are reference counted. If two assets A and B both depend on another asset C, C won’t be disposed of until A and B have been disposed of. This also means that if you load an asset multiple times, it will actually be shared and only take up memory once!
  • A single place to store all your assets.
  • Allows to transparently implement things like caches.

AssetManager usage is simple enough.

The first line makes a new object of AssetManager. The second line puts the image myImage.png which is a texture in the queue.

From the time we call finishLoading(), we start the loading process of the assets. The whole program is blocked until all assets are loaded.

Caveat. Method manager.load(“…”); doesn’t load any asset, instead, it puts every asset in the queue and when we call finishLoading(), it starts loading the assets.

Method get() returns an asset and we use casting in order to set image variable with an image from the manager.

Attention! Don’t use AssetManager as static.

According to the documentation, it is bad practice to use AssetManager as static due to the different lifecycles of a static and Android Activity. This approach may lead to bugs and memory leaks.

There are two ways to load assets using AssetManager. We have already seen the first using finishLoading() function. The second is update() method. Using this function we have a better control when assets are loading. We can use it with the function getProgress() which returns a percentage of loading.

Take a look in the next example of code

It is worth noting that we don’t need to use dispose() in each Texture or any asset AssetManager handles. The code is more elegant and we don’t need to write too many lines so as to dispose of each asset individually.

This whole process is very useful and a big improvement during code execution. It’s a big improvement when we have to create new instances of an asset in run-time.

Drawing With AssetManager

Continuing, we will see how we can use AssetManager with a good structure. Also, we will draw some images on our screen.

Starting with class Assets and we will declare the images paths.

AssetDescriptors

We can use get(“asset name”) method in order to get the asset and use it. It’s not the best practice, in case we want to change an asset with another one. Then we have to change each one point that we have already declared.

Another reason is when we just have a single string in get() we cannot be aware of what type of asset the get() is going to return.

So, LibGDX offers AssetDescriptor which handles situations like that.

LibGDX API Class AssetDescriptor<T> describes an asset to be loaded by its filename, type, and AssetLoaderParameters. Instances of this are used in AssetLoadingTask to load the actual asset.

Now we are ready to create a class named AssetDescriptors and we will declare every asset.

The next step is to create the right code in order to load assets in AssetManager and draw these assets on screen.

At this point, we are only going to see and analyze AssetManager and not the camera.

As we can see in the constructor we create a new instance of AssetManager.

Show() calls loadAssets() function. This function sets assets in a queue and after that, it calls finishLoading() function which blocks everything until all assets are loaded.

After that, we are ready to use all assets that are loaded in AssetManager.

Now we are ready to draw images (our assets) inside render() with the standard way, using batch.

You may have already noticed that in dispose() function we don’t dispose of every asset as we used to.

We just have to dispose of manager and all assets will be disposed of by the manager. Nice!

Using AssetManager with update()

In order to use update() method we have to remove the line below from loadAssets();

and add the code below in show() function after loadAssets() call.

You can find the whole source code in the file AssetManagerUpdateExample.java

AnnotationAssetManager

AnnotationAssetManager is another tool that comes with libgdx-utils library. It is a tool that simplifies the whole situation even more. As you can imagine we will use annotations.

Before we start we have to add the following lines in gradle file in order to download libgdx-utils library.

Now we are ready to go!

We will need one more class named AssetsAnnotation and we will use @Asset() in order to put assets in the queue. So, we don’t need to write the same code twice.

You may have already noticed that loadAssets() function is just 2 lines. We don’t need to load every single asset anymore, we just need to call AssetsAnnotation class.

Outputassetmanager examples

You can read more about AnnotationAssetManager here!

Conclusion

It is suggested to always use AssetManager in order to handle and load assets. In that way, assets are loaded once in memory and we use them as many times as we want.

Assets don’t need to be disposed of one by one. Instead of that, we just dispose the manager.

Also, it’s easy to handle our assets because they are located in one place.

The outcome is a more compact and elegant code and this leads to cleaner code. Also, there are fewer places to hide a bug.

It’s the best solution in case we have to create “new” instances of assets at run-time and not only!

You can find LibGDX examples in GitHub!

creational patterns, Design Patterns, Game Development, Java, Object Pooling, OOP, Programming

Design Patterns : Object Pooling

Object Pooling is a design pattern that belongs to creational design patterns. Creational design patterns are the ones that deal with object creation mechanism. This gives the program more flexibility in deciding which objects need to be created for a given use case.

Design pattern object pooling gives us the ability to load some instances before any object, so we are able to borrow any of the pre-loaded instances from the reusable pool class.

Using the keyword new to create multiple instances of the object every time, is costly. This cost is related to the time a new instance needs to be created.

The fact that we are able to borrow some instances of an object and return them back to the pool when we don’t need them is very useful.

Object pooling is usually used in games. For instance, in our game, there are some characters who have a gun and shoot. Every time that we use the keyword new to create a new bullet our game is becoming slower and doesn’t work as we would expect.

So, in this case, it is not only the right decision to use object pooling, but it’s mandatory.

Also, it’s a good practice to use it in our characters and some other points of our game.

Now we are ready to see a simple example of object pooling usage.

Using Object Pooling

Our game is simple, the user has to connect the dots so as to make something known to us, like an elephant, a man, flowers e.t.c.

The game is going to have a lot of levels, so, that means we will create and destroy dots all the time. So, it is a great chance to use object pooling pattern.

Let’s start with the Dot class.

As you can see this class creates only a dot. The code below creates the dot.

circle = new Ellipse2D.Float(posX, posY, radious * 2, radious * 2);

Additionally, a function named isColliding() checks if this dot intersects with a line.

The next step is to create an abstract Pool class. You can see the code below.

The constructor calls method init(). This method initializes the object with instances of Dot class.
Method addObj() is an abstract function. Also, there are 2 more methods, method size() returns the size of the object and the second removes all of the elements from objects.

DotPool class is extended by an abstract Pool class. Let’s take a look at the code :

Method addObj() adds a new instance in objects.

Method get() returns an instance of Dot if it exists, otherwise, it creates a new one. Also, it is a good practice, if there is not any available instance, to wait to get back one instead of creating a new one.

Method free(Object o) returns an instance to objects.

Last but not least, the Main class.

OUTPUT:

And this is the window that our code produces.

object pooling dot window

As you can see, Pool starts with 2 instances of Dot class. We get one instance and  1 remains in Pool. We get one more instance and we can see that size of the Pool is 0.

In the next step, we release the second instance back to the Pool, and Pool’s size is 1 again.

After that, we ask 2 more instances from Pool, but only one exists. So, Pool will create a new instance.

Now we release all the instances back to the Pool.

As you can see, Pool starts with 2 instances but in the end, it has 3. This has happened because we asked 3 instances and get() function is able to create a new instance if there is not any in Pool.

You can find the code in my GitHub account.

If there is any mistake or you have any questions, please let me know.

If you want to read more about creational patterns and object pooling you can read these books Design Patterns: Elements of Reusable Object-Oriented Software and Game Programming Patterns.

Design Patterns, OOP, Programming, Software Engineering

The OOP Concept

Object-oriented programming (OOP) is a way of writing code based on the concept of objects. Every object has its own arguments and functions.

If there is a need to code with OOP principles then we have to be in a continuous effort trying to describe everything into objects.

Before we continue on to how we have to think when we develop with OOP I would like to give you a very basic intro about some of the principles that we have to follow in order to build better software that is maintainable and easy to improve with new functionalities.

It’s a good practice to separate the code into small blocks of code. Every single block of code must be responsible for one task only. To achieve this goal we can use functions.

A function is a block of code that executes a specific task. We have to keep in mind and not break the rule that a function must execute only one task. This is the way that the complexity of the code will be reduced making the code reusable. Also, these small blocks of code mean fewer places for bugs to hide.

A function should not exceed 25 lines. It’s rare for a function to exceed 25 lines. We don’t need to count each line of function all the time. If a function exceeds the 1/2 of the screen it means that it may perform more than one task. So, we are able to break it in two or more functions.

If we don’t break the rule that a function must perform a single task then it’s almost certain that it will not exceed the top-up limit of 25 lines.

The name of the function is an important fact as well. The name has to describe what the purpose of the function is with one, two, or more words. It such a great help for everyone to understand what a function does without the need to read a whole block of code.

I would like to continue to write about some good practices that everyone has to follow for a better quality of code. Even that, it would not be enough. The best way to learn more about that is by reading the book named Clean Code by Robert Cecil Martin.

Every developer must read this book. Before reading anything else. If you have not read the book then stop what you are doing and go for it. It’s the best book in order to set the right bases for programming.

After this short analysis on how to improve your code quality, this is the right time to talk about OOP. As I said, we have to reduce the feature that we want to build in order to describe it as an object.

In order to do that, we have to think that an object is an entity or a class. Every class contains attributes and functions.

So we have to describe and build those attributes and functions. Every function has to perform only one action of the object. Functions are able to handle these attributes and change them sometimes. Let me give you an example.

Supposing that we want to build a game with people and dogs.

A dog is an entity that has 4 legs. This is an attribute. Also, the dog can execute tasks like barking, walking, or running. These tasks are functions. And each function performs only one of these tasks. Thus, we can make a dog.

Now we want to make a man. A man is an entity again with 2 hands and 2 legs. These are attributes as well. Some of his functions are to walk, run, and talk. As before, each of the tasks that a man can perform is a function in our class.

This way of thinking seems to be easy at first but in case we have a complex problem to solve then the code’s complexity is equally important. Even though, it’s certainly an efficient style of programming to build big applications.

There are many reasons why we want to use OOP.

It’s a really efficient way to build a reusable code. It’s certainly not so easy. We have to follow some rules like the rules that I described before. Alternatively, we will end up with a spaghetti code written in a class.

Another important reason is that developers are able to collaborate with each other more efficiently without so much communication. That means that they don’t need to waste their time describing and analyze the way in which something was built or what is the way that a new feature will be built.

To be successful, we need to use design patterns. Design patterns offer solutions to problems during development. It’s a framework that helps developers solve common problems.

Moreover, design patterns are able to solve communication problems among developers. If design patterns are known among the developer’s team, productivity and effectiveness are increased.

Writing code with design patterns it’s not so easy and requires a lot of practice and study. One of the best books is Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Ralph Johnson, Richard Helm, John Vlissides.

All of the above come true through some principles. These principles are encapsulation, inheritance, and polymorphism. According to this book these principles are :

ENCAPSULATION

The result of hiding a representation and implementation in an object. The representation is not visible and cannot be accessed directly from outside the object. Operations are the only way to access and modify an object’s representation.

In other words :

Encapsulation is the process of combining data and functions into a class. Attributes of the class are kept private and there are public getter and setter methods that are provided to manipulate these attributes. Thus, encapsulation makes the concept of data hiding possible.

INHERITANCE

A relationship that defines one entity in terms of another. Class inheritance defines a new class in terms of one or more parent classes.The new class inherits its interface and implementation from its parents. The new class is called a subclass or (in C++) a derived class. Class inheritance combines interface inheritance and implementation inheritance. Interface inheritance defines a new interface in terms of one or more existing interfaces. Implementation inheritance defines a new implementation in terms of one or more existing implementations.

POLYMORPHISM

The ability to substitute objects of matching interface for one another at run-time.

This was a quick review of what OOP is. It is really an immense subject, and we only just scratched the surface of it.

I will get back to the subject soon with more details when I present design patterns.

View More