At DBS>Interactive, we are always creating and improving websites and web applications – it’s what we do. A well-designed website should offer the end user an intuitive, easy to navigate gateway into what your company has to offer. If you sell products online, it should be easy for them to place orders. If they need more information, it should be simple to find. And the whole experience should be attractive and seamless. But beneath the sleek exterior of a well-done website, there is a lot going on under the hood.
As web applications become more sophisticated and powerful all the time, it is very easy to forget that at their core, computers are little more than really, really, REALLY fast idiots. They have to be told every single action to take. That’s what programming is – giving a computer an exact list of things to do, which the computer then does at lightning speed.
Procedural Style of Programming
To give you some background, in the early days of modern computing, most programs were written in pure procedural style. The code gave a literal, linear, step-by-step set of instructions for the computer to follow – similar to a flow chart. Although this worked well for simple applications, there were obvious disadvantages to this approach. If you wanted the program to perform different actions depending on what a person input, for example, you had to tell it exactly where in the code itself to go for further instructions – in language the computer would understand, such as by “line number” or other numerical addressing scheme. This leads to overlapping code that doesn’t appear to be in any logical order on the surface. Appropriately, it is often called “spaghetti” code, because you literally have to read it line by line to see what it is doing. Editing or creating additional functionality was thus very difficult.
Framework-based Programming
The next logical step up was coding based on events and functions. What enabled this step forward was the concept of a framework – a set of base functionality already programmed, on top of which you can build further functionality. Operating systems and web browsers, for example, are frameworks. Instead of having to give a computer a literal step-by-step “Simon Says” list of actions in a specific order, with a framework you can organize code into functions, which in turn can be triggered by events such as a mouse click or pressing a key. Functions allow a programmer to specify tasks by friendly names rather than by numbers, and events offer much more transparent logic during application development. The logic of code begins to more closely resemble how a human being would organize instructions. This, along with the addition of an ability to add “comments” within code, was a huge breakthrough in terms of making code readable, editable, and reusable.
This function and event framework-based approach works particularly well for “short bursts” of code, such as the basic front-end behavior of most web pages – how the site reacts to user clicks and form submissions. We at DBS take full advantage of the capabilities of web browsers and other related frameworks. In cases where custom user interaction is needed above and beyond what the framework does by default, we write clearly documented code to handle this. Our goal is twofold – firstly, the code should do what it’s supposed to do; secondly, the code should be well-organized and documented, and therefore easy to maintain. At DBS, we take this second goal as seriously as the first.
Object-Oriented Programming
When dealing on the level of more complex applications and lengthy code, however, the danger is that the organization of functions within a program could become arbitrary and scattered. Since the whole evolution of programming follows the route of making code organization more and more similar to the way humans perceive structure, object-oriented programming (“OOP”) is the next logical step to avoid this problem – and to improve the way we take advantage of frameworks.
Let’s take the wheel, for example.
What if you could have a clear chunk of logic containing instructions and properties to cover all possible wheels, so no matter how many different wheels you create, you can reuse the same set of instructions to do so? In OOP, this self-contained logic is called a “class,” and it holds all the ingredients needed to produce and control an object. A class contains properties and methods; properties of a wheel could include color and size, while methods could be behaviors such as rolling and stopping. The primary advantage is, since all the inner workings are inside the class, any programmer using this class to create wheels only needs to know the names of the methods and properties and their parameters to make it work. The programmer never has to “reinvent the wheel.”
More significantly, classes can also be extended – that is, you can create a new class that inherits the behavior and properties of an existing class, then adds on more functionality. And this leads us back to the concept of frameworks. The goal of a good Content Management System (“CMS”) is to separate content from code – so after the initial creation and structuring of a site, content can later be added or edited by someone who doesn’t have to know anything at all about programming. For nearly all websites that we build, we start with an open-source CMS framework such as WordPress or Drupal. “Open-source” just means that the source code is publicly available – a huge advantage if you intend to extend the existing code.
Not surprisingly, most modern frameworks are developed in OOP style – functionality is clearly organized into classes which can be reused and extended while avoiding editing or interfering with the source (a dangerous and undesirable practice sometimes known as “hacking core,” which less thorough programmers often do because it requires less initial effort). At DBS, we insist on the use of consistent and appropriate code extension practices. What this means to you is two things; first, when there are updates available for the underlying CMS framework software, there is much less danger of something “breaking” as a result of DBS custom code; and second, this translates to easier future extensibility as your business needs evolve.
