#poodr

This fall, I attended Sandi Metzs' POODR workshop.  I decided to sneak off during lunch (which is typically a no-no because work-life balance), and apply what I had learned at POODR to the building of my java server.  But this early on there is no big refactor in the production code.  I knew right away that the most obvious places of duplication would appear in my test code, so I decided to use what I learned there. 

Here is what I did:

1. I've written the test code that meet all of the requirements for a particular story.  All of my tests are passing, and I have not refactored any code.  Refactoring too early can lead to the wrong level of abstraction, something that I'd be concerned with in production code, not test code.  But this is still good practice.  As you can see, there is some unnecessary duplication.  

https://gist.github.com/LNA/3f0f0557a4448a6edf41

2. I want to look for the things that are the most alike.  There is 1 line of code that appears in every test:

RequestParser parser = new RequestParser();

And there is a second line of code that appears in 3/4 of the tests:

RequestParser parser = new RequestParser();

So we will first focus on refactoring the thing that appears the most. 

3. Add before you take away: Add the new code and make sure that the tests still compile:

https://gist.github.com/LNA/d1e80bb2be9d7f22a423

4. After you prove that it compiles, pull out the kind of living, kind of dead code(zombie code?).  Make sure that the newly refactored code passes.

https://gist.github.com/LNA/b69d0deb930894728cfc

5. Do it all again, with the next most similar thing.

Sample Class in PHP:

class Gear { protected $chainring; protected $cog; public function __construct($chainring, $cog) { $this->chainring = $chainring; $this->cog = $cog; } public function getChainring() { return $this->chainring; } public function setChainring($chainring) { $this->chainring = $chainring; } public function getCog() { return $this->cog; } public function setCog($cog) { $this->cog = $cog; } }

Same Class in Ruby:

class Gear attr_accessor :chainring, :cog def initialize(chainring, cog) @chainring = chainring @cog = cog end end

I'm building an iOS application that works with a RESTful API built in Rails.  I want the user to be able to upload various content types: Text, Picture, and Video.  When I'm designing the Model for the Content, does it make sense for the text property to live with the Parent content object class and the Picture / Video subclasses inherit this property or should it live within the Picture and video subclasses?  

The ultimate output will be a push notification to the user's device and I understand that Push notifications are only text based, but can also contain a URL that can send the user to the Image / Video, so my gut says the text property would be inherited, but the Video / Image subclasses would contain a Display URL property that can be passed to the push notification object on the end user side.

"It's not how strong we are that determines are survival, it's how much we can adapt to a changing environment" - Some smart old dude

Change is gonna come. We really don't have a choice in matter. That includes changes to our programs as they grown, specifically our classes.

While designing the class to be indefinitely changeable you need to break the class and it's methods down into it's smallest, most fundamental behaviors.

In order to tell if your class is isolated and striped down to it's bare minimum behaviors you have to be pretty hard on it. Ask questions and try to describe it's behavior in one sentence. Words like "and" and "or" imply that your methods have more than one responsibility and thus aren't very adaptable to the inevitable change that is going to come. 

Every class has a purpose right? (Say yes...I can hear you...). So it's important for everything in this class to be directly related to this core purpose - this my friends is what the pros call the Single Responsibility Principle (or SRP if ya nasty). SRP helps you, as the class designer, to create the initial responsibilities of the class that perpetuate all design decisions going forward forever and ever and ever and ever....muhahahahaha...or until you stop using the class or whatever.

When you define your class' soul purpose, you can then start making all the behaviors of the class reflect that purpose. This class soul-searching exercise also helps to eliminate behavior that may belong in a seperate class. ",,,a class should do the smallest possible useful thing."

Notice I said behavior and not data (or attributes) and it's not just because I can't spell attributes. Transforming data into behavior gives the class a single point of dependency on the structure of particular set of data. This is particularly useful when dealing with an external data structure that is index based. Translating the class methods dependability on the indices to a behavioral based model like a Struct allows you adapt to structural changes in the data structure by only changing one piece of the code, the translation method/struct, as opposed to all the many places the data structure would be referenced explicitly.

The single responsibility principle is important because it helps you see clearly what the true goal of your class is before you start to code too many dependencies and introduce redundancies that'll make your code too wet (opposite of DRY).

Your application should be very modular with a bunch of small methods that perform a very specific singular task, and when their powers combine they can do some amazing things! Cohesion is the name of the game here.

The future of your code depends on how well it can adapt to things that might not be realized right now, so the only thing you can do it make it easy to upgrade your code without breaking too many existing Objects.

"The structure of every class is a message to future maintainers of the application." 

Now go forth and create applications so future proof that when dug up by researchers in 200 years, they'll understand why they can't stop playing your Facebook game 195 years after Facebook was gone.

This post is based on the work in the book "Practical Object-Oriented Design in Ruby" by Sandi Metz

Week 2, Day 1

I've been, very slowly, going thru Sandi Metz' wonderful Practical Object-Oriented Design In Ruby. In Chapter 3, which deals mainly in managing dependencies, one of the suggested ways to loosen coupling between entities is to inject the dependency.

This got me thinking about my usual playground for programming ideas, my eternally-in-development Halibut library. In it there are two classes that are very much entangled, in a very similar way to the book's examples: Halibut::Core::Resource and Halibut::Core::Link.

You can see this coupling here,

Halibut::Core::Resource

def add_link(relation, href, opts={}) @links.add relation, Link.new(href, opts) end

which method is further called from other places.

def initialize(href=nil, properties={}, links={}, embedded={}) … add_link('self', href) if href end def add_namespace(name, href) add_link 'curie', href, templated: true, name: name end

On top of the several connascence of name sprinkled through the Halibut::Core::Resource class each time I send a message to Halibut::Core::Link, and this includes #new, we also have connascence of position and probably some other types of dependency.

What this essentially means is that any time Halibut::Core::Link changes, especially the initializer method, we are probably breaking Halibut::Core::Resource. This might not be a big deal, since it's such a small library and you can even argue that such breakage is actually desired, since all these pieces are meant to work together.

On the other hand Resource already depends on Link, and I'm not doing the user that much of a favor by shoving "implementation details" further down the road. The user already has to know that a link has a href, and possibly options, and which type of options it supports, so I might as well make it explicit and make the user inject the dependency directly.

Having added Halibut::Builder to the library, I'm actually more confident in making this change. The builder pattern allows a straight-forward (I hope) way to build a resource, making use of the much popular DSL pattern.