Category Archives: Coding

A short pairing story

A recent discussion on the ALE LinkedIn group about pair programming made me remember a fun little event I lived recently. Read on for a true story about the power of pairing.

A couple of weeks ago I was at a client site and we had a meeting scheduled for 11 am. Shortly before the meeting I got an email notifying me that it will be delayed for 10 minutes.

What to do in the meantime? Even if my role in that assignment was to help a team adopt Kanban, I always try to get a glimpse at the code and see how clean it is. I find it often speaks louder than words. I decided to ask a developer (let’s call him Paul) to show me what he was working on. As it turns out, Paul was actually stuck with a problem and had been fighting with it for the last twenty minutes.

I proposed to pair on it, even if I had never seen the code before. It was the front-end (HTML, CSS, Javascript) of a web application, so to me it seemed pretty familiar stuff (I was a web developer in a previous life). We worked step by step, with me acting as the teddy bear and asking my partner to verbalize at each point what the code was trying to do.

Much to my surprise, about five minutes into our exploration, without really understanding much of anything, something jumped at me. Hey, shouldn’t that “class=” be an “id=” ? I asked Paul. He looked at me silently, changed the code as I suggested and voila!, the bug was gone. As I stood up, I heard Paul say: Dude, we should do this more often!

With three minutes left, I walked to the coffee machine, poured myself a black coffee and slowly headed towards the meeting room.

Advertisements

Good OO design doesn’t need setters/getters

Migrated from Posterous.
———————————

Today I had one of those “a-ha” moments after I stumbled across some blog posts from two years ago that ran a conversation about the value/need of setters and getters in domain design. As you learn OO, most books teach you encapsulation/data hiding in a simplistic way: make all properties private and add setters and getters for them. As it turns out, this is mostly wrong.

First, some theory. In OO, objects communicate using methods(messages), following a noun/verb parallel. The methods are what the objects do (their external interface), while their properties (private variables) store internal state. (I like to think about objects as finite state machines) As a consequence, when providing setters and getters we are actually reaching deep inside the gut of the object and provide access to its inner workings, thus breaking its encapsulation.

One example of a resulting problem is this: should we ever decide to change the signature or semantics of a property, we’ll have to update all of the clients that use that property (via the getter). As an example, compare the following two class definitions:

class LeakyCustomer {
   private $name; // eg. "John"
   private $surname; // eg. "Doe"
   [...]
   public function getName(){
     return $this->name;
   }
   public function setName($name){
     $this->name = $name;
   }
   public function getSurname(){
     return $this->name;
   }
   public function setSurname($name){
     $this->name = $name;
   }
}

and

class StrongCustomer {
   private $name;
   private $surname;
   [...]
   public function getFullName {
     return $this->name . ' ' . $this->surname;
   }
 }

The first class design implicitly invites its clients to use something like:

$name = $customer->getName().' '.$customer->getSurname();

while the second can only be used as:

$name = $customer->getFullName();

The benefit is obvious if later on the requirements change and we have to accomodate a name prefix such as “Mrs.” or “Mr.”. All clients of LeakyCustomer will have to change

$name = $customer->getPrefix().' '.$customer->getName().' '.$customer->getSurname();

while clients of StrongCustomer will remain unchanged. This is true encapsulation!

There are some caveats though, such as deciding what to do when doing ORM mapping or rendering views (which need access to an object’s state). Suggestions include adding a Composite DisplayableCustomer class, but (sadly), as always, the answer is “It depends”.

For a more in-depth look, take a look at:

Refactor code to abide by Demeter’s law

 

Migrated from Posterous.
———————————

Demeter’s law helps with encapsulation and information hiding by trying to minimize dependencies between objects. It states:

  • Your method can call other methods in its class directly
  • Your method can call methods on its own fields directly (but not on the fields’ fields)
  • When your method takes parameters, your method can call methods on those parameters directly.
  • When your method creates local objects, that method can call methods on the local objects.

In the following youtube video by Jason Gorman you can see a complete refactoring of a code that did not respect the law.