OOCSS methodology helps to break up your css code so that you can logically separate objects into modules and classes for reuse and to avoid duplicating code.
Instead of:
#button {
width: 200px;
height: 30px;
background-color: red;
border: 1px solid green;
box-shadow: rgba(0, 122, 244, .5) 2px 2px 5px;
}
#box {
width: 100px;
height: auto;
background-color: red;
border: 1px solid green;
box-shadow: rgba(0, 122, 244, .5) 2px 2px 5px;
}
You would write this to reuse code and also to separate how these tie in logically (applying one skin to multiple objects that appear the same):
.button {
width: 200px;
height: 30px;
}
.box {
width: 100px;
height: auto;
}
.skin {
background-color: red;
border: 1px solid green;
box-shadow: rgba(0, 122, 244, .5) 2px 2px 5px;
}
In coming up with the member functions or methods for your object in a class or module, there can be several behaviors that an object can have in real life. You don’t have to identify all of them. Just identify those behaviors that are relative to the goal of your system.
Example
If you had a Motorcycle Racer object and you were trying to identify the behaviors or methods he would have, some behaviors to consider are:
- startMotorcycle
- gridUp
- changeGears
- wheelie
- accelerate
- brake
- train
- eat
- rest
These are all certainly valid behaviors of a Motorcycle Racer but if the goal of our system was specific to racing and what happens on the track, then the last 3 on the list would not be relevant.
So ask yourself:
What does the object do in relation to the nature of the system that is being developed?
And then go code. Wootie.
Function vs. Functionality
Function is the object’s behavior.
Functionality is the set of instructions or steps to perform that behavior.
Abstraction is what the base or superclass requires of it’s derived or subclass to define the functionality of a behavior. The base class can force the derived class to define an implementation for a function if the base class declares that function as abstract.
Abstract class
a class that cannot be instantiated. Purpose is to have a subclass inherit from it in order for its data and behavior to be used in an application.
An abstract class can have member or method functions designated as abstract. This will require derived class to redefine the abstract method, otherwise a compiler error will show.
How does this differ with Encapsulation?
Encapsulation is a way to define objects in a system so there are associated data and behavior (procedures) tied to it. The only way to access attributes and procedures of an object is to create an instance of it.
Given picture below, the attributes are ID, name, and Graduation. The member functions or behavior (procedures) are Write() and Display. These attributes and behaviors are said to be encapsulated in the Student class.
Purpose for encapsulation
The main purpose for encapsulation is protection, defining explicitly how an object’s data is accessed or what member functions can be called on it.
Tracer Bullets
How do you shoot a machine gun in the dark to determine if it hits your target? You can do some calculations based on gun type, environment, trajectory, etc., or you can insert some special bullets that have phosphorus that ignites when it leaves the gun leaving a pyrotechnic trail from the gun to the target. This is preferred over the labor of calculation since feedback is immediate.
How does this tie in with programming and software design? Sometimes developers want code that glows in the dark too, if there’s some vague requirement and a goal is to try to hit some specific target. When the tracer bullet technique is applied, we get some type of immediate feedback as well since some portion of the system is created, visible and repeatable.
Caveats of Tracer Bullet methodology
- Consistent with idea that project is never finished
- There will always be changes and things to add to the system
- It is an incremental approach since the requirements were completely defined
- Use in situations where you’re not 100% sure of where you are going but you can adjust until you hit what you’re trying to aim for
Difference with Prototypes
A prototype generates disposable code. It’s not meant to have everything fleshed out like error checking, complete working submodules, real data, etc. It’s main aim is to explore risky or uncertain elements to evaulate without committing to building the real item. This offers changes for correction at a greatly reduced cost than from finding out after the system is fully developed.
Tracer bullets define a system to see how everything connects. As requirements get more finalized, more pieces can be defined better and hit closer to the final target.
Prototyping is a learning experience. It’s value lies not in the code produced, but in the lessons learned.1
-
The Pragmatic Programmer, by Andrew Hunt and David Thomas
↩
Definition
In doing more planning for the modules/components of a project I’m working on, I’m designing what the system will be composed of and how best to implement them for scalability and object reuse. A pattern that came up was the use of a Facade, or an object that provides a simplified interface to a larger body of code.
Something analagous to this in modern web development is the use of APIs, or an application programming interface that consists of software component that can communicate with each other. What’s usually given is a set of methods or function signatures that indicate their input and will provide some service or output. Through one, unified interface, access to the system and its components are provided, simplifying its use.
Example diagram
Benefits of using
Another example of using the facade pattern and APIs is creating an interface to a poorly designed API. This would satisfy simplifying an interface to a larger body of code.
Using the facade pattern allows you to decouple your implementation from the subsystem. If your subsystem had to change for any reason and if the interface changed, you would only need to update the facade that interacts with the interface to the subsystem.
How I’m using it
From a talk given by Nicholas Zakas on Scalable JavaScript Architecture, he provides examples of how components can be connected together while being loosely coupled with use of Modules -> Sandbox -> Core -> Base. Modules communicate to other modules via the Sandbox. Only the Sandbox interacts with the Core. And the Core is the only component that talks to Base.
The Sandbox in this setup is what uses the Facade pattern, an object with a simplified interface to the Core. I’m using the pattern in the same way so that any modifications being done in the core are separated from the API or method signatures that the modules are using, thus keeping my components loosely coupled. If any updates are needed to the system, the modules are not implemented so tightly where many modification points are needed, allowing for easier testability and streamlined enhancements.
Happy coding.