Posted on

SOLID principles using Typescript

SOLID principles using Typescript

SOLID principles using Typescript

SOLID principles using Typescript

SOLID principles using Typescript

The following article explains SOLID principles using Typescript.

Here are more articles about Typescript:

Introducing Typescript

Introducing Typescript: Language features

SOLID is an acronym for the first five object-oriented design(OOD) principles by Robert C. Martin, popularly known as @UncleBob.

The five SOLID principles are:

  • Single responsibility principle: a class should have one, and only one, reason to change;
  • Open-closed principle: it should be possible to extend the behavoir of a class without  modifying it;
  • Liskov Substitution principle: subclasses should be substitutable for their superclasses;
  • Interface segregation principle: many small, client-specific interfaces are better than one general purpose interface;
  • Dependency inversion principle: depends on abstractions not concretions;

These principles, make it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development.

The Single Responsibility Principle (SRP)

The SRP requires that a class should have only one reason to change. A class that follows this principle performs just few related tasks. You don’t need to limit your thinking to classes when considering the SRP. You can apply the principle to methods or modules, ensuring that they do just one thing and therefore have just one reason to change.

 

Example – wrong way

The class Task defines properties related to the model, but it also defines the data access method to save the entity on a generic data source:

UML

 

SOLID principles using Typescript - SRP wrong way

Code

Example – right way

The  Task class can be divided between Task class, that takes care of model description and TaskRepository that is responsabile for storing the data.

UML

 

SOLID principles using Typescript - SRP right way

Code

 

The Open-closed Princple (OCP)

 Software entities should be open for extension but closed for modification.

The risk of changing an existing class is that you will introduce  an inadvertent change in behaviour. The solution is create another class that overrides the behaviour of  the original class. By following the OCP, a component is more likely to contain maintainable and re-usable code.

Example – right way

The CreditCard class describes a method to calculate the monthlyDiscount(). The monthlyDiscount() depends on the type of Card, which can be : Silver or Gold. To change the monthly discount calc, you should create another class which overrides the monthlyDiscount() Method.

The solution is to create two new classes: one for each type of card.

UML

SOLID principles using Typescript - OCP Right

Code

The Liskov Substitution Principle (LSP)

Child classes should never break the parent class’ type definitions.

The concept of this principle was introduced by Barbara Liskov in a 1987 conference keynote and later published in a paper together with Jannette Wing in 1994.

As simple as that, a subclass should override the parent class methods in a way that does not break functionality from a client’s point of view.

Example

In the following example ItalyPostalAddress, UKPostalAddress and USAPostalAddress extend one common class: PostalAddress.

The AddressWriter class refers PostalAddress: the writer parameter can be of three different sub-types.

UML

SOLID principles using Typescript - LSP Right

Code

The Interface Segregation Principle (ISP)

It is quite common to find that an interface is in essence just a description of an entire class. The ISP states that we should write a series of smaller and more specific interfaces that are implemented by the class. Each interface provides an single behavior.

 

Example – wrong way

The following Printer interface makes it impossible to implement a printer that can print and copy, but not staple:

Example – right way

The following example shows an alternative approach that groups methods into more specific interfaces. It describe a number of contracts that could be implemented individually by a simple printer or simple copier or by a super printer:

The Dependency inversion principle (DIP)

The DIP simply states that high-level classes shouldn’t depend on  low-level components, but instead depend on an abstraction.

Example – wrong way

The high-level WindowSwitch depends on the lower-level CarWindow class:

UML

SOLID principles using Typescript - DIP wrong way

Code

Example – right way

To follow the DIP, the class WindowSwitch should references an interface (IWindow) that is implemented by the object CarWindow:

UML
SOLID principles using Typescript - DIP right way

Code

Final thoughts

Typescript make it possible to bring all of the principles and practices of OOP into your software, using SOLID principles to guide your design patterns.

Here’s the GitHub repository containing the full examples.

Posted on

.NET Core and MVC: Customize view paths

Customize view paths

.NET Core: Customize view paths

.NET Core: Customize view paths

Download from github

Customize view paths

Intro

The .NET Core is finally released 🙂 !!  I wrote about .NET Core a lot of times:

Future of ASP.NET is open source and cross platform

Introducing ASP.NET 5 on Ubuntu

Introducing vNext and MVC6

What is .NET Core?

ASP.NET Core is a lean and composable framework for building web and cloud applications. ASP.NET Core is fully open source and available on GitHub. ASP.NET Core is available on Windows, Mac, and Linux.

 

Usually, .NET Core tries to search views in the following folders  by using the following names( {1} is the Controller name, {0} is the Action method name):

~/Views/{1}/{0}.cshtml
~/Views/Shared/{0}.cshtml

 

This article shows how to customize views paths and names by extending RazorViewEngine and  IViewLocationExpander.

Customize views name

You may need to rewrite the name of searched view , For example:

~/Views/{1}/{0}.vary1.cshtml
~/Views/Shared/{0}.vary2.cshtml

 

UML solution

To customize views name is necessary to extend the RazorViewEngine class, I’ve called the subclass CustomViewEngine:

CustomViewEngine

Code solution

Here is the implementation of CustomViewEngine.cs class:

Important: the Concat method @ line 41 is used to maintain the original locations.

You also need to add the CustomViewEngine class to your Startup.cs file:

Customize view paths

.NET also allows to customize the paths of views, for example :

~/CustomViews/{1}/{0}.cshtml
~/CustomViews/Shared/{0}.cshtml

 

UML solution

To override views path is necessary to extend the IViewLocationExpander class, the subclass name is  CustomViewLocator :

CustomViewLocator

Code solution

Here is the implementation of CustomViewLocator.cs class:

You also need to add the CustomViewLocator class to your Startup.cs file:

Conclusion

.NET Core 1.0 offers a lot ways to customize itself by using OOP fundamentals. As open source framework, Companies and user can rewrite and customize every single part of it.

It is also very easy access to the source code, which is available on Github.

The repo of this article is available here.

Cheers 🙂

Posted on

Hack is cool

Hack is cool

Hack is cool

 

Hack is cool
The last week I’ve participated to my first hackathon, I enjoyed it very much and  I had the opportunity to collaborate with people from London.

There are a lot of reason to take part in a hackathon:

  • Learning new techniques and technologies come out all the time, and a hackathon is often a good way for developers to try out something new;
  • Collaboration between people from different business teams, which have a common purpose;
  • Creating and Making. Hackathons allow you to write software in an entirely different area for a change, letting you flex mental muscles that don’t often get used during your day job;
  • Having fun with your hack team;

Why companies need to host hackathons?

  • Innovation: hackathons can solve all kinds of challenges ranging from day-to-day workflow issues to software solutions to customer service concerns or even the creation of new products;
  • Community creation: hackathons are useful to create an innovation community;
  • Developer engagement: hackathons help establish two-way conversations between those that develop the technology (APIs, APKs) and the people that use them;
  • Recruitment:  hackathons are the better way to testing a candidate’s capabilities of handling challenges in the workplace;

What about my hack?

I have collaborated with 2 software developers and one product owner, here is our purpose:

A Facebook Messenger bot that will interact with customers and show product recommendations based on their input

We have used facebook developers API to build the Bot, and Wit.ai to improve the AI.

Conclusion

Keep in mind, hack is cool and fun. Hackathons increase your teamwork skill and they gives you the chance to improve your technical skills.

Cheers 🙂