Dependency Injection And IoC Containers

05.10.2013

The dependency injection pattern is one of my all-time favorite patterns in software design. The concept, in its most simple form, is so simple yet so powerful.

In essence, it takes us from this:

var TweetStream = function() {
    this.twitter = new TwitterService();
};
 
TweetStream.prototype.streamTweets = function() {var tweets = this.twitter.getTweets();};
 
var stream = new TweetStream();
stream.streamTweets();

To this:

var TweetStream = function(twitter) {
    this.twitter = twitter;
};
 
TweetStream.prototype.streamTweets = function() {var tweets = this.twitter.getTweets();};
 
var twitter = new TwitterService();
var stream = new TweetStream(twitter);
stream.streamTweets();

So what’s the big deal?

In the first example, TweetStream creates the TwitterService instance. TweetStream is forced to have a knowledge of (1) the exact “class” it should use to communicate with Twitter, (2) where and how to access the constructor, and (3) how to create an instance and appropriately initialize the object (passing parameters to the constructor, calling methods after the fact, etc.).

In the second example, TweetStream does not need to know any of these things since TwitterService is created by a third party and later passed into TweetStream. TweetStream only needs to know how to interact with the instance it is passed.

Although seemingly benign, the additional knowledge that TweetStream is forced to have in the first example increases its coupling to its dependencies while decreasing its own cohesion. The additional coupling leads to code that can be difficult to test and less flexible at runtime. If we were to “inject” the dependencies rather than forcing TweetStream to create or find them, we can easily mock dependencies during unit tests and provide them directly to the subject being tested. At runtime, we can easily swap out the object being provided as a dependency based on rules or contexts. Continue reading »


Slides: Intro To AngularJS

05.10.2013

Here are slides from a presentation I recently gave at Adobe on May 6, 2013. The examples linked to in the slides provided the basis for most of the discussion.


Slides: JavaScript Patterns And Principles

05.10.2013

As web applications grow increasingly more dynamic, software design patterns and principles become crucial for robustness and scalability. Let’s break out of the stigma of hodgepodge, spaghetti code found in web apps of old! In this presentation, we discussed modularity, communication patterns, and patterns used within MV* frameworks with examples from Backbone.js and AngularJS.

These are slides from presentations I gave at Adobe on February 5, 2013 and April 30, 2013.


ADC & Appliness – Dependency Management with RequireJS

10.23.2012

As if you haven’t had enough dependency management bi’niss from my recent Slides – Dependency Management with RequireJS and JavaScript Architecture: RequireJS Dependency Management posts, here’s similar material I’ve authored through other outlets:

Adobe Developer Connection: Dependency Management with RequireJS
Appliness: Dependency Management with RequireJS


Slides – Dependency Management with RequireJS

10.22.2012

Presented at 360|Min 2012 in Las Vegas, NV.


JavaScript for the Flex Dev Slides

04.16.2012

Presented at 360|Flex 2012 in Denver, Colorado.


JavaScript Architecture: RequireJS Dependency Management

03.20.2012

Updated Aug 11, 2012 to reflect current library versions.

In JavaScript Architecture: Organization and Quality, we discussed the importance of breaking apps down into very small, decoupled pieces following the single responsibility principle. Small pieces are generally easier to comprehend than a mess of large peices.

Some devs coming from other languages feel like they can only build a few large, spaghetti JavaScript files for their app. I tend to think this may be caused by three reasons:

  • That’s the way JavaScript has been done in the past.
  • Loading many JavaScript files requires many HTTP requests resulting in longer load times.
  • Dependency management is hard in JavaScript.

Don’t stoop to these excuses. We can do better than that and today there are fantastic libraries and standards that can help us out. However, let’s see what the above problems mean. Continue reading »


JavaScript Architecture: Backbone.js Routers

02.29.2012

Updated Aug 11, 2012 to reflect current library versions.

In JavaScript Architecture: Backbone.js Views we discussed how to build dynamic apps that change views on the fly using JavaScript. Because view-switching is done without reloading the page or transferring control to a separate page, these are called single-page applications. Single-page applications pose a few issues we need to address:

  • When users hit their browser’s back button, they will be taken away from the app completely rather than back to a previous view within the app itself.
  • Users are only able to link to or bookmark the app itself–not a specific view within the app.
  • Deep views within the app may not be crawlable by search engines.

We want a great experience for our users. Successful apps behave as users would logically expect and users should feel like they can easily navigate back to where they were previously.

Like the topics we’ve addressed before, these issues aren’t specific to Backbone. It’s an issue that naturally arises in any single-page app. Fortunately, Backbone does a great job at addressing it and has a simple API. Continue reading »


JavaScript Architecture: Backbone.js Views

01.08.2012

Updated Aug 11, 2012 to reflect current library versions.

Tech-agnostic concepts

At this point of the series I really want to emphasize that the core concepts I’ve explained and will explain are not unique to Backbone; they’re unique to apps with state and dynamic views. I’m merely using Backbone as an illustration of a concrete tool that can be used to solve problems common to this type of app in general. The concept of “views” is no different.

What is a view?

If you’re coming from a different language or even a different library, you may be familiar with words like component, widget, or control. You can ask 10 engineers what they think those terms mean and you’ll likely get 10 different answers…or 30 if they think the terms are different from each other. The term view is just another one to throw on the pile and is equally ambiguous. It’s not all that unfortunate. Indeed, its usage can be quite flexible and its granularity disparate.

In the traditional web of requesting a new page for each section of a website, we may consider each page a view. Indeed, it is. In modern apps, it’s more common to have a single page and, as the user interacts with the page, portions of the page change. Those dynamic portions could likewise be called views. Within a dynamic portion of the page, there may be a toolbar that affects a list of customers. The toolbar could be considered a view. The list of customers could be another view. Each customer row inside the list of customers may be its own view. The row may contain a toggle button which is yet another view. The point is, in the Backbone world, the term view doesn’t necessary mean “a section of your website”. It can be, and oftentimes should be, much more granular than that. Continue reading »


JavaScript Architecture: Backbone.js Collections

01.04.2012

Updated Aug 11, 2012 to reflect current library versions.

Collections of items are amazingly pervasive in applications. Gmail deals with collections of emails. Twitter deals with collections of tweets. Facebook deals with collections of friends, updates, and apps. Very often these collections contain living data. The app may be constantly updating with new, changed, or removed items from the server. Maybe users are able to filter, sort, add, edit, or delete items and maybe they can do so from multiple views that need to be synchronized.

Usually when we think of collections of items in software terms with think of an array. Objects can be added and removed from an array easily enough but a native array on its own has no ability to broadcast notice of the change. Why do we care? Let’s say we’re building an RSS reader that shows the user a feed of articles from their subscriptions. The articles come from an array we loaded from the server. Each article contains a remove button next to it that allows the user to remove the article from the feed. Let’s also say in the top-right corner of the screen, separate from the feed of articles, we have a little counter that shows the user how many articles they currently have remaining in the feed. Assume that the feed has a JavaScript object managing it and the counter has a separate JavaScript object managing it.

When the user clicks a remove button to remove an article from the feed, it’s easy enough for us to remove the article from the feed itself and the accompanying array of articles, but how do we update the counter? The most direct approach is to give the feed view a reference to the counter view. That way the feed can just call a function on the counter view to tell it to refresh itself, right? Noooooooooo! Sure, it might function, but that’s a very good way to couple our views and reduce our flexibility. Our views would know more than necessary about each other. In this case, the data should drive the views instead of the views driving each other. Unfortunately, it’s difficult for our data (the array of articles) to drive the view using a native array because the counter can’t “watch” the array for a removal of an article. Native arrays do not broadcast events when items are added or removed.

You’ll notice a great similarity between what I’ve written above regarding native arrays resulting in view coupling and what I wrote in my previous post about native objects resulting in view coupling. Indeed, there are a lot of similarities and they are both resolved by implementing the observer pattern within our data structures. Just as a native object can be wrapped by a Backbone model in order to broadcast attribute changes, an array can be wrapped by a Backbone collection to broadcast additions and removals. Continue reading »