Day 4: Object-oriented programming and MVC

March 6, 2014

This article is the fourth in a 5-day series about teaching beginners how to program. Read the introduction.

If you've been following this series, by this point you'll have learned enough about web development to create a database-backed website or web application, using Bootstrap, jQuery, Apache CouchDB and Javascript.

This is an impressive, well-rounded set of skills. But there's much, much more to learn about Javascript, web technologies, and computer programming in general. Today, we begin moving into some advanced concepts.

Object-oriented programming

Many popular languages you may go on to learn after Javascript are object-oriented languages. This means that they emphasize code reusability by organizing code around abstract concepts (like 'person', or 'blog post'). As you write more complex applications with lots of moving parts, it makes more sense to group code under general 'building-blocks' (objects) like these. Without giving structure your code somehow, it can quickly become unmanageable. The more complicated the interface you build, the more complicated the dependencies between different moving parts.

Javascript is an object-oriented language, but we haven't really had a need to explore the implications of this in depth yet. jQuery has taken care of most of the heavy lifting on the front-end, and the Javascript you've had to write for CouchDB is limited to a few view functions, update handlers and so on.

In order to introduce learners to object-oriented programming (which can be a difficult concept), we're going to rely on a front-end Javascript framework to give us some real-world context.

Why a framework?

We're using a framework for the same reason we learned Bootstrap: it helps us achieve meaningful results quickly by embracing magic (for a more detailed rationale, check out the note on pedagogy from Day 2).

There are other reasons to learn a framework as well: web development languages (Javascript, PHP, Python, Ruby, etc.) use frameworks to simplify things, by reducing the amount of boilerplate, repetitive code that you'll need to write. Frameworks take care of lots of basic configuration, so you don't need to reinvent the wheel. Learning a Javascript framework will give you a 'frame' (sorry) of reference for what you'll encounter down the road. Incidentally, there's a partial list of popular frameworks used by different languages back on Day 1.

Frameworks are also, in a way, inevitable. The most experienced a programmer you become, the more good habits you develop, to save time and automate as many repetitive tasks as you can. Ultimately, you'll either invent your own framework and tools (which requires lots of time and mastery), or you'll start using the ones developed by your peers. It's a simple, logical progression.

There are lots of strong opinions among Javascript developers about which front-end framework is the best one to use. After plenty of deliberation, I've decided to go with EmberJS as our front-end framework. Ember is a mature MVC (model-view-controller) framework for client-side development. What this means is that Ember forces you to organize your code in a way that defines information (model), interfaces (view) and application logic (controller) separately (believe me, it's really easy to mix the three of them up, which makes it much harder to change anything later). Programmers who follow MVC end up with very flexible, maintainable code. This is why so many application frameworks are designed to encourage it.

Why Ember?

Front-end Javascript frameworks are a dime a dozen. There's Meteor, Angular, Ember, Backbone, Sencha / ExtJS, Knockout & React, and a smattering of other lesser-known frameworks that all claim to do more-or-less the same thing. I chose Ember for the following reasons:

It gets you quick results with minimal effort.

Ember has so much automation built into it that a basic application can be developed with very little actual code. The framework makes intelligent guesses about the things you've left out, and if you follow the default path, a great deal of the work is done for you. This is in line with our mantra: getting results is more important than understanding how. Embrace magic.

It's all about URLs.

One of the big reasons I endorsed CouchDB was because of its emphasis on HTTP and REST. I believe it's extremely important for web developers to understand these concepts, and URLs are at the core of both. Ember was built with URLs at its centre, so every state of your application can be represented by a unique URL. In fact, the first thing you do when building an application is defining all these URLs, which is a great exercise to help you map out your project.

This focus on URLs reinforces the importance of REST (Representational State Transfer) in web development, and makes Ember that much more closely aligned with the various server-side frameworks (Rails, Django, CodeIgniter, etc.) you might encounter in the future.

It introduces object-oriented concepts clearly.

Ember, for better or for worse, redefines certain data types that are built-in to Javascript in order to enhance their behaviour. As a result, each time you create a new object, you're extending an aspect of the framework. By doing this again and again, you become familiar with the concept of inheritance (making a specific thing by customizing a more general thing). It also demonstrates polymorphism (see Mixins), encapsulation (or 'data hiding'), and abstraction (simple code that hides more complicated code).

These four concepts are the fundamental building blocks of object oriented programming, that you'll encounter in C++, Java, PHP, and pretty much all the well-known contemporary languages. Ember provides a framework that helps demonstrate and explain these concepts while building cool stuff quickly.

Important note: NEVER use the terms 'inheritance', 'polymorphism', 'encapsulation' or 'abstraction' with students. You'll scare them off, and they don't need to know about them explicitly. Let them do their thing, and get comfortable applying these concepts without knowing that they are. It'll be our little secret.

It's forward-thinking.

Ember's core team has prolific open-source developers with a diverse range of experience behind them. This experience is reflected in the decisions they are making today, and the direction that Ember is headed. As the web continues to evolve, it's important to know that your framework is being steered by people who are actively involved in this evolution. Like CouchDB, Ember is skating to where the puck will be.

Unit overview

The goal of this unit of study is to introduce learners to more advanced programming techniques, using an object-oriented approach and an MVC framework. At this point, students should know how to build a front-end interface and link it to a database using AJAX. This is a pretty good skill-set for basic websites and web applications, but it quickly becomes unmanageable when you want to build something more complex. The more "states" your application can have, the more carefully you need to plan so that the right controls are available at the right time. Once students come up against these limitations, it's time to graduate to a framework.

To find a hook into this unit, consider finding some samples of really polished web applications, and speculate about how they might have been built. What would the database fields have to look like for each kind of item? How do the buttons respond when clicked? How does everything happen so quickly, without reloading the page? When do AJAX calls happen? As you ask these questions, you'll help students articulate and define the limitations of what they can currently build.

Now, show them how to overcome these limitations.

A beginner's exercise to introduce some basic features of Ember would be to create a simple, three-page website. Nothing special, no forms or database interactions yet. Just a simple, static website with 3 links to different sections. Have students model this website using Ember's approach: define the application, define the 3 routes, the application template, and the 3 corresponding page templates.

Students should immediately begin to see one of Ember's value propositions: instead of creating 3 HTML files and linking them all together by copying and pasting a navigation bar, they can write the entire website on a single page, and rely on Ember to respond to clicks, load new content instantly, and even change the URL. They may also notice that they only needed to write the navigation bar once, in the application template. As the page contents change with each new section, the navigation bar stays the same, and the page never needs to refresh.

For an intermediate exercise, students might try and re-create one of their previous web applications from Day 2, but using the Ember framework to reduce the amount of code they need to write. This will reveal the areas where they still need to grow, like action handlers, Handlebars templates, model hooks and state management. Students may need to remain at this stage for a while, and it's a good opportunity for group-work, as many students will find that they're trying to solve similar problems. That's okay - there should always be time for collaboration and exchanging ideas. Vygotsky might even call these opportunities zones of proximal development.

Finally, as an advanced exercise, challenge students to create an Ember application that can list items from a database, display those items individually, and edit & save them back to the database. This will require learners to define nested routes (e.g. /posts , /post/hello , /post/hello/edit), initiate a model with data from a database (using AJAX inside Ember controllers), and create interface templates that can trigger actions when buttons are clicked.

Where to go from here?

Like CouchDB and pretty much every other technology we've covered, Ember is a rabbit hole unto itself. You could spend months on this one topic and still learn how to do new things, and it's entirely up to you how in-depth you care to go. However, the bare minimum that students should learn before moving on to Day 5 is how to create an Ember application that can fetch data from a database, display it, edit it, and save it back to the database. If they've mastered the skills required to meet this outcome, they have an excellent foundation in front-end development, databases, and object-oriented programming.

Congratulations, your students are now highly employable. But, there's still plenty more to learn about programming. We'll catch a glimpse of this tomorrow.

Up next:

Day 5: Server-side programming and future directions

Ari Najarian Follow @stickbyatlas