Despite the fact that Object-oriented programming has been around since the 1970s, it is surprising how many people either do not understand the concept or use it incorrectly. A brief history lesson tells us that Bjorn Stroustrup began integrating object-oriented concepts into the C programming language in the late 70’s creating what we all know of as C++. The goal was to help to describe complex problems by breaking them down into objects which may contain fields or attributes which could then be called through procedures otherwise known as methods.
In its most simplistic state, object-oriented programming helped developers visualize their code by describing boxes and allowing those boxes to share data or build upon what the previous boxes had done to create more complex shapes. This sharing of data or attributes was described as inheritance where one object could inherit the data and attributes from a larger item.
The two most important concepts of Object-Oriented Programming are Classes and Objects. So we should probably start with a definition of those two things. Classes – this is the definition and format of the data, basically a container. Next is Objects – these are the individual instances of the classes.
A real-world example may be in order. If we were going to describe man’s best friend, we would create a Class that describes a dog. This could include the breed of a dog, the fur type, length of tail or ears, and the name of the dog as an example. Notice that the class is not describing your dog, merely describing the common attributes of an animal called a dog.
Now if we were going to define a specific dog, then we would create an Object of the Class Dog. Here we would describe specific attributes of that particular dog meaning it’s birth date, color, favorite treat, favorite toy, etc. Notice that we are not necessarily defining all the things for all the dogs and we are now talking about specific items about one dog.
The beauty of this is that our Dog Object has inherited the attributes of all dogs meaning it has a breed and fur type and length of tail. Our Object has also extended the class of Dog by defining its own attributes that are attributed to this one particular dog. We can create a set of classes that continue to drill down each inheriting those from the class above it to further define our objects and manage the complexity of the problem we are trying to solve.
Looking at this example it may seem obvious why Object-Oriented Programming was such a breakthrough. So why then did I suggest that some 40 years later we are struggling with this concept and programmers are using it the wrong way?
Some of the more common misuses of Object-Oriented Programming are listed below:
Mixing Class and Object Levels – When defining classes and objects we sometimes create the wrong level of detail. Instead of looking at a top down approach of defining objects some choose to eliminate higher level classes and instead start defining at the lower level making a class for every object rather than finding the similarities and building hierarchy.
Too Much Hierarchy – The opposite of what was described above, the other misuse comes from defining too much hierarchy, so you have to traverse several layers of sub-classes before you finally get to a level that us useful. An example of this with our dog analogy is that we define a Class of mammals then canines then dogs bred in the United States then dogs bred in the Southwest then dogs in Arizona. While those all may be valid subclasses, unless you have a valid reason for building that level of hierarchy it tends to be overwhelming trying to follow the attributes being inherited.
Both of these can lead to complexity and confusion and should be avoided where possible. This is not an exhaustive list but one that will stand as a reminder of what you should consider when designing a system. The definition of classes and objects will have a huge impact when you start to traverse between them with procedures and data.
Swift does a very good job of managing this but it will take effort by the programmer to make sure that they are using Swift’s language constructs properly. There are many similarities between a Swift Structure (struct) and a Class (class) but there are also vital differences. You will need to understand those differences if you want to properly use Swift as an Object-Oriented language and take advantage of what that gives you.
Day 10 of the 100 Days of Swift program has some great videos that describe the differences between struct and class and I highly recommend them.
0 Comments
Trackbacks/Pingbacks