If you are familiar with object-oriented programming, you are most likely familiar with subclassing and inheritance. However, inheritance has been getting a bad rap. I believe that is because some developers see it as a catch-all solution when you need to modify a program. The problem with this is that class hierarchies can become unmanageable.
There are other design patterns we can use to make our apps easier to understand and ready for change. I will show you examples of how you can use inheritance and the decorator and composite pattern to improve your program’s design.
Inheritance
The idea behind inheritance is that one object “is a” specialized version of another object. There is a parent class (also known as a superclass) which defines the base properties of our object. And there is a child class (subclass) that inherits the properties of the parent class.
An example of inheritance is a dog and a poodle. All dogs have certain features like four legs and the ability to bark. A poodle “is a” kind of dog. An SUV is a vehicle. A circle is a shape. This is what our class hierarchy would look like if we were designing a program for creating shapes.
The benefit of having a Shape class is that we can reuse the properties and methods we defined in other classes.
Notice that the getArea method was redefined in each of our subclasses. We did not have to redefine this method, but we did it to replace our parent’s implementation of the method. That is because each shape will have its own way of calculating the area.
Overriding a parent method in a child class is an example of polymorphism. Polymorphism is the ability for objects to have multiple forms. It allows subclasses to have methods with the same name as their superclass but with different implementations.
This is an example of what our code would look like for creating a Shape and Circle subclass:
class Shape {
constructor(x, y) {
this.xPosition = x;
this.yPosition = y;
}
getArea() {...}
}
class Circle extends Shape {
constructor(x, y, radius) {
super(x, y, radius);
this.radius = radius
}
getArea() {...}
}
let circle = new Circle(1,2,3);
One of the drawbacks to this design choice is that if you decide the parent class needs to change, then the subclasses may need to change too, along with all the objects we created.
For example, suppose we decided later on that it would be better to replace the x and y parameters of the Shape class with an object. Consequently, we would need to change the constructor for all of our subclasses and the arguments for every object we instantiated.
We can see how this can easily become problematic. We would have to make sure we got our design right the first time around so that we could avoid making a change. But that is not practical, nor is it what we should be striving for. A program is an ever-evolving entity, and it’s better for us developers if we have the flexibility to make changes easily. At the very least, we should not have more than one level of child classes.
Decorator Pattern
A decorator allows us to attach properties to an object after they have been created. This means we can add functionality without subclassing or being concerned with the implementation of our object.
Instead of thinking a circle is a shape, we could use the Shape class to create circles and wrap it with the additional properties we want. Here is an alternative to creating circle objects using a decorator:
class Shape {
constructor(data) {
this.x = data.x;
this.y = data.y;
}
getArea() {...}
}
function CircleDecorator(shape) {
shape.radius = 3;
shape.getArea = function() {...};
return shape;
}
let shape = new Shape({x:1,y:2});
let circle = new CircleDecorator(shape);
We can add or modify members of our Shape class with a decorator as opposed to subclassing it. With our shapes example, you might find that you just want to create a circle object that has all of the properties you need and do the same for other shapes. That is fine. But a decorator allows us to reuse the code in our Shape class and modify it with the functionality that differs with each shape. As a result, we will have more objects, but more objects are easier to manage than more subclasses.
This pattern is not limited to creating graphics. You can use it in any situation where you want to add responsibilities to an object.
For example, we may have a class that handles signing up users to our account. Before we save their information to our database, it would be wise to check that the input is valid and doesn’t contain any malicious scripts. We could decorate the class with a method to validate the information first. This same decorator can be reused anywhere in our application where we accept user input.
Composite Pattern
Objects can be composed of other objects. The view for an app can be thought of as a component that is composed of other views. If we were making a game, our game world would display all our graphics we created like circles and squares. Every time we update our view, we would need to redraw every element. We need a way to manage all of the elements as a group.
That is where the composite pattern can help us. We can create a class that is responsible for all of the elements. When we want to redraw the elements, we call this class’s draw method, and it will call the draw method on each individual element.
class Component {
constructor(name){
this.components = [];
this.element = document.createElement(name);
}
add(elem) {
this.components.push(elem);
}
draw() {
for (const elem of this.components) {
elem.draw();
}
}
}
class Circle {
constructor(data) {
this.x = data.x;
this.y = data.y;
this.radius = data.radius;
}
getArea() {...}
draw() {...}
}
let world = new Component('div');
let circle = new Circle({x: 1, y:1, radius: 2});
let circle2 = new Circle({x: 10, y:10, radius: 2});
world.add(circle);
world.add(circle2);
world.draw();
A webpage can also be thought of as a component. This component could have a menu, a sidebar, and a blog post. The post would be a sub-component that has a picture, a title, and a body. The draw method for our main app component will call draw on the menu, sidebar, and post. The post component will in turn call draw on the post image, title, and body.
Here is a view of what a web page would like divided into components:
This pattern isn’t limited to creating views. For example, if we were making a game, we might have a component to manage the elements on the screen, a component to manage the audio, and a component to manage the game state.
These would all be inside a component I call the game engine. The game engine would have an initialize method that would call the initialize method on each of its sub-components. That is the power in using the composite pattern. Instead of dealing with individual objects, we can treat them as one object.
Conclusion
Inheritance lets us reuse code by defining an object in terms of another object. The decorator pattern allows us to add responsibilities to an object without changing the original code or subclassing. The composite pattern models part-whole relationships. These patterns aren’t meant to be used in isolation.
JavaScript has become the language of working on the web. It’s not without its learning curves, and there are plenty of frameworks and libraries to keep you busy, as well. If you’re looking for additional resources to study or to use in your work, check out what we have available on Envato Market.
They can be combined as you see fit. The examples I provided also should not be taken as the only application for using the patterns. They are just a guide. Feel free to use your creativity to apply them. There is no one way to implement them or one use case.
Powered by WPeMatico
