Paul Kent

Let's look at the example code below and its output in JS Bin:

var x = "string";

console.log("!!x is " + (!!x));
console.log("x == true is " + (x == true));

You might be surprised that the second statement actually prints false instead of true, even though both sides of the == operator are truthy values. So why is this the case?

This is because when you're using the double equals operator (==) and you're comparing a string with a boolean, both values first get converted to a Number and then they are compared.

If we convert a boolean to a number then a true converts to 1 and false converts to 0. A string like '1' can be converted to 1 but a string like 'string' can't be converted to a number so it gets converted to NaN.

NaN == 1

Now NaN compared to anything is false. Hence the expression ends up being false.

If you want to see if a value is truthy, use the not operator twice (!!). This is also known as 'double bang'.

For example:

var x = "string";

console.log(!!x);

This would print true.

Reference:

http://stackoverflow.com/questions/4923631/why-does-ifstring-evaluate-string-as-true-but-if-string-true-does-not

I made this short video to explain what Dependency Injection is and how to use it to create loosely coupled and easily Unit Testable components.

S - Single Responsibility Principle

O - Open/Closed Principal

L - Liskov Substitution Principal

I - Interface Segregation Principal

D - Dependency Inversion Principal

The Single Responsibility Principal states that a class should only be responsible for doing one type of thing, not multiple things. For example an OrderCalculator class should not contain methods that do calcuations and sending emails. Instead any other responsibilities should be separated out and placed into another class.

The Open/Closed Principal states that a design should be open for extension and closed to modification. It means that you should not have to edit an existing class in order to add new functionality. Instead you should be able to add a new class to add new functionality. That way by adding a new class you are not touching any existing code and this means that the chance of breaking something is significantly reduced.

The Liskov Substitution Principal states that subtypes must be substitutable for their base types.

The Interface Segregation Principal tells us that we shouldn't create fat interfaces. Instead we should create lots of smaller interfaces instead. For example if you have a client that only need to do VerifyLogin(username, password) then why create an interface with 100 methods on it?

The Dependency Inversion Principal allows us to create loosely coupled components.