OO Bootcamp: Day 1

My company is sponsoring a two week object orienting programming boot camp led by Fred George, who's a well known programmer and instructor. Today was the first day and we learned a lot. I'll be sharing the most important lessons on my blog over the course of these two weeks. I think it's an amazing opportunity for us to learn from someone with so much experience so I'm going to do my best to make sure I get as much as I can out of this as well as share as much useful information as I possibly can.

The primary goal of the boot camp? 

To teach us the fundamentals of modeling effectively. No, not this kind of modeling:

Data modeling. Defining conceptual models of some domain. Why is this important? Because how a system is modeled sets the groundwork for everything else that follows in building the system.

What's your job?

In OOP, we design systems that are based on objects and their behaviors. To understand what those behaviors and how they interact with other objects in the system, we need to clearly understand the jobs of these objects.

So our first lesson was this: learning to identify an objects job. He posed a basic question: what is the job of a rectangle? We all struggled to come up with an answer he was satisfied. Our answers were so off that he created a list of criteria that disqualified a job definition.

For example:

• Circularity. Saying that the rectangles job is to understand itself or rectangles is a circular definition. No good. 
• A list of data or methods. An object contains data and procedures that allow it to do its job. You can't really define what they are without knowing what its job is! 

The problem was that a lot of us were stuck on defining its job in terms of the behavior and knowledge that were implied by our subconscious knowledge about its actual job. You could say that we were getting a little ahead of ourselves. We were defining its job it terms of things like length, width, area, and perimeter. Sure, it may be useful for a rectangle object to have knowledge of those things - but we needed to get deeper. What job does it have that makes sense for it to have knowledge of those things?

The answer turned out to be something we all understood but took for granted: the job of the rectangle is to understand opposing sides that are right angles to each other. Now, that's not a very precise definition but it does establish the primary job of the rectangle that is not tied to any ideas we had in regards its behavior in the system. Once you know what the job of an object is, the rest will follow. For example, now that we know it's job we can then say that having knowledge of its area and perimeter is useful information. 

Tips

• Keep the job as simple as possible. Break it down to its bare essentials. What's the job, really?
• Come up with jobs for the object by role playing(anthropomorphism). What is your job? What are you expected to know for your job? How will you work with others?

The Task Cycle

Once we have an object modeled in our heads, we want to actually test our model against reality by building it and seeing how it performs. 

The most important thing to keep in mind about this cycle:

• We want to keep our test & code cycle short (less than or equal to 15 minutes) because that leads to code that can be quickly integrated into a code base. Small changes integrated quickly leads to less bugs. 
• A short test & code cycle depends on not spending too much time on design. A design is useless until you actually implement it and get feedback on how it actually works in a system. 

OO Principles

Encapsulation is a very important software technique to use when building your models. Code that is not well encapsulated is leaky and can lead to rapid software deterioration. If an object is not encapsulated, its data ends up being pulled into other parts of the system which creates unnecessary coupling that can make change very, very difficult. 

There are some common signs of violating encapsulation:

• -ER / -OR class names
• Classes that end in -er are usually violators because they are grabbing data out of other objects to perform some action. For example, controllers are notorious for acting as a middle man between the view and the model. It knows a lot about the views and knows a lot about the models in order to manage the flow of data between the two.
• Many instance variables (> 2)
• Law of demeter .... or your object is looking at too many other objects: a.b.c.d()
• Presence of getters & setters. Having getters and setters is just ASKING for other people to violate you. 
• Chances are, the object you're trying to grab data from knows how to use that data better than you do. You can learn to avoid this by role playing. Have someone ask you to give up your data. Then ask why. In most cases, you'll know how to do that with less duplication.

How do you know when you're done? 

In order of priority,

1. The code works. You're confident that it works because you've seen it work, it meets the requirements, and the tests are green. 
2. It's clear what the code does. Is it clear what the job of your objects are? Are there comments where the code is not clear?
3. There is no duplication. Is this code duplicated anywhere else? Duplication can happen even on a single line of code - an expression that accidentally gets repeated. Dry up your code!
4. It's implemented with as few logic, method, classes as possible.

Why is this priority order important? Well because if you optimize for #4 without following this priority, your code can get very unreadable very quickly :D