OO Bootcamp: Day 2

We spent most of the day 2 pairing. We started the day off by learning the vocabulary of pairing, went over a few key object to object relationships, and then we were off to the races implementing a program that performed unit conversions that took up most of the day.

Pairing

Fred is a huge proponent of pairing. We only started pairing on our team fairly recently. The two main arguments I've heard for why pairing is important are

1. Reduced business risk because it leads to knowledge transfer on a team. More than one person will know how to perform a specific task.

2. Higher quality product as a result of combined intellect and greater accountability.

Not all pairing is made equal, however. Effective pairing requires an understanding of pairing dynamics and adherence to some basic rules and guidelines.

Pair Types

• Expert + Expert
• Expert + Beginner
• Beginner + Beginner

In reality, software expertise can't be represented by either "expert" or "beginner". Consider the types above as the most extreme combinations you can have for completing any given task given a group of people with varying levels of expertise relevant to that task. 

From a getting shit done perspective, it's ideal to have a team of A players / 10X programmers. That's how amazing products get built. For most companies, that's not the reality. This doesn't mean beginners should never pair. Quite the opposite. Everyone should pair because that's the only reliable way to bring everyone up to the same level. 

So what are the advantages of the expert + beginner pair and the beginner + beginner pair?

Advantages of the Expert + Beginner pair:

• Expert gets a fresh perspective on problems
• Beginner can learn a lot about existing systems and programming techniques in a short period of time. Rapid ramp up.

Advantages of the Beginner + Beginner pair:

• Both beginners can hone their problem solving and team work skills by relying on themselves and each other.

Pairing Protocol

• Let me drive = "Give me the keyboard"
• Trust me or Trust me I know what I'm doing  = "Be quiet and let me finish this and I'll explain afterwards"

Pairing Tips

• Less experienced pair should drive. More likely to retain information. 
• Talk, talk, talk. By talking, you clarify your thoughts and let your pair know what your intentions are. If you walk into a room of pairs and its quiet then that's a bad sign. 

Pairing Models

• Pair programming ping pong. Pair A writes a test. Pair B writes code to pass the test. Pair B writes the next test. Pair A writes code to pass the test.

Object relationships

There are fundamentally three types of object relationships.

• Inheritance (is-a relationship)
• Buying / Composition (has-a relationship)
• Collaboration (bi-directional has-a)

If you've ever taken an OO class in college before or read a design patterns book, you've probably head of the phrase "prefer composition over inheritance". The main reason is that our human brains are biased to see inheritance relationships where there does not exist any. In other words, we're prone to creating inheritance hierarchies that do not make sense behavior wise. To avoid making the error of having a class inherit a bunch of behaviors it does not need, we should only consider inheritance if and only if the sub class uses most of the methods in the base class and the sub class has specialized behavior. Fred calls this specialized behavior a "kick". If a class has no "kick", it should not exist as a stand alone class.

The Quantity Pattern

We were asked to write a program that checked if any quantity of a given unit on the metric system is equal to any quantity of the same or different unit. For example, one question we would be able to ask this program is: "Is 5 teaspoons equal to 10 tablespoons?".

Our initial design was a quantity object whose job was to understand units and quantity of a unit. We then created sub-classes for each type of unit to perform the necessary conversions. We got this to work, but it produced a lot of duplication and it looked impossible to extend with new behaviors like adding quantities of different units or worst, adding an entirely new set of units.

The solution was a common pattern called the Quantity Pattern. Essentially, the quantity pattern sees two main players in this problem domain: a unit object and a quantity object. What happened in our design was that the logic of unit conversion was duplicated across multiple objects. In the quantity pattern, the unit object is responsible for understanding the concept of a base unit and the size of other units in the same system relative to that base unit. The quantity object understands the notion of size / magnitude given a unit and how to compare sizes. This greatly DRY'ed up the code and was by far the most elegant solution.

Afterword

Becoming a truly expert programmer requires developing a vocabulary in all of the following areas:

1. Language / Key frameworks
2. Tools / Text editors
3. Coding patterns or programming style
4. Code smells or signs of bad design 
5. Design patterns or patterns of software design
6. Analysis patterns or patterns that exist across domains

Getting language and tools down will make you go fast. However, just going fast isn't enough. As we've learned, having a bad design leads to ugly code. Mastering the others will allow you to become a true craftsman. In this course, we'll be focusing mostly on language, code smells and a couple of design patterns.