7 Patterns to Refactor JavaScript Applications: Value Objects

Note: This is part one (next) of a seven part series.

On October 17, 2012, Bryan Helmkamp, founder of Code Climate, wrote a blog post outlining seven patterns to refactor fat ActiveRecord models in Ruby on Rails. This post is the first of a seven part series that will demonstrate these concepts in the JavaScript environment. I will show that they are just as applicable, and equally as valuable. Each post will cover one of the seven patterns in detail. In this post we'll be talking about Value Objects.

Bryan's article describes Value Objects as "simple objects whose equality is dependent on their value rather than an identity."

Because JavaScript adheres to the "pass-by-reference" principle for all JavaScript objects, there are no native examples of this in ECMAScript 5 or even Harmony, save for primitives.

For example:

// Primitives
var foo = 2;
var bar = 2;
foo === bar; // => true

// Object identity
var foo = new Number(2);
var bar = new Number(2);
foo === bar; // => false

The first example assigns primitive integers to the variables foo and bar, which are equal by their value, even though primitives are technically still objects in JavaScript. The Number constructor, even though it provides a wrapper for primitives, is a Plain Old JavaScript Object, and is therefore equal by reference, not value. Thus, in the second example, foo does not equal bar, even though both Number instances represent the same integer value.

But Value Objects offer a great place for domain logic to reside. Almost every value type in your application has logic associated with it, such as equality, and the best place for that logic is in a value object.

Read More

Happy, Sad, Evil, Weird: Putting Use Case Planning Into Practice

In part one of this miniseries, we introduced formal Use Case Analysis and a simplified version called Use Case Planning which fits a rapid, iterative development process. That post went over the high-level concepts, and explained how this planning method will help you catch problems with your design before you start to implement.

In this post, the final post of this miniseries, we’ll step through a concrete example so you can see how to put Use Case Planning into practice.

An Example

We'll imagine that we work for a company that is building a multi-tenant Software as a Service (SaaS) platform where people can set up shops and sell products. Tenants will be able to charge their customers through the platform.

We're part of a team that's getting ready to create a credit card payment acceptance feature. It will be a credit card form common to all of our tenants. We'll be writing the markup by hand and using of Stripe for processing cards. We're entering a sprint planning meeting to define the scope of the work to be done and decide how long it will take to build. During this meeting, we'll talk about many different aspects of the billing process.

For the purposes of this post, let's hone in on one specific feature: once a user has clicked Buy, they are presented with a credit card form. We want to plan what will happen when they try to make use of this form.

Let's walk through the Use Case Planning process for this scenario.

Read More
Learn about Engine Yard
Try Engine Yard for your Ruby or PHP Apps

Happy, Sad, Evil, Weird: Driving Feature Development With Feature Planning

Feature planning has to be done early and often. But it can be a complicated process due to all of the stakeholders involved, each with different viewpoints and goals.

What's more, it's easy to overlook key behaviors of a feature, which can lead to expensive and rushed code later. It's usually intuitive to figure what should happen when everything goes according to plan, but what about edge cases? What should happen when a user supplies bad data? A hacker launches a malicious attack on our application? What about when chaos makes the whole system unstable?

In the first post of this miniseries, we'll take a look at one way to get everyone's voice heard in the planning process, including the product owner, developer, designer, and QA engineer. Using this approach, teams can draw on their diverse perspectives to tease out a detailed blueprint of a feature that costs less and performs better.

Read More

Linux Isolation Basics

Note: This is part one of a two part series. Read part two.

In the complex world of modern app deployment solutions, containers have been gaining traction as a popular distribution method. But what are they, and why are people so excited about them? This two part series will look into some of the benefits offered.

First, we’ll look at how isolation is generally used to solve a whole class of problems. Next we’ll look at how containers, specifically, makes isolation more manageable. An intermediate familiarity with UNIX-like systems is assumed throughout.

Read More

ZF2 Modules, Services, and Events

In this post, we are going to explore a few design patterns and architectures that reach into the heart of any ZF2 based application: The ServiceManager, the EventManager, and the Module architecture.

When it comes to building an application with ZF2, your application will be constructed with one or more modules, each of them providing services for other modules to consume. Likewise, these modules can trigger events which allow additional modules to react to things happening within the application at large.

To get started, we will begin with an introduction to the ServiceManager in ZF2.

Read More


Look through our specially curated posts to get focused, in-depth information on a single topic.