Category: Just some thoughts

Javascript inheritance

Thoughts and notes on inheritance in javascript.

You can use the built in .call() method to extend a javascript class.

Syntax:

1
2
3
4
var InheritClass = function() {}
var YourClass = function() {
InheritClass.call(this);
}

An example with “Animal”. Inherit an Animal class inside a Cow class.

Remember to create a new instance of Cow. Only in the object instance can you call the methods and properties.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
var Animal = function() {
this.speak = "no speak set";
this.food = "no food set";
this.action;
this.says = function() {
console.log(this.speak);
};
this.eats = function() {
console.log(this.food);
};
};
var Cow = function () {
Animal.call(this);
};
// Cow.says(); // This wont work
//You have to create a new object as indicated below
var Bessie = new Cow();
//You will see the default values
Bessie.says();
Bessie.eats();
Bessie.speak = "Moo";
Bessie.food = "Hay";
//You see your newly set values
Bessie.says();
Bessie.eats();

So can you use the same concept to inherit from multiple classes? Yes.

You can inherit from multiple classes and keep adding to the current class.

Eg

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
var Animal = function() {
this.speak = "no speak set";
this.food = "no food set";
this.action;
this.says = function() {
console.log(this.speak);
};
this.eats = function() {
console.log(this.food);
};
this.actions = function() {
console.log(this.action);
};
};
var Farm = function() {
this.farm = "no farm";
this.whichFarm = function() {
console.log(this.farm);
};
};
var Cow = function () {
Animal.call(this);
Farm.call(this);
};
var Bessie = new Cow();
Bessie.says();
Bessie.eats();
Bessie.whichFarm();
Bessie.speak = "Moo";
Bessie.food = "Hay";
Bessie.farm = "Old Mc Donald's";
Bessie.says();
Bessie.eats();
Bessie.whichFarm();

Be a better developer by thinking of many solutions

I try challenge my code on a regular bases. I have noticed my code get better the more I pause and question if it definitely is the best solution.

The goal is to solve a problem

I have a lot of designers for friends and what I have noticed is how designers approach their projects.

Brain storm

Designers tackle projects by brainstorming. They go sit and think about lots (and lots and lots) of creative ideas. They want a big collection of ideas, and then they want to take the top 3 or 5 (or 10 even) from that list.

As developers we should try this as well.

Brain storm naming conventions, folder structures, reusable services, tests, constants, best practices, useful abstractions etc. Will a new developer understand the code you have written? Is the code understandable without comments?

There are many aspects to the code you write that if overlooked could incur technical debt. Think about a big picture solution.

Have goals

When you start your code, decide what you need to achieve as a holistic solution. Certain goals should come with any final solution:

  • Is the code easy to test? Do the tests help make sure the code keeps working? (This is for developers who partake in the TDD approach).
  • Is the code self documenting? Is it easy to hand over to a new developer without any teaching required?
  • Can the code be altered easily?
  • Is the naming conventions consistent with the rest of the project?
  • Is the file and folder structure consistent and intuitive? Will other developers have to go on an Easter egg hunt to find the right file?
  • Can design patterns like SOLID help make the code neater?
  • Are your methods doing too much? Can you separate the code further?
  • Are best practices being used?

The list can go on and on. You should always keep these types of questions in your mind, and think of new ones to push your skills.

Beware the problem dressed as a solution

The first solution is not always the best solution. And be skeptical if you can only think of one solution. Our brains can be lazy. Ever have that situation where the easiest way to solve a problem becomes the most problematic to maintain?

A solution should not come at a high maintenance cost. Solutions should not be short term. Else you have just created another problem. Might not be a problem now, but it will be a problem eventually.

Will the real slim shady please stand up

Take the time to brainstorm and think of many ways to solve the problem you are facing. Have enough foresight to see which solution is the real long term solution.

Avoid technical debt. It will whittle away at your project and slowly destroy your passion for what you do.

Also keep in mind the team you work with. Designers, developers, strategists, project managers, business analysts, etc. Do not code something at the expense of the team’s efforts. Always remember to communicate often.

Code solutions, not problems. Word.

Plan your code

I have a mantra at this current point in my life:

If you need documentation to explain your code, your code is too complicated, but if you can’t create the documentation with ease, your logic is too complicated.

I have been reading “Introduction to systems analysis and design, an agile iterative approach”. And it has reinforced that mantra in the way I approach my development.

Planning is a very important part of development. I encourage all developers to pause and take some time to plan your code before you actually put any code to screen.

Also take the time to learn how other developers plan their work. Many use UML as a solution for planning their projects.

When you plan you allow for a big picture approach. Think about the code as a piece to a whole.

The logic should feel simple by the time you start adding code.

Documentation is good to have, especially if you need another developer to take over a project. It lessens the bus factor. I find documentation has become less as a means to explain code, and more of a means to understand the logic of the whole project.