Technology is often perceived as a black box, an opaque, mysterious tool that somehow performs magic. We take out our phones, press a few buttons, and suddenly we’re able to converse with friends, read books, buy food and learn about pretty much anything. However, as I’ve learned over the past few weeks at The Flatiron School, technology is anything but a mysterious process; its just really good at hiding what its doing. The process of learning how to code is all about not being intimidated or frustrated by the black box, but rather excited to learn about how the black box can seem so magical.
Avi talks a lot about design concepts of modularity and composition. Modularity in code means that individual methods should have one responsibility and objects should be separated into classes that each describe a discrete entity. Composition, on the other hand, serves as a complement to modularity, as it enables us to take discrete, atomistic elements in code and link them together to create what appears to the outside world to be a black box. This design concept of taking a series of distinct but related building blocks and chaining them together is remarkable because it seems so simple in its conception, so complex in its execution and so elegant in its operation.
The past few days at Flatiron we’ve been learning about the Web and how applications interact with clients (i.e., the browser) and servers. As I’ve mentioned before, this is often times one of the toughest concepts new programmers need to grasp. We started exploring the Web (instead of just programming, which we’ve been doing since the first week with Ruby) using Sinatra, a light-weight framework for developing applications. This week, we’re moving on to Rails, which is a more robust framework that many modern web applications are built on (Twitter started on Rails). Think of frameworks as the scaffolding upon which an application is built. A framework is just a collection of files that makes it easier to build stuff; it provides ready-to-execute code to streamline more mundane web processes, like connecting to a server or querying a database.
As we’re moving into web applications, we’re learning about the model-view-controller design pattern. This MVC concept demonstrates the notions of modularity and composition that make programming complex on its face but learnable at its core. There are a lot of resources online about the MVC pattern, but in short, models provide the analytical engine that defines an application’s database, views generate the browser-side display that users actually see and controllers connect the two together so that when you type in www.espn.com, the correct HTML page is rendered in your browser (views) with the necessary data from ESPN’s database (models).
Avi often uses the metaphor of a restaurant to explain the MVC pattern and demonstrate the principles of modularity and composition. Broadly speaking, a restraunt can be broken down into the kitchen (model), staff (controller) and atmosphere/ambiance (view). The chefs in the kitchen need to cook and make dishes. They have to know the food offered on the menu inside-and-out, and their responsibility is to create food. However, they don’t have any responsibility for actually connecting with the restaurant patrons and figuring out what they want. That’s the role of the wait staff. They serve the patrons, get their orders and deliver them to the chef. The staff doesn’t have to know how to actually cook, all they do is transmit information (a very critical task nevertheless, as anyone who has had a bad restaurant experience due to bad service can attest to). Finally, the restaurant atmosphere is how the restaurant-goers experience the restaurant - the lighting, the temperature, the surrounding people, the ambiance - while the food certainly has an impact on the experience, going to a restaurant is about more than just the food.
Taken together, the kitchen, staff and atmosphere need to work together to produce a pleasant restaurant experience for customers. If any one of them fails to do its job - the kitchen produces bad food, the staff is unfriendly or the restaurant smells - the customer has a lousy experience. That said, each part of the restaurant is responsible for its own task and does not need to know the inner workings of the other part. Cooks need to focus on food and how that food gets to customers is not their concern. Wait staff need to get food to customers, but how that food is made is irrelevant. Each component of the restaurant is able to specialize, yet the restaurant experience is best when all three work together.
In much the same way, web applications need to have a well-designed model for the database, intuitive and beautiful views and a controller that is able to transmit user requests effectively. If any one of those three breaks down, the whole system is damaged. However, each of the three does not need to know about the inner workings of any other - that’s where the modularity comes in. As a programmer, I can work in my application’s model and focus on writing clean, efficient code that reflects the data I want to gather and use while not caring about how that data is presented to users. Then, I can move onto the views and focus on making sure that people are presented with a beautiful interface and design when using my application. In each of the model, view or controller, the design pattern of modularity and composition is repeated, as individual methods and classes in a single model have responsibilities distinct from other methods and classes, yet also relate and depend on them as well.
These concepts seem simple and intuitive, but can be difficult to implement in practice. I think of the process of refactoring as the hard work necessary to achieve more modularity and loose coupling - the “make it right” part of “make it work, make it right, make it fast” formulation that I like so much. Just like a restaurant could function with the wait staff both serving, cooking and decorating, a web application could work without the principles of MVC. However, it just wouldn’t be right and wouldn’t make much sense. Using modularity and composition as a guide to writing code and designing elegant yet powerful applications has made me appreciate the “black box” complexity of technology that we all interact with every day, yet also eager to explore and dive into the details as I come to realize that its not really magic at all, its just good design.