I was enrolled in college for my BS in Computer Science from the mid-90s to 2003. My father had health issues which led to money issues, so I was forced to put myself through college. After 8 years of working weird jobs and finishing my degree with part-time and full-time schooling from Auburn University in Auburn, AL (WAR EAGLE!) and Wright State University in Dayton, OH, eventually I achieved my BS in Computer Science.
What does this have to do with Object Oriented Programming? Nothing. But, I did receive OOP instruction from two universities and I think both taught it strange.
I was taught an object is a thing. I was taught inheritance is something like a Shape class, then if I want a circle, I should create a Circle subclass that inherits the qualities of the Shape base class. While this provided a decent enough understanding of OOP, enough where I could pass tests and write coding projects, once I hit the real world, it wasn't enough.
Objects are more than things, 'thing' isn't granular enough. Luckily for me, early in my career, I read about the SOLID principle (SOLID on Wikipedia) and I've been living by it ever since.
What really caught my attention, is the idea objects should represent a single responsibility rather than being, simply put, a thing. In OOP, an object does not have to be something tangible. It doesn't have to be a shape, it could be a database reader. It could create objects, it could be a jersey on a player in a video game, configuration manager, etc...Sure it's a thing, but if you focus on objects encapsulating responsibility rather than tangibility, I guarantee your code will be more clean.
As a novice software engineer, the hole I was always fell in was by thinking an object was tangible, I never encapsulated the inner responsibilities of the thing. Let's take the player jersey in the video game as an example. I would code a class called PlayerJersey. PlayerJersey would have a string number property and a string last name property. It would have a color property, is it mesh, does it have trim, etc...Before I knew it, I was managing all that data in one class because all those properties are on a PlayerJersey. The product was an object that was not easily maintainable and it would hide behaviors and properties that I could have reused in other classes.
Now, let's think of the PlayerJersey as a responsibility and let's think of those properties as other responsibilities. We should have a Name class, that contains the string name, but maybe it contains other info like the font and it manages all the properties of the Name. We should have a Number class that is similar. Maybe there's a JerseyFabric class managing the fabric responsibilities...so on and so forth. If we encapsulate those inner behaviors into their own single responsibilities, the PlayerJersey class now becomes the manager of those objects. All of the logic is now encapsulated into smaller classes and the PlayerJersey class becomes cleaner and more manageable. The product is a number of re-usable classes managing a small subset of responsibility that when joined into another object creates another responsibility. For example, if we have a Name class, we could reuse that on a stats screen, maybe a scoreboard style ticker in the game, etc...Also, we now know if there is a problem with how we handle names, then we can go to the Name class rather than updating the PlayerJersey class or any other classes which incorrectly encapsulated the Name responsibility.
I know this was a quick blog entry. It's purpose is to wet your feet on how I think when I lead projects. In Part 2 we're going to discuss the Open/Closed principle of SOLID and how not following it can make a good app go bad.
Since I write this stuff on my own time, I usually blaze through it. If you want more detail or if you find any technical errors, feel free to post a comment. If you want to correct my grammar or point-out typos, go walk the plank, I'm a software engineer not a literary mastermind. After years of programming, sometimes you lose grasp of writing with proper English.
No comments:
Post a Comment