From Development

Object oriented programming principles

Object oriented programming is a trend that started some time ago and stayed enough time to make a real difference in most modern programming languages. If you're programming, you've must have met it on your way already.

The concept is very simple: turn everything you need to work with into an object. Then, it's up to you how many and what kind of objects you create. Today I want to share with you what I learned about separating app architecture into objects, starting with a quick introduction to object oriented programming (OOP).

Object Oriented Programming Principles

Search anywhere else on the web and you'll quickly find a list of principles linked to OOP. Those are: encapsulation, abstraction, inheritance and polymorphism. Next you can find a very summed up definition for each of them:

  • Encapsulation: the attributes of an entity are enclosed in itself;
  • Abstraction: hide important information in order to reduce complexity;
  • Inheritance: an entity can inherit attributes from other entities;
  • Polymorphism: entities can have more than one form.

This is not, however, where I'll focus on this article. At least, not on the more scholar version of the object oriented programming principles. Here you'll find more practical knowledge about object oriented programming and real insights on how to improve in the art of turning everything into an object. By the end of this article, it'll be perfectly clear why that is relevant for everyone who is programming out there.

Don't be afraid of creating too many classes

In my programming experience I'll always remember the day when I opened one of those big projects and the amount of files in it was simply overwhelming. That's when I though: this is impossible to understand. The concept of turning a simple idea into a huge amount of files seems an overkill, but very often it's not.

For me, the question I ask myself the most when designing app architecture is "should I create an object for that?" And, most of the time, the answer is simply:

Yes, I should.

In the end, it's much easier to read 10 files of different objects with names representing their function than 1 huge pile of code that does everything. The only issue here is organizing the large amount of files you create into a structure, that can be easy to understand and search through for anyone that might pick up your work later.

As an iOS developer, I follow what most of iOS developers use, which is the MVC model, and I always try to organize files into folders instead of just dropping them all into one place.

Use more subclassing

Instead of creating one class and giving it a set of properties and enum types to configure, think if it wouldn't be better just to separate those into elegant subclasses for easier identification of what they actually do, leaving the base one generic enough to keep scaling it later on.

Make objects generic

One of the beauties of object oriented programming is that the classes for the objects you create can be reused in other projects, which is a huge time saver. Think about that when you create objects and make them generic. The subclassing approach can definitely help you do that.

It's better to separate the class to manage API calls or in app purchases for the generic one that you can use across your projects and subclass with a specific one that will fetch you the data you need.

Don't tear objects apart

Sometimes I have to create a method that requires a lot of properties to be passed around. I don't want to ask for each one by one, so I decided to put them all in a dictionary or an array and pass it.

It seems convenient enough, but it never is.

I come back to it a month later, or worse, somebody else tries to use it and they have a really hard time putting the properties together exactly in the way I did, and maybe even spend some time debugging why one of those is perceived nil on their way.

In the end, it's much easier to pass the entire object of which the properties belong to, even if it has a lot more than you need. This solution also scales better because you never know when you'll need the whole object context, even if you start just with a small part of it.

All the programming languages I know are object oriented and, yet, I still keep finding different ways to answer this simple question: what kind of objects should represent this? The amount of possibilities might present a challenge when it comes to object oriented programming, but the alternative of not using is neither viable, nor desirable.

At Imaginary Cloud, we simplify complex systems, delivering interfaces that users love. If you’ve enjoyed this article, you will certainly enjoy our newsletter, which may be subscribed below. Take this chance to also check our latest work and, if there is any project that you think we can help with, feel free to reach us. We look forward to hearing from you!