Tuesday, December 30, 2014

OOP - how to do it right? - part 1

When I started my journey with Object Oriented Programming I quickly found out many tutorials and trainings, which showed how to use OOP structures in code. Unfortunately, most of them demonstrate only how to write your first own class, interface. How to create an object. All of this was about language “grammar”, about key words, the way how to create structures used in OOP, etc. Yet, somewhere authors lost the most important information to share - why we decide to do this instead of looking for other solutions? Why an interface contains nothing more than abstract methods? Why all of those are public? What for are those visibilities? And so on...

That’s why I will try to interrupt you a little bit with your coding (of course there will be code in here as well :) and I will focus on things that really matter - on object oriented thinking. Because regardless of how many you can think of, everything what is possible (and impossible) to do when you are using OO languages has a reason.

The way you are implementing OO concepts in a particular language is floating, decisions made as a solution to a given problem are common, common is the way of thinking, the whole process of making decision. It doesn’t matter whether you are writing your code in PHP, Java, C++, etc., because if you know how to do a design of it right, this design will be valid for each language. The only thing that changes is the way you translate it into something understandable for a interpreter/compiler of a used language.

Ok, I think it’s more than enough of an introduction and we can move on to something more funny. Today I will write mainly about basis.

Object Oriented Programming - what’s that?

OOP is an attempt to visualize real world and its relation with objects. The most important paradigms are:
  • Abstraction
  • Encapsulation
  • Inheritance
  • Polymorphism

We will go through each of this concepts during the series of articles. Today we will focus on a language and things that are necessary if we really want to start our adventure with OOP.

Class and Object

From a programmer’s perspective, class is a type of variable. Yet, from the design point of view it’s a common definition of a certain group of related object, which have got different identity. Class defines methods (functionalities) that are delivered by the objects of it. Except this, we define also attributes, which are specific for each object (not always, but we will get back to this later).

What is an object? It is an instance of a class, the variable with a specific type.

I think is right time for an example :)
Peter, May and Norman are the objects of the class Human. Each can sleep, eat and move it those activities are the methods defined in class Human. On the top of that, each human was born on a particular day and has a name. Yet, those are specific for each person (object, instance of Human), which means they are strictly related not with a class, but with the instance.

And how would code for this example look like?
class Human
{
    private String name;
    private Date birthDate;
 
    public Human(String name, Date birthDate) {/**...*/}
    public void eat() {/**...*/}
    public void sleep() {/**...*/}
    public void move() {/**...*/}
}
 
Human peter = new Human("Peter", new Date("1982-01-09"));
Human may = new Human("May", new Date("1950-02-21"));
Human norman = new Human("Norman", new Date("1999-11-17"));

Abstraction and Inheritance

An abstract class is little bit different than a regular class. And the main difference is its inability to create an instance of it. It can define methods, also abstract one, which mean the one that existence was declared, however has to be defied in child classes.

Ok, let’s add something more to our example:
It’s now known that Peter, May and Norman are instances of Human. However, all of them are also mammals, same as Peter’s dog - Killer. And as we know, each mammal sucks milk, at least when it’s young :)

Based on what we said, we can produce the following code:
abstract class Mammal
{
    // code
    public void drinkMilk() {/**...*/}
}
 
class Human extends Mammal
{
    // code
}
 
class Dog extends Mammal
{
    // code
}

Why is Mammal an abstract class? Well, regardless of the fact that each Human and each Dog are Mammals it’s impossible to create a mammal (one was never born :) which won’t be a part of specific species. Yet, it doesn’t change the fact that we need to know what is the mammal and what’s not.

Interface and Realization

A specific form of abstraction is an interface. The main differences from abstract class are two things:
  • You cannot declare any attributes, only methods and constants.
  • All methods have to abstract (declared, not defined) and abstract.

The main role of interfaces is to provide a required and needed set of functionalities. They are some kind of contract between classes, which are using it and those who are implementing it. Interface are to to guarantee that specific method exists and not what it will really do.

Ok, so let’s move on with our example:
Mammals, like all other Animals, have the ability to move and they have to eat. However, there is huge difference in how fishes, birds or humans are moving from point A to B.

The same happens with eating.


And that’s the way how code like below is created:
interface Animal
{
    public void eat();
    public void move();
}

abstract class Mammal implements Animal
{
    // code
} 

abstract class Bird implements Animal
{
    // code
}

Is that all?

Everything I wrote today is nothing more than an introduction and I just want to be sure that we will all start with the same knowledge base. There are many things worth mentioning in front of us so be patient - we will go through all of them step by step :)




In this series I also wrote about: