Jackson’s Blog

A lot of people don’t understand why object-oriented programming (OOP) practices are getting so much hype. While I can’t explain all the benefits of using OOP in this article, I will cover one of the compelling cases of using OOP, you save time.

Imagine a scenario where a new recruit has just joined your ranks. He was hired into your team to speed up your project. If your code wasn’t designed in an OOP manner, then he’ll most likely have to review a good chunk of the code in order to figure out what’s going on and how the various pieces interconnect. Some code at line 23 might be affecting line 83. Some function might take 2 integers and behave one way, and then take in 3 arrays and behave another. The code might also require certain global parameters to be set in a certain sequence before things can function.

In OOP programming, things you don’t need to know, you don’t need to know. For example, if you were coding a shopping cart, the “scanning system” only cares to know about the price of the item. The “product” object only needs to know it’s “price”. The “shopper” only cares about the price and the total. Each of these objects can have various complex behaviors, but they’re all encapsulated within the object. For example if the “product” was perishable, and price was a function of it’s expiration, the “scanning system” and “shopper” doesn’t need to know about this. If you were to adjust how various item’s price fluctuates, you only need to focus on “product” classes.

Whereas, in a non-OOP class, you might a very long file, class, or function, and it might be filled with all these complex checks to figure out how much the price is, but in an OOP system, the “scanning system” simply asks the “product” for it’s price. OOP code is also more intuitive, since OOP mimics real world objects and relationships.

OOP practices are good to adopt, although there is some overhead, there will definitely be long-term savings in more ways than one.

I believe that code-base no matter how well written are doomed to the fate of eventual obsolescence. No matter how well the code is constructed, there are bound to be unforeseen edge cases that can have a minor or major impact on your code. If your business  decides to take the code to a whole different level, you might need additional functionality that the code-base didn’t account for. “The best laid plans of mice and men oft go astray”. Businesses need to plan for this case, and allocate the resources accordingly.

It’s possible for your code to absolutely perfect and NEVER EVER require change. You might even conclude it might be a Microsoft only thing, but think about it this way. How often has Microsoft, Apple, Linux, Facebook, Myspace, and Google changed their code? Quite often, it’s almost like every few years, some major change occurs. Windows XP was recoded into Vista, and Windows 7 was Windows completely recoded from the grown up. Changin not only the look, but the security and functionality.

Code changes because they business requirement changes. Business requirements change because the customer’s demands change. Time changes a lot of things. So you have to ponder, if your code-base is an exception to the rule. Chances are, it’s not. If you don’t plan for the team to completely recode the code-base every few years, then you’re going to force yourself into an immobile position where your customer’s demands have changed, but your business  can’t respond to accommodate it.

With each new core product system, you should keep track of how long it took to develop it, make sure it’s well documented, and budget some time in the future to reallocate this amount of time to reinventing it. Yes, reinventing. Is this a direct violation of the DRY principle (Do not Repeat Yourself)? No. If it was exactly the same product, sure, it’s a violation, but since you’ve introduced new parameters, the no. Do you use the same method to do single-digit against single-digit multiplication as you do double-digit vs. double-digit, triple-digit and so on? No. Code should be no exception, plan accordingly, or face some interesting crossroads in the lifetime of your business.

Your testing sandbox can be flexible or immutable. I have a preference for designing testing systems that are flexible. Data that is generated via the testing process, can be modified through the testing process. Everything flows the same as a live system from beginning to end. There are developers who would disagree with this approach, such as we’re giving the testers too much control that can allow testers to generate cases we didn’t expect, which can cause some amount of embarrassment. Another argument is that with fixed data, we don’t have to worry about as much, since we pretty much control the entire flow. While the counter-arguments have a legitimate point, I would argue that their limitations defeat the purpose of a testing system.

A testing system should be a sand-box, as in implied in the term “sand-box”, testers can play around with it as much as they want. If we made the data immutable, it’s not really a sand-box, but more like buttons. If a person relying on your system have a lot of unique demands on your system, your system will not be able to handle it without changing code or system structure. In fact, you’ll need to implement a whole layer just to handle the immutable data and how to handle the response. If you were to allow the system to be flexible, and the objects mutable, or changeable, there will still be layer, but that layer will be deeply tied to existing components, which will still allow existing components to be tested. While the first case, although you can still have existing components tested, such testing is pointless, since you’re forcing a set response to a set data set each time.

Flexible testing systems allow you to fulfill the demands of any tester easily, since they’re pretty much testing how their system interacts with your system, and it closely mimic normal behavior. Not only that, but it also allows testers to test your system for flaws, helping point out flaws in your system before the flaw does any major damage. In an immutable system, we don’t have to worry about edge cases we didn’t account for. Which can be great, but unfortunately, a flexible system can handle the tester’s system that was design to deal with immutable or mutable data. In an immutable system, if the tester wants mutable data, we will pretty much junk the existing system and create another one. Turning a flexible system immutable is easy, turning an immutable system into a flexible system is hard. Much like procedural code versus object-oriented code, procedural code is pretty rigid, but object-oriented code is pretty flexible. “Be water, my friends.”