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. So in the above code example the comparison becomes:
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'.
var x = "string";
This would print true.
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.