Working as a contractor and consultant for the past 6 years, I’ve given my fair share of interviews for software developer roles.
One type of white-board assessment you may find yourself in with an interviewer is to draw out in pseudo code the classes you would compose for an Animals software program that allows us to easily define new types of reptilian and mammal creatures.
So Interviewer A will ask, “We have a program that contains various types of animals each having their unique features and some shared features. Can you write an object oriented approach to architect this solution. Write out pseudo code to show what types of classes you would develop, so we can easily define new types of reptilian and mammal creatures in the future.”
Quite a basic question example above, but this is meant to be easy to follow for all audiences.
So I would come up with something like this:
abstract class Creature {
- method isLiving();
- method moveAction();
- ...some more
}
class Mammal extends Creature {
- porperty legs;
- poroperty bodyHeat;
- method walkAction();
- ...some more
}
class Reptile extends Creature {
- porperty scales;
- method crawlAction;
- method layEggsAction();
- ...some more
}
class Monkey extends Mammal {
- property hair;
- method walkAction(){
- use walkOneTwoLegsAction(); }
- ...some more
}
And so depending on how different my mind works from the interviewer they would critique my ideas of encapsulation and abstraction and mutability and suggest how I could have gone further.
This above example of animal abstraction is usually found in many software development books explaining these concepts.
So that is abstraction in a nutshell. Software programmers are expected to follow the above line of abstract thinking while designing good software. Abstraction and its related concepts aim to assist developers in breaking down an application function into as many smaller components that can be pluggable, easily modifiable and easily reusable. We do this with the mantra that we must “reuse our code whenever possible”
Why Abstract your Code?
Why do this, from a bottom-line perspective? Let’s take the above example and walk further with it; let’s say the above animal definition program was a real app that Company ABCD (have to be careful) uses for defining new animals that it discovers in a forest exploration project they have undertaken. The objective of the software is to quickly layout new features of any new animal they classify as a discovery and integrate it into an ecosystem of animal definitions which they can later use for some sort of a 3D game for kids to play with. Each time a new animal is discovered, all sorts of properties and actions that the animal can perform would have to be coded out.
Imagine having to re-write “it can eat, it can sleep, it has two legs, etc…” every single time, in code. That’s unnecessary company resources! Abstraction allows us to write out a clear architecture for the app, where it can be easily extended.
If we discover a new type of monkey, a software developer can simply extend the Monkey class, and add/modify all of the pre-existing definitions for the generic monkey class. This is the power of abstraction. A mammoth of an enterprise application can become easy to extend and even understand.
Too Much of a Beautiful Thing can be a….
However, we should be careful how much abstraction we do. There is useful abstraction like in the above example; where we can re-use code and save company resources; and then there is abstraction for the sake of art.
I kid you not. I have seem artists write code! Beautiful minds that have made a statement. However, software engineering is not about artistic encapsulation, but pragmatic modularity.
There are frameworks in PHP that if you look at the code architecture, it is simply mesmerizing. They have truly made object oriented code in the truest sense. Everything is envisioned and modelled around objects. Everything. When we speak of handling HTTP requests, they have bags; so a request bag and response bag; each bag containing truffles and candies of different sorts. This is what OOP was envisioned to be. Objects are a big deal.
Nothing wrong with the bags example above, but when we use and select frameworks for an app; the senior architects in the team should sit down and asses if the chosen framework is a right fit for the project at hand; or if the level of abstraction is too riddled and refined to serve any real benefit.
What use are 30 levels of abstraction in a given web application, where no developer in their right mind will bother drilling down in the code enough to reuse some of the abstractions for future extensions and modifications?
Remember how a computer works. Excessive abstractions take up excess memory and server resources in code compilation, which translates into longer processing times.
Abstraction should be used pragmatically. What needs to be made reusable should be abstracted. We should never forget the computer is a machine with finite resources and every new variable and every new class extension and every new object instance we create, is going to take a toll on the speed and or capacity of the app. Network applications demand such care.
If your company desires a walk through or inspection of a certain PHP framework to assess if it suites your project’s needs, connect with us, we may be able to help.
By: Mustafa Ghayyur
July 8th, 2018
