Designers intuitively grasp the way techniques and tools affect results. Design the same scene twice — once with vector graphics and once with raster — and you’ll likely get very different results based on the strengths, weaknesses, and workflow of each approach.
But some techniques are so deeply ingrained that you may not even think about them, or how they shape your workflow and results. And one of the most ingrained approaches is object-oriented design. While object-oriented design is generally thought of as an approach for software developers, it probably plays a role in how your company approaches mobile app design already, even if you’re not aware of it.
Here’s what object-oriented design is, how it affects your mobile app design role, and how you can learn from it to be a better designer.
Object-Oriented Programming
Object-oriented design is an approach for solving problems in object-oriented programming, so before we talk about design principles, we need to get into the coding end of things.
Object-Oriented Programming (OOP) is a programming approach based on the creation of discrete objects that interact with each other. An object is an entity which has both internal data in a particular state, and methods, which are used to interact with other objects.
Objects in OOP are like real-world objects — or at least how we see real-world objects.
For example, a lock has internal values (the pattern of tumblers inside) and a method (inserting and turning a key). When you use the method, it changes the state of the lock from open to closed or vice versa.
The benefits of this approach are obvious. Because objects relate to other objects through simple methods, you can build large, complex programs relatively easily. You don’t need to even know what’s going on inside an object — as long as you understand its behavior, you can use it.
OOP Principles
OOP principles are rules for how to properly build programs within an object-oriented paradigm. The four main principles are encapsulation, abstraction, inheritance, and polymorphism.
Encapsulation and Abstraction
Let’s return to our lock and key example above. When you open a lock, there’s one way and one way only you’re supposed to do it: by inserting and turning the key. You can’t see the internal mechanisms or individually set the tumblers to change the way the lock is configured — in fact, you may not even know how it works. That makes it easy to use; because no one is screwing around with the mechanism and changing it in unexpected ways, it always works the way it’s supposed to.
The OOP encapsulation and abstraction principles work the same way. Encapsulation says that each object should keep its internal state private, so that other objects can only access it when programmers explicitly provide that permission.
Abstraction says that the internal workings of the object should be hidden as well. Other objects can’t go inside the object and change its state — or even see its state — unless the programmer has created a method. This ensures that objects always interact with each other in a predictable fashion, even when the program becomes large and complex.
Inheritance
Inheritance is an OOP method to deal with a large number of objects that are similar, but not identical. Objects inherit all their traits from parent objects, which can be supplemented by their own traits. So for example, if you were making a mobile app with several pages that were structured in a similar way, you might use a parent object to define the pattern, then create child objects for each page.
Polymorphism
Sometimes, you might have to work with a group of objects that don’t have quite the same data types. You might need to create a method to draw different shapes, such as cubes, spheres, and cones, or a form that needs to be able to process text fields, checkboxes, and multiple-choice menus. Polymorphism enables you to treat multiple child classes in the same way, by using the same methods within the child classes.
Why Should Object-Oriented Principles Matter to Designers?
Strictly speaking, understanding object-oriented design isn’t explicitly required in most design roles, save those that require a coding background. So why should other designers care about any of this?
There are a few reasons:
1. There are more overlapping roles: As the product cycle gets faster and internal methodologies and tools get more refined, many companies are working with smaller, more multidisciplinary teams. Instead of siloed designers on one side of the office, and equally isolated developers on the end, organizations increasingly use more flexible models, fitting their particular software niche.
Many design roles already require some basic programming skills or familiarity with particular platforms, and there are more and more jobs that fit into this area every day. The better you understand how programmers work, the easier it will be to find your niche in this climate.
2. Designers work closely with developers: Even companies that divide skills in traditional ways are increasingly getting rid of silos. A good designer and developer team can be an amazing thing, but there are a range of barriers. Understanding object-oriented design principles can help you create a workflow that works for everyone.
3. Prototyping unites the two halves: The slow death of siloing has as much to do with technological progress as it does with changing approaches to project management. As mobile app design and development software advances, the sharp line between design and development has faded and blurred into a continuous gradient. Designers can build and animate scenes and objects using an analytical, modular approach, and developers can more easily transition into design, using templates, patterns, and libraries.
The line is blurriest when it comes to mobile app prototyping software. Newer prototyping tools allow designers to create app prototypes without writing a line of code — giving them more power over the development process.
As the boundaries continue to open up, there’s ample opportunity for companies to innovate, changing not just the way designers and developers put together apps, but even the way they conceptualize the work they do. While it’s hard to predict exactly where this will lead, one thing is certain: learning to cross those boundaries with OOP principles will make you a better designer.
Understanding Object-Oriented Design Principles
The core principles of object-oriented design form the acronym SOLID. They build on the basic OOP principles, creating a logically organized methodology of mobile app design that makes it relatively easy to modify or extend your app. They are:
- Single Responsibility Principle
- Open-Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Single Responsibility Principle
Single Responsibility dictates that a class should have only one responsibility. If a class has multiple responsibilities, it’s a good idea to divide it into separate classes.
For example, let’s say you had a class called Radius that calculated the radius of a circle. You decided you also wanted to be able to calculate the surface area as well. According to SRP, you should create a separate class to calculate the surface area, rather than adding it as a new capability of the existing class, Radius.
The reason you’d do this is to make the code as flexible and modular as possible. When each class does just one thing, making changes or adding new functionality is less likely to cause problems with the code, since changes only affect classes in one dimension. This is why programmers state SRP as “a class should have one, and only one, reason to change” — because making complex changes in classes is more likely to cause problems.
Open-Closed Principle
Classes are open for extension, but closed for modification — i.e., you should be able to make a class do new things without changing the code.
OOP treats classes as small, simple machines that can do work on other machines. The OCP says that you should design classes such that you can add whatever functionality you need by building new machines, rather than modifying the ones you’ve already built.
For example, let’s say you create a class called Draw that draws a circle when you feed it the centerpoint and radius. Later, you go back and decide you’d like it to be able to draw a square, too. If you graft on a second function to draw a square, it will violate both SCP (since it will have two responsibilities) and OCP as well.
The solution is to divide the machine up into different pieces that each do one thing. You’d have a class that gets the draw information (radius and centerpoint, length of a side, or whatever) and passes it to a Draw machine. The Draw machine then calls on another class like Square, Circle, or whatever. If you want to extend Draw to create another geometric object, you just create a class called Triangle or Diamond that draw can call. That means you can add any shape you want without changing your code.
Liskov Substitution Principle
Remember when we talked about Inheritance earlier? If you recall, subclasses inherit the traits for their parent classes, supplemented by their own traits. The LSP says that you should be able to substitute in a subclass for a class without messing up the program.
A common example of this uses squares and rectangles. Let’s say you create a class that draws a rectangle — you call the class with two integers L and W, which the class uses as the length and width of the rectangle. Later you want to create a version that draws squares. A square is just a special kind of rectangle where length = width, so you should be able to create it as a subclass, right?
That works according to geometry, but not according to object-oriented design principles. The square doesn’t take two integers — it takes one — the length of a side. Because you’d have to change the method to draw it, you’re better off creating square as a separate class, rather than a subclass of square.
Interface Segregation Principle
An interface is a type of structure that defines a set of properties for a class. ISP says that an interface should not pass unnecessary properties to the class. For example, let’s say you have an interface called vehicle that lists all the things vehicles have: wings, wheels, engines, pedals, tires, treads, etc.
Because this class is so comprehensive, most vehicles would have many unused properties. A car would have no wings, a bike would have no engine, and a rowboat would have neither. You’re better off designing interfaces based on roles. So, defining a bicycle, you’d have an interface for HasWheels, another for HasPedals and so on. This ensures you end up with small, modular interfaces that are easier to work with.
Dependency Inversion Principle
The DIP states that high level objects should depend on abstractions (i.e. interfaces), not low level objects. Essentially, the goal is to make high level objects independent. So for example, let’s say you’re making a texting app that lets you send messages to several platforms.
Instead of building a piece of software that handles conversion of your messages to WhatsApp, another one that handles conversion to Signal and so on, you’d should build an abstraction for the conversion process — an object that handles conversions in general, by calling lower level objects for each platform. Then, you can easily design more lower level objects to convert to new platforms, as they become desirable.
Object-Oriented Mobile App Designers
Object-oriented design isn’t just a good approach to coding software — it’s a great set of guidelines for prototyping and mobile app design as well. It lets you approach design as a modular process, where everything from overall page design to the smallest button is laid out in hierarchical fashion.
This makes it much easier to change details as needed. Changes in page layout or user flow can be approached as one layer of abstraction, so you don’t have to struggle to disentangle it from other parts of the system.
But ultimately, the biggest benefit of object-oriented design principles could be the way they free you to push your limits, from building ultra-realistic prototypes to building your own apps.
Do you use object-oriented design principles in your mobile app design work? Let us know by tweeting us @Protoio!
