En esta entrega, vamos a detallar el proyecto que construiremos a lo largo de esta serie. Se trata de un sistema IoT de monitoreo y control ambiental compuesto por varios dispositivos interconectados. El sistema consta de tres tipos de unidades: Sensor Unit, Central Unit y Actuator Unit. Vamos a explorar cada uno de estos dispositivos y cómo interactúan entre sí y con la nube.

Descripción del Proyecto

Sensor Unit

Las Sensor Units son los dispositivos encargados de recopilar datos ambientales. Cada Sensor Unit incluye los siguientes componentes:

• Sensor de humedad
• Sensor de temperatura
• Sensor de calidad del aire
• MCU (Microcontrolador) que lee los datos de los sensores y los envía a la Central Unit.

La comunicación entre las Sensor Units y la Central Unit se realizará utilizando la tecnología LoRaWan, que permite la transmisión de datos a larga distancia con bajo consumo de energía.

Central Unit

La Central Unit es el corazón del sistema y actúa como un LoRaWan Gateway. Sus funciones principales son:

• Recepción de datos: Recibe las lecturas de las Sensor Units a través de LoRaWan.
• Procesamiento de datos: Analiza los datos recibidos para determinar el estado ambiental.
• Comunicación con la nube: Utiliza WiFi y el protocolo MQTT para enviar los datos procesados a un servidor en la nube.
• Configuración remota: Recibe configuraciones y parámetros desde una aplicación web alojada en la nube.
• Visualización local: Incluye una pantalla para mostrar los datos actuales de las mediciones en cada estancia y el estado de los relés.

Actuator Unit

La Actuator Unit es responsable de realizar acciones basadas en las decisiones tomadas por la Central Unit. Sus componentes y funciones incluyen:

• MCU que recibe mensajes desde la Central Unit vía LoRaWan .
• Relé que controla dispositivos como ventiladores o humidificadores.
• Ejecutar acciones: Activa o desactiva el relé según las órdenes recibidas de la Central Unit.
• Comunicación entre los Dispositivos LoRaWan
• Sensor Unit a Central Unit: Utiliza LoRaWan para transmitir datos de humedad, temperatura y calidad del aire.
• Central Unit a Actuator Unit: Utiliza LoRaWan para enviar comandos de control a la Actuator Unit. WiFi y MQTT
• Central Unit a la nube: Usa WiFi para conectarse a internet y MQTT para enviar datos ambientales al servidor en la nube.
• Nube a Central Unit: La configuración y los parámetros se envían desde la aplicación web a la Central Unit usando MQTT. Infraestructura en la Nube
• El sistema en la nube constará de los siguientes componentes:
  • Backend (Web API): Gestionará las peticiones y la lógica de negocio, exponiendo los datos y configuraciones necesarios.
  • Frontend (Angular): Proporcionará una interfaz web interactiva donde los usuarios podrán ver las mediciones en tiempo real y ajustar los parámetros del sistema.
  • Job de Azure: Se encargará de gestionar la comunicación con el broker MQTT, asegurando que los mensajes se envían y reciben correctamente.
  • Application Insights: Se utilizará para almacenar logs y realizar análisis posteriores de posibles errores, facilitando la monitorización y el mantenimiento del sistema. Flujo de Trabajo
  • Lectura de Datos: Las Sensor Units toman lecturas de humedad, temperatura y calidad del aire.
  • Transmisión de Datos: Las lecturas se envían a la Central Unit vía LoRaWan.
  • Procesamiento de Datos: La Central Unit procesa los datos para determinar las condiciones ambientales y muestra los resultados en su pantalla.
  • Subida a la Nube: Los datos procesados se envían a la nube usando WiFi y MQTT.
  • Configuración Remota: Los usuarios pueden ajustar parámetros y configuraciones desde una aplicación web.
  • Acciones en Actuator Unit: La Central Unit envía comandos a la Actuator Unit para activar o desactivar dispositivos como ventiladores o humidificadores.

Diagrama del Sistema

Conclusión

En esta serie de publicaciones, guiaremos paso a paso cómo construir cada uno de estos dispositivos, configurar las comunicaciones y desarrollar la interfaz web para gestionar el sistema. En la siguiente entrega, entraremos en la selección de los componentes necesarios para construir las Sensor Units, la Central Unit y las Actuator Units. ¡Vamos a sumergirnos en el emocionante mundo de la IoT!

Volver a la primera parte

El siguiente video es una muestra de las dos opciones más básicas que tienes para hacer un despliegue en Azure desde Visual Studio 2017.

While watching a Coursera course of functional programming, I saw a Scala class that I liked in concept and implementation. It's a utility class and is called Try. Now that C# 7 includes pattern matching I thought it was time to review it and pass it to C#.

The Try class represents the result of a function with the expected value or an exception. The purpose is that you can leave your clean code exception management and errors.

But, previous to talk in details about Try, let me to do an introduction to Monad and other implementations.

Monad, Maybe and Try

First, all this term have relation with functional programming, and the way to resolve problems with this paradigm. To an introduction to the topic, you can follow this link.

Monad When using sequenced operations, with monad you can structure the code. Another term most descriptive to this is computation builder. The monad allows us to create pipelines that process data in steps, with additional process rules provided by the monad. Also, can be seen as a functional design pattern for building generic types.

Maybe<T> is a container of type T that may be present or not. It's a monad implementation. It has only one implementation.

Try<T> represents an operation. If it's successful return T, else some subclass of 'Exception'. As Maybe, it's a monad implementation. You create two different subType of Try, Success<T> when the operation is Ok, and Failure<T> when found errors or handling exceptions. Internally, the Failure contains the exception.

Problem

First, to understand the need, I will present the original scenario with an elementary example. We have a function that finds data in the database and then passes that data to another process as arguments. Simple, but a pipeline. For simplicity, it'll be synchronous.

var dbResult = repository.GetData("parameter");  
var result = anotherProcess(dbResult);  

The code above is not bad, but it's too much optimistic. The search operation can at least give a timeout. When you start programming with try-catch block, the code is no longer expressive, as the next code.

customer dbResult;  
try  
{
   dbResult = repository.GetData("parameter");
}
catch (TimeOutException toEx)  
{
   //cut to simplify
}
catch (Exception toEx)  
{
   //cut to simplify
}
var result = anotherProcess(dbResult);  

Solution

The Try class helps us to encapsulate the result and the exception, and whether it is one thing or another is as easy as it is a concrete class or another.

The syntax we use when using a try is as follows:

Try t = f1(x);  
Try y = f2(t);  

So, in the end, is a monad, as the class Maybe, where f1 would be the ToMaybe and f2 would be the projection of the person's address

Maybe personaMaybe = persona.ToMaybe();  
Maybe direccionMaybe = personaMaybe.Select(p=>p.Direccion);  

Like the class Maybe can be put in the chain of operations or pipelines, and catching the exception in the same chain. In the case that was an exception, we have to ensure that the first exception is encapsulated and don't lose the reason and callStack of the original exception.

Implementing Try

The implementation has three parts, an ITry interface, one class that represents the successful result and another class representing a failure

public interface ITry<T>  
{
    T Value { get; }

    ITry<U> Select<U>(Func<T, ITry<U>> mapper);
}

In this case, i add only one operation - Select - to make a mapping between to types.

In the case of the class that represents the failure, the exception comes by the constructor

public class Failure<T> : ITry<T>  
{
    private readonly Exception ex;
    public Failure(Exception ex)
    {
        this.ex = ex;
    }

    public T Value
    {
        get { throw new InvalidOperationException("Can't get value for failed Try"); }
    }

    public ITry<U> Select<U>(Func<T, ITry<U>> mapper)
    {
        return ex.ToFailed<U>();
    }

    public Exception GetException()
    {
        return ex;
    }
}

Please, take a minute to see the Select method.This method is inside the failure class, then don't execute the mapper, on the contrary, the function returns the same exception that was passed in the constructor. Thereby you don't miss the exception that causes the failure, nor the callStack.

public class Success<T> : ITry<T>  
{
    public Success(T newValue)
    {
       Value = newValue;
    }
    public T Value { get; private set; }

    public ITry<U> Select<U>(Func<T, ITry<U>> mapper)
    {
        if (mapper == null)
        {
            return new Failure<U>(new ArgumentNullException(nameof(mapper)));
        }
        try
        {
           return mapper(Value);
        }
        catch (Exception ex)
        {
            return new Failure<U>(ex);
        }
    }
}

The last step, create a extension class to simplify the creation of Failure or Success instance.

public static class TryExtension  
{
    public static ITry<T> ToSucess<T>(this T data)
    {
        return new Success<T>(data);
    }

    public static ITry<T> ToFailed<T>(this Exception ex)
    {
        return new Failure<T>(ex);
    }
}

In the client side, you must know if you had success or not the operations. For this reason, you need patterns matching, the new feature in C#7. The result would be something like this.

var searchResult = customerRepository.GetCustomer(index);  
var processResult = ProcessData(searchResult);

switch (processResult)  
{
    case Success<CustomerDTO> success:
    {
        Console.WriteLine(success.Value.CustomerId);
        break;
    }
    case Failure<CustomerDTO> fail:
    {
        Console.WriteLine($"Problems when get customer. Error : { fail.GetException().Message}");
        break;
    }
}

The switch command can be replaced by if command since we have only two options.

All the source code you can be found on Github.

Conclusion

One important property of Try class is the ability to pipeline or chain, operations and caching exceptions along the way. This class provides some default behaviour in the case of failure. It's error handling, in a functional way.
The last changes on C# 7 allow us to access some high-level features to apply functional programming.

Picture try again by Sean MacEntee, is licensed under Creative Commons BY-2.0..

When you work on different projects and also sometimes you have to do an architecture, there comes a time when you realise that it would be great to create a solution template with your projects and dependencies.

You could read this post in Spanish here

More than once I wanted to create a template in visual studio that had the typical thing that you need to make a solution in three layers. The times I wanted to do I found a problem, the cost/benefit ratio. It's very costly to create a template for a solution - it's already difficult for a project template - utility time may be relatively small (think about the times they changed from Visual Studio 2012 to Visual Studio 2017 to just create a web project). Also, Visual Studio changes support for templates arbitrarily amongst versions. Then came out yeoman with their generators and I forgot a bit about this.

Dotnet CLI ... to the rescue

But seeing what could be done from the dotnet CLI command line, I took it back with new hopes. And I want to share my results.

First, my problem about cost benefit was solved in full. It took me 30 minutes to see it was doable and 3 hours until I had the script I will show you. And unlike a Visual Studio template, this also works for me on Mac and Linux.

The idea is to create the backend skeleton for a typical 3 layer architecture in .NET.
The requirements are:

1. The solution must have the following projects:
   • Web API
   • Messages used in the web API signature
   • Application layer,
   • Business layer,
   • Data layer,
   • Entities,
   • Testing projects.
2. All projects must be linked to the solution.
3. Each project will have references to the other projects it uses. In addition, when necessary they will have references that are in nuget.
4. Also, I want you to have a directory structure that separates the test code from the application code.
5. Another thing I have to add to projects is gitignore, so I will download it from the repository that is on GitHub where there are different gitignore dependent on the development tool you use.
6. Restore references for all projects.
7. I will compile the solution. Not just a project.
8. Open the solution with Visual Studio Code.

The final idea is to open a bash and write "Bash createBackend3Layer.sh SolutionName".

What do you need to have installed?

• .Net Core
• The latest .net core SDK.
• If you have any problem, download the latest dotnet CLI build from the repository releases on GitHub.

Let's go for it !!

If you want to follow the article with the downloaded code, you have it in this GitHub repository.

Variable declaration

We take the name of the solution that was put as a parameter and we'll create the solution file inside a folder with the same name. If the solution is called "CodeCrafters", there will be "CodeCrafters / CodeCrafters.sln". Same as if you did with Visual Studio.
For each project, I'll use three variables for

• The project name
• The folder where the project will reside
• The path where the project file will reside

Remember that at this point I am already fulfilling the requirement of placing the code in one directory and tests in another. The code will reside in the src folder and the tests in the test folder

SolutionName=$1;  
SolutionFile="$SolutionName/$SolutionName.sln";  
gitIgnorePath="$SolutionName/.gitignore";  
projExt=".csproj";

WebApiName="$SolutionName.WebApi";  
WebApiPath=${SolutionName%%/}/src/$WebApiName;  
WebApiProj=${WebApiPath%%/}/$WebApiName$projExt;  

Creating the solution

We'll tell dotnet CLI to create a solution in a directory called the same as the solution.
Just a detail, to be able to differentiate the steps that will be executed from the script of the rest of values ??that will be written in the console I put the first ones of light green colour.

echo -e "\033[1;92m Create solution \033[0m"  
dotnet new sln -n $SolutionName -o "$SolutionName"  

Create the projects

In the GitHub script you have all the projects, but here I am giving an example of the three types of projects that are created.
As for directories, the idea is that the API Web Project is in "CodeCrafters / src / CodeCrafters.WebApi / CodeCrafters.WebApi.csproj"
In all of them, I am putting the same framework. In your 2.0 version, you can make the framework come as an optional parameter.😁
Class library projects can be projects that reference net Standard, and you can specify as a framework the netstandard from 1.0 to 1.6

dotnet new webapi -n $WebApiName -o "$WebApiPath" -f netcoreapp1.1  
dotnet new classlib -n $AppLayerName -o "$AppLayerPath" -f netcoreapp1.1  
dotnet new xunit -n $AppLayerTestName -o "$AppLayerTestPath" -f netcoreapp1.1  

Use a gitignore

There is a repository in GitHub that has the different gitignore depending on the tools you use. With the following command line, you can download it from Github and save it in the root folder of the solution.

curl -o $gitIgnorePath 'https://raw.githubusercontent.com/github/gitignore/master/VisualStudio.gitignore'  

This same mechanism can be used for other files in common use, such as a settings file of StyleCop.

Link the projects with the solution.

You can not leave projects as islands, they belong to a solution and you have to link them. In this line below you look for all the projects and execute the command that links them to the solution.

for refProj in `find $SolutionName -name '*.csproj'` ;  
  do dotnet sln $SolutionFile add $refProj ;  
done

Note: This command can be used to execute all test projects. I invite you to make a script that compiles on your computer and run the tests. You already have 50%, you can not complain 😁

for unitTestProj in `find $SolutionName -name '*UnitTest.csproj'` ;  
  do dotnet test $unitTestProj ;  
done 

Cross-project references

To show that the WebApi project requires the Business Layer project you have to execute the following command

dotnet add $WebApiProj reference $BLayerProj 

External References

You can download the external packages from a nuget server, but first look at which references each project brings by default.
For example, the API Web project already brings the MVC package.

dotnet add $DALayerProj package Microsoft.EntityFrameworkCore --package-directory $SolutionName/packages 

If you are looking for packages that are not in nuget you must specify the URL with the -s parameter.

dotnet add $DALayerProj package Microsoft.EntityFrameworkCore -s https://dotnet.myget.org/F/dotnet-core/api/v3/index.json  

With everything so far you would have enough, but let's continue to obtain the maximum grade. 👍

Restore packages

The nuget packages that you need were already downloaded in the previous step, but those that are predetermined in the projects, such as Microsoft.AspNetCore weren't. Let's download now.

for proj in `find $SolutionName -name '*.csproj'` ;  
  do dotnet restore $proj ;  
done 

Compile the solution

Here we build the solution, not just a project. When compiling it already detects the dependency between projects.

dotnet msbuild $SolutionFile

(Optional) Open solution in Visual Studio Code

If you have VSCode in your command path, loading the solution is very easy

code $SolutionName

(Recommended) Upload a first version to a local git

In Mac and Linux, git comes already integrated into bash, in windows you have to install it. The idea is that you can start a local repository of git and make the first commit with the solution as I left after running the whole script.

pushd $SolutionName  
git init  
git add --all && git commit -m "Code generate by @CodeCraftersEs"  
popd  

"But Daniel ... this last one was not among the requirements ..." Well, I always like to surprise my clients giving something more than they wait for. 😁

Conclusion

Three years ago I did an Angular demo and I used yeoman from the command line to create an MVC web solution. Some saw it as "a step back" because it should be all visual and integrated into Visual Studio.

I think dotnet CLI has opened a different door, one that .net programmers are not as used as node programmers with npm, and it is the use of command line. This is no longer a DevOps thing that makes a script in PowerShell to do something in Azure. Now we can create solutions, add projects, download references, and those commands that we already knew - like Add-migration and UpdateDatabase of Entity Framework - and join them in a single script.

but... ¿why I should learn functional programming?

You could read this post in Spanish here.

For your professional life, it is very good that you handle at least three types of languages

• Object Oriented (c #, java)
• Dynamic (javascript, python)
• Functional (scala, f #, Haskell)

Because behind the language itself, is the way to solve the problem. And that's what costs the most about functional programming. I'm not talking about one being superior to the other, but that they are two different paradigms and it's good that you have them in your mental toolbox.

What do you need to know to continue reading?

• Be familiar with object-oriented programming's (hereinafter OOP) concepts like class, objects, polymorphism, and inheritance
• Must read C#

What do you not need?

• Be an expert on OOP
• Being a ninja of C #
• Know something of Haskell, Scala, F # and other functional languages.

Why do I have to trust in maths?

In Wikipedia, if you are looking for functional programming it says

In computer science, functional programming is a paradigm of declarative programming based on the use of mathematical functions ...

What do maths have that will help me become a better programmer? Why do I have to trust them when they almost ruin my teenage years? :)

Let's start with a simple example. A function that returns the Value Added Tax (hereinafter VAT) for a given amount.
First, we define the function, in maths, it will be VAT(amount, percentageVAT) = amount * (percentageVAT / 100) whereas in C # it will be

public decimal GetVat(double amount, double percentageVAT)  
{
   return (amount * (percentageVAT/100));
}

Now we call the function defined with the value 100 and 21

Doing maths: VAT(100, 21) and in C # var result = GetVAT (100, 21);

From this example, we are able to see 3 things in common that maths and this function of C # have

• They are only dedicated to calculating the VAT.
• The only dependence they have are the input parameters.
• For a set of input parameters, only one output value corresponds to those. No matter how many times I put 100 and 21, I'll always get back 21.

First: The S of solid.

Doing maths, adding only adds. You can combine different formulas, but each one is dedicated to his own, it has only a responsibility, that is to say, they are Single responsibility, the S from SOLID

Now let me put a typical object-oriented programming function, add an invoice detail to an invoice.

void AddLine(InvoiceLine newInvoiceLine)  
{
    this.lines.Add(newInvoiceLine); // 1
    this.totalPrice += newInvoiceLine.Total; //2
}

One of the properties of OOP is encapsulation, and this function acts very well because it hides what happens after adding. But as you have noticed, it does two tasks, 1 - add an item and 2 - recalculate the total.

The first thing you think about is to separate it into two methods

void AddLine(InvoiceLine newInvoiceLine)  
{
  this.lines.add(newInvoiceLine);
}
void UpdateTotal(InvoiceLine newInvoiceLine)  
{
  this.totalPrice += newInvoiceLine.Total;
}

But the problem with this solution is that you generate a dependency between the functions, forcing to place the second call after the first one so that the internal state remains coherent. The real problem is... total is a materialized result, we need to change to a functional result.

decimal GetTotal()  
{
   decimal total = 0;
   foreach(var line in this.lines)
   {
      total += line.Total;
   }
   return total;
}

Now we can remove the totalPrice variable because it is being replaced by the GetTotal function.

We can make the GetTotal function a little different, so it has a more functional style without using the total internal variable, to do this we will use Linq.

decimal GetTotal()  
{
   return this.details.Sum(item => item.Price);
}

Even better, as a read-only property

public decimal Total  
{ 
       get { return Details.Sum(l => l.Total); } 
}

And now, you can write the first functional programming's lesson. When refactoring to functional programming, the internal state of objects is reduced.

Now we have the first completed objective. Each function has a unique responsibility.

Second: No side effects.

When a function causes a change to something out of its range, it is called a side effect. Because of this, the function has to receive everything necessary to be able to complete its responsibility by means of parameters.

Continuing with the example of the invoice, imagine that you have a method named cancel. The moment you cancel the invoice you update the balance of the customer.

private Customer customer;  
public void Cancel()  
{
    this.state = StateKind.canceled;
    this.customer.UpdateBalance(this.GetTotal());
}

Now let's put a scenario where the customer has a balance of 500 € and cancels an invoice of 100 €.

customer.Balance; // 500€  
invoice.Cancel();  
customer.Balance // 600€  

This is a clear example of a side effect and a function that is not mathematical because it does not always return the same result. How can I do so that Cancel becomes a no-side-effect?

Let's return again to the subject of responsibility. It is not the responsibility of cancelling the invoice to update the customer's balance.

public void Cancel()  
{
    this.state = StateKind.canceled;
}

The Customer class will be in charge of receiving an invoice to cancel and thus update your balance. After verifying that the invoice is cancelled, it will adjust the balance.

public class Customer  
{
   void CancelInvoice(Invoice invoice)
   {
      if (invoice.State == StateKind.canceled;)
      {
         this.UpdateBalance(invoice.Total);
      }
   }
}

With this design, we have two good news.
1. The Cancel method no longer needs the customer class. Maybe it is needed on another part of the invoice class, but no longer on this method. This makes the Bounded context of the customer object for the billing system more limited. And maybe we will need an integration event to notify Customer bounded context.
2. In the customer class, the UpdateBalance method can now be a private method.

Returning to the previous example we now have

customer.Balance; // 500€  
invoice.Cancel();  
customer.Balance; // still is 500€  
customer.CancelInvoice(invoice);  
customer.Balance; //now is 600€  

We have moved the responsibility to the customer so it makes two calls sequentially.

Although this design is better, it is not 100% functional, because the Cancel method modifies a variable (state) that is not received as a parameter.

Third: pure functions or referential transparency

In maths, all functions are referentially transparent. The cosine of a 90-degree angle remains 0, no matter how many years have passed and how many times you repeat it, it will always be Cos (90) = 0. No matter how you pass the reference Cos (89 + 1) or Cos (91- 1), it will be the same result.

Let's go back to the AddInvoice function. Although it is perfectly valid in object-oriented programming, in terms of referential transparency it is not, because it changes the internal state when adding an item to the list.

void AddLine(InvoiceLine newInvoiceLine)  
{
  this.lines.add(newInvoiceLine);
}

If we want this function to be a pure and non-side-effect one we need to changes same things:

1 - Expose the properties of the invoice object by the constructor. We going to pass the new state to a new instance.
2 - The internal list of lines change from List to InmutableList. In this way, when we change the collection returns a new immutable list instance.
3 - Create a local function to manage changes in the collection and return an invoice or the same object if we don't have changes.
4 - Adding the item to the immutable collection, and use the previous function.
5 - Change the 'void' by Invoice.

Let's do it. First step. In the future steps, we need to create another invoice instance and pass the new state. One note, When I speak of the state of an object I mean the value of all properties, not just the state property. I'm using one IEnumerable, in this way call this constructor is easier. Inside, I convert it to immutable.

public Invoice(IEnumerable<InvoiceLine> lines, StateKind state)  
{
    this.lines = lines.ToImmutableList();
    State = state;
}

The second step. Change the internal variable as ImmutableList, but keep the public as an IEnumerable.

private ImmutableList<InvoiceLine> lines;  
public IEnumerable<InvoiceLine> Lines  
{
     get { return lines; } 
}

Third step. Local function. If the immutable instance is different, then create a new Invoice. The property state doesn't change, we create the new invoice instance with the same value we have right now.

private Invoice WithLines(IEnumerable<InvoiceLine> value)  
{
      return Object.ReferenceEquals(lines, value)
         ? this
         : new Invoice(value, State);
}

Steps 4th and 5th. When we add an item to the immutable list returns a new instance of an immutable collection, and pass it to the before function.

public Invoice AddLine(InvoiceLine newOrderLine)  
{
    return WithLines(lines.Add(newOrderLine));
}

We have the internal function, then we can add remove line functionality.

public Invoice RemoveLine(InvoiceLine invoiceLine)  
{
    return WithLines(lines.Remove(invoiceLine));
}

What happend with the property State in the Cancel method?
Ok, we change it.

public Invoice Cancel()  
{
    return (State == StateKind.canceled)
        ? this
        : new Invoice(Lines, StateKind.canceled);
}

Second note, when you try to make functional transparency the immutability of the data as goes without saying. That is, immutability is a consequence of the referential transparency that is used in maths.

Ok, right now the invoice class is immutable, all the property are read-only and any change returns a new Invoice instance.

Now, we are going to do the same in Customer class. Change the constructor, the properties to read-only and the method return a new instance.

public class Customer  
{
    public Customer(decimal balance)
    {
        this.Balance = balance;
    }

    public decimal Balance { get; private set; }
    public Customer CancelInvoice(Invoice invoice)
    {
        return (invoice.State == StateKind.canceled)
            ? AddToBalance(invoice.Total)
            : this;
    }

    private Customer AddToBalance(decimal total)
    {
        return new Customer(Balance + toTake);
    }
}

Now let's see how these functions are called. We will start assuming that the detail list has 2 items, one of 5 € and another of 15 €, and the new one we want to add which has a price of 20 €.

List<InvoiceLine> lines = new List<InvoiceLine>  
{
    new InvoiceLine(1, 5),
    new InvoiceLine(1, 15)
};
Invoice invoice = new Invoice(lines, StateKind.incomplete);  
var invoiceWithNewItem = invoice.AddLine(new InvoiceLine(1, 20));  
Console.WriteLine($"older total -> {invoice.Total}");  
Console.WiteLine($"new total -> {invoiceWithNewItem.Total}");  

What's really important here is that no matter how many times you run Total for invoice variable, it'll return 20 always because a) any method that modifies the object invoice return a new invoice instance, b) because the total calculation does not keep any internal data.

Now, we're trying with customer objects

Customer customer = new Customer(500);  
var invoiceCanceled = invoice.Cancel();  
var customerWithInvoiceCanceledProcessed = customer.CancelInvoice(invoiceCanceled);  
Console.WriteLine(customer.Balance); //500  
Console.WriteLine(customerWithInvoiceCanceledProcessed.Balance); //520  

You can find the code here.

Conclusions and next steps/challenges

We saw a very practical introduction to functional programming - so I hope :) - and how maths can help us to program through functions that:

• Just have a single responsibility.
• Have no side effect.
• Use referential transparency.

We saw how this impacted on the design of our application. And how it helps us to think differently when solving a problem.

But we have only scratched the surface, it leaves us with some questions that will be seen in other articles such as:

1 - There is no doubt that immutable data are safe, but what about performance? If I have to add 1000 items to the invoice it will create a thousand different instances of the list to finish up using the last one. What about memory?
2 - If the methods do not save the state that is going to be mutated, what happens to the index variables of the for command or to the item variable in a foreach command?

Today I want to write about some questions people are asking me about the patterns' subject.

You could read this post in Spanish here.

What are they?

Patterns are verified solutions to recurring problems in design and software development. For a solution to be considered a pattern, it must have some characteristics, such as to demonstrate that it can be applied in different technologies, meaning that it is an agnostic and reusable knowledge that can be broken down into well-defined roles or responsibilities, and has demonstrated its effectiveness under certain circumstances. These circumstances have been given the name of forces and are the reasons to use the pattern and to identify it from a different one.

Why I have to know them?

Luckily, there is not a single reason! But there are several reasons for you to know them.

Because you do not need to re-invent the wheel. Patterns try to avoid the repetition to search for solutions from problems already known, so you do not re-invent the wheel.

Because you will go on the shoulders of giants. Yes, yes ... You will be applying solutions that hundreds of architects with a lot of experience have used and refined over the years.

Because they will help you to structure your code. Patterns have well-defined roles or participants. For example, in an Observer pattern, there is the observer and the observed subject. This way you will avoid programming everything together in a single class.

Because they will be part of your developer jargon. This is like police saying "it's a 3218" and understand it they alone. With patterns, you will say "You have to do an Abstract Factory" and all the developers should know what you are talking about. Moreover, they should think about the different roles of the pattern.

Because you will formalize the design. Neither reaching to the extreme case of "To a hammer, all problems look like nails", nor pretending to eradicate creativity, what patterns search for is if your solution has encountered a problem that has an already tested solution. If you have a tree structure in your solution you should encounter yourself with a Composite pattern.

Because they are becoming more known. In recent years, I have seen how different languages and frameworks were adding patterns. Some of them are:

1. Iterators (foreach) in OO languages.
2. Abstract Factory in ADO.NET to create connections and commands.
3. WPF and command to execute UI actions.
4. Aspnet and the radical change in the use of MVC to handle HTTP requests.
5. Js Frameworks which have observables or are MV* (Knockout, Angular, Aurelia, Vue, to name a few) to keep the HTML updated.
6. Rx.Net and the use of *observables.
7. NodeJs and its event loop. If you want to know why Node is so fast you should know this pattern.
8. Redux and its immutable state.

If someone approaches you and tells you that patterns are a waste of time and are used by only 4 geeks, you already have arguments to say that it is not the case.

Because they will be the best professional investment you can make. This is not a Javascript framework that appears today and in 6 months appears another one, and you have to be jumping from a "Getting Started" to another. This is a basic knowledge that you then apply in different programming languages. If you still have doubts I'm going to tell you my experience. I learned about patterns before the year 2000. At that time I was programming Visual Basic 6, that was not 100% object oriented because it had interfaces, and it hadn't inheritance. I started to develop patterns that were based on interfaces like the adapter or strategy pattern with VB, and for those languages which used inheritance, I started to write them in Java until on 2001 I could start doing on C #. About 2 years ago, I had to work on a project where I applied user interface patterns with typescript. How much technological knowledge can you use after 15 years?

But I am already doing this !!

It's possible that if you structure your code well you are already using some pattern without knowing it. If you are in that group, you are a machine! Now learn the pattern's name and you will be able to communicate better with other programmers.

Do I need to know them all?

No, it's not necessary. My advice is to first try to link the problem - or as I said at the beginning, the forces - and the name of the pattern that solves it. When you have the problem, remembering the name you can search the internet to see some implementation in a blog or in GitHub. Then start to learn well the ones you see more often.

What you must know is that there are different patterns for different paradigms or scopes. To name a few you have patterns for object-oriented programming, functional programming, cloud, concurrency, domain driven design, etc.

What's the difference between development principles?

I'll explain it with an example. If you want to design a car that has adhesion, you have to do it with front-wheel drive. This is an example of a recurring problem and linked solution, namely a pattern. Following the example, the principles would be the basic rules for an engine to work.

Development principles are a guide that helps you have an easy-to-maintain and an easy-to-change code, and not being fragile in the face of change - something you touch on one side and stops working on the other side. To me, development principles are before patterns, and patterns often apply these principles.

Do they always have to be used?

No, forcing the use of a pattern is often a mistake. Let's go back to the previous question for a minute. There is a principle called YAGNI, which comes to say to not do something you do not need. And believe me, there are two things you will never need, a poorly built architecture and an over-architecture, which in the end is nothing more than a poorly built architecture.

Conclusion

I have used patterns for over 15 years and I will continue to use them for the advantages they offer. I urge you to learn about them and also use them. The benefit cost is amazing.

Cuando vas trabajando en diferentes proyectos y además algunas veces te toca hacer arquitectura, llega un momento en que te das cuenta que estaría muy bien crear un template de una solución con sus proyectos y dependencias.

Más de una vez quise crear un template en visual studio que tuviera lo típico que necesitas para hacer una solución en tres capas. Las veces que lo quise hacer me encontré con un problema, la relación coste/beneficio. Es muy costoso crear un template de una solución - ya lo es el template de un proyecto - el tiempo de utilidad podría ser relativamente poco (piensa las veces que ha cambiado desde Visual Studio 2012 al Visual Studio 2017 la creación de un proyecto web). Además Visual Studio cambia el soporte a los templates arbitrariamente entre versión y versión. Después apareció yeoman con sus generadores y me olvidé un poco de esto.

Dotnet CLI... to the rescue

Pero al ver lo que se puede hacer desde la línea de comandos de dotnet cli, lo retome con nuevas esperanzas. Y quiero compartir mis resultados.

Lo primero, mi problema sobre el coste beneficio se resolvió de pleno. Tarde 30 minutos en ver que era viable y 3 horas hasta tener el script que te muestro. Y a diferencia de un template de Visual Studio, esto también me funciona en Mac y Linux.

La idea es crear el esqueleto de una backend típico en .net como puede ser una arquitectura de 3 capas.
Los requerimientos son:

1. La solución tiene que tener los siguientes proyectos:
   
   • web api,
   • Mensajes usados en la firma del web api
   • application layer,
   • business layer,
   • data layer,
   • entidades,
   • proyectos de pruebas.
2. Todos los proyectos deberán estar asociados a la solución.
3. Cada proyecto tendrá las referencias a los otros proyectos que usa. Además, cuando sea necesario tendrán referencias que estén en nuget.
4. Además, quiero que cuente con una estructura de directorios que separe el código de pruebas del código de aplicación.
5. Otra de las cosas que me toca agregar a los proyectos es el gitignore, así que me lo descargaré del repositorio que está en GitHub donde hay diferentes gitignore dependientes de la herramienta de desarrollo que uses.
6. Restaurar las referencias de todos los proyectos
7. Compilare la solución. No solo un proyecto.
8. Abrir la solución con Visual Studio Code.

La idea final es abrir un bash y escribir "Bash crearBackend3Capas.sh NombreSolucion".

¿Que necesitas tener instalado?

• .Net Core
• El último SDK de .net core.
• Si tienes algún problema, bájate el último build de dotnet cli desde las release del repositorio en GitHub.

¡¡Vamos a por ello!!

Si quieres seguir el artículo con el código descargado, lo tienes en este GitHub.

Declaración de variables

Tomamos el nombre de la solución que se puso como parámetro y creamos el archivo de la solución dentro de una carpeta con el mismo nombre. Si la solución se llama "CodeCrafters", quedará "CodeCrafters/CodeCrafters.sln". Igual que si lo hicieras con Visual Studio.
Por cada proyecto uso tres variables para

• el nombre del proyecto
• la carpeta donde se pondrá el proyecto
• el path donde estará el archivo del proyecto

Recordar que en este punto ya estoy cumpliendo el requisito de colocar el código en un directorio y los test en otro. El código irá a src y las pruebas a test

SolutionName=$1;  
SolutionFile="$SolutionName/$SolutionName.sln";  
gitIgnorePath="$SolutionName/.gitignore";  
projExt=".csproj";

WebApiName="$SolutionName.WebApi";  
WebApiPath=${SolutionName%%/}/src/$WebApiName;  
WebApiProj=${WebApiPath%%/}/$WebApiName$projExt;  

Crear la solución

Le decimos a dotnet cli que nos cree una solución en un directorio llamado igual que la solución.
Un detalle, para poder diferenciar los pasos que se van ejecutan del script del resto de valores que se escribirán en la consola pongo los primeros de color verde claro.

echo -e "\033[1;92m Create solution \033[0m"  
dotnet new sln -n $SolutionName -o "$SolutionName"  

Crear los proyectos

En el script en GitHub tenes todos los proyectos, pero aquí pongo un ejemplo de los tres tipos de proyectos que se crean.
En cuanto a directorios, la idea es que el Proyecto de Web Api este en "CodeCrafters/src/CodeCrafters.WebApi/CodeCrafters.WebApi.csproj"
En todos estoy poniendo el mismo framework. En tu version 2.0 puedes hacer que el framework venga como un parámetro opcional. 😁
Los proyectos de tipo librería de clases pueden ser proyectos que referencien net Standart, puedes especificarle como framework el netstandard1.0 al 1.6

dotnet new webapi -n $WebApiName -o "$WebApiPath" -f netcoreapp1.1  
dotnet new classlib -n $AppLayerName -o "$AppLayerPath" -f netcoreapp1.1  
dotnet new xunit -n $AppLayerTestName -o "$AppLayerTestPath" -f netcoreapp1.1  

Poner un gitignore

Hay un repositorio en GitHub que tiene los diferentes gitignore según la herramientas que uses. Con la siguiente línea de comandos lo bajas de Github y lo grabas en la carpeta raíz de la solución.

curl -o $gitIgnorePath 'https://raw.githubusercontent.com/github/gitignore/master/VisualStudio.gitignore'  

Este mismo mecanismo te puede servir para otros archivos de uso común, como puede ser un archivo de settings de StyleCop.

Asociar los proyectos a la solución.

No puedes dejar los proyectos como islas, pertenecen a una solución y tienes que asociarlos. En esta línea de abajo buscas todos los proyectos y le ejecutas el comando que los asocia a la solución.

for refProj in `find $SolutionName -name '*.csproj'` ;  
  do dotnet sln $SolutionFile add $refProj ;  
done  

Nota: Este comando te puede servir para ejecutar todos los proyectos de test. Te invito a que te hagas un script que en tu ordenador compile y ejecute los test. Ya tienes el 50%, no te puedes quejar 😁

for unitTestProj in `find $SolutionName -name '*UnitTest.csproj'` ;  
  do dotnet test $unitTestProj ;  
done  

Referencias entre proyectos

Para indicar que el proyecto de WebApi necesita del proyecto de Business Layer tienes que ejecutar el siguiente comando

dotnet add $WebApiProj reference $BLayerProj  

Referencias externas

Puedes bajarte de un servidor de nuget los paquetes externos, pero primero mira que referencias trae en forma predeterminada cada proyecto. Por ejemplo, el proyecto de Web Api ya trae el paquete de MVC.

dotnet add $DALayerProj package Microsoft.EntityFrameworkCore --package-directory $SolutionName/packages  

Si buscas paquetes que no están en nuget debes especificar la url con el parámetro -s

dotnet add $DALayerProj package Microsoft.EntityFrameworkCore -s https://dotnet.myget.org/F/dotnet-core/api/v3/index.json  

Con lo que llevas hasta el momento ya tendrías suficiente, pero seguimos para matricula de honor. 👍

Restaurar paquetes

Los paquetes de nuget que tu necesitas ya se descargaron en el paso anterior, pero los que estan predeterminados en los proyectos, como Microsoft.AspNetCore no. Ahora toca descargarlos.

for proj in `find $SolutionName -name '*.csproj'` ;  
  do dotnet restore $proj ;  
done  

Compilar la solución

Acá hacemos un build de la solución, no solo de un proyecto. Al compilar ya detecta la dependencia entre proyectos.

dotnet msbuild $SolutionFile  

(opcional) Abrir la solución en Visual Studio Code

Si tienes VSCode en el path cargar la solución es facilísimo

code $SolutionName  

(recomendable) Subir una primera version a un git local

En Mac y Linux el git viene integrado en el bash, en windows tienes que instalarlo. La idea es que puedas iniciar un repositorio local de git y hacer un primer commit con la solución como quedo después de ejecutar todo el script.

pushd $SolutionName  
git init  
git add --all && git commit -m "Code generate by @CodeCraftersEs"  
popd  

"Pero Daniel... esto último no estaba entre los requerimientos..." Es que siempre me gusta sorprender a mis clientes dando algo mas de los que esperan. 😁

Conclusión

Hace tres años atrás hice una demo de angular y use yeoman desde la línea de comandos para crear una solución web mvc. Algunos lo vieron como "un paso atrás", que tenía que ser todo visual e integrado en Visual Studio.

Creo que con dotnet CLI se ha abierto un melón diferente, uno al que los programadores .net no estamos tan acostumbrados como los programadores node con npm, y es el uso de la línea de comandos. Esta ya no es cosa de devOps que hacen un script en powershell para hacer algo en Azure. Ahora podemos crear soluciones, agregar proyectos, descargar referencias, y aquellos comandos que ya conocíamos - como Add-migration y UpdateDatabase de Entity Framework - unirlos en un solo script.

Hoy quiero escribir sobre algunas preguntas que me hacen sobre el tema patrones.

¿Qué son?

Los patrones son soluciones contrastadas a problemas recurrentes en el desarrollo y diseño de software. Para que una solución se considere un patrón debe tener algunas características como, por ejemplo, demostrar que se puede aplicar en diferentes tecnologías, es decir es un conocimiento agnóstico y reusable, que puede descomponerse en responsabilidades o roles bien definidos, y que ha demostrado su eficacia bajo ciertas circunstancias. A esas circunstancias se le da el nombre de fuerzas y son los motivos para usar el patrón y para identificarlo de otro diferente.

¿Porque tengo que conocerlos?

Por suerte ¡no hay un solo porqué! sino que hay varios motivos para que los conozcas.

Porque no necesitas reinventar la rueda. Los patrones pretenden evitar la reiteración de búsquedas de soluciones a problemas ya conocidos, que no re inventes la rueda.

Porque iras en hombros de gigantes. Si, si... Estarás aplicando soluciones que cientos de arquitectos con muchísima experiencia han usado y refinado a lo largo de los años.

Porque te ayudarán a estructurar tu código. Los patrones tienen roles o participantes bien definidos. Por ejemplo, en un patrón Observer, está el que observa y el sujeto observado. De esta manera evitaras programar todo junto en una sola clase.

Porque serán parte de tu jerga de desarrollador. Esto es como la policía que dice “es un 3218” y lo entienden solo ellos. Pues con los patrones dirás “Hay que hacer un Abstract Factory” y todos los desarrolladores deberían saber de qué estás hablando. Es más, deberían pensar en los diferentes roles del patrón.

Porque formalizaras el diseño. Sin llegar al caso extremo de “Para un martillo todos los problemas son clavos”, ni tampoco pretendiendo erradicar la creatividad, lo que buscan los patrones es que si tu solución se ha encontrado con un problema que tenga la solución testeada. Si en tu solución tienes unas estructuras de árbol deberías encontrarte con un patrón Composite.

Porque se están dando a conocer más. En los últimos años, he visto como diferentes lenguajes y framework iban agregando patrones. Algunos de ellos son:

1. Los iteradores (foreach) en lenguajes OO.
2. Abstract Factory en ADO.NET para crear conexiones y comandos.
3. WPF y los commands para ejecutar acciones de UI.
4. Aspnet y el cambio radical en el uso de MVC para gestionar las peticiones http.
5. Framework js de tipo MV* y los observables (Knockout, Angular, Aurelia, Vue, por nombrar algunos) para mantener el html actualizado.
6. Rx.Net y el uso de observables.
7. NodeJs y su event loop. Si quieres saber porque Node es tan rápido debes conocer este patrón.
8. Redux y su estado inmutable.

Si alguien se te acerca y te dice que los patrones son una pérdida de tiempo y que lo usan 4 friquis, ya tienes argumentos para decir que no es así.

Porque serán la mejor inversión profesional que puedes realizar. Esto no es un framework de Javascript que hoy sale uno y en 6 meses otro y tienes que estar saltando de un “Getting Started” o a otro. Esto es un conocimiento base que después vas aplicando en diferentes lenguajes de programación. Si todavía te quedan dudas te cuento mi experiencia. Aprendí sobre patrones antes del año 2000. En aquel entonces programaba en Visual Basic 6, aquel que no era 100% orientado a objetos porque tenia interfaces, pero no tenía herencia. Empecé a desarrollar patrones que se basan en interfaces como adapter o strategy con VB, y para los que usan herencia empecé a escribirlos en Java, hasta que en el 2001 pude hacerlos en C#. Hace cosa de 2 años, me tocó trabajar en un proyecto donde aplique patrones en la interfaz de usuario con typescript. ¿cuanto conocimiento tecnológico puedes usar despues de 15 años?

Pero si esto yo ya lo hago!!

Es muy posible que si estructuras bien tu código ya estés usando algún patrón, pero sin saberlo. Si estas en ese grupo, ¡eres un maquina! Ahora apréndete el nombre del patrón y podrás comunicarte mejor con otros programadores.

¿Hace falta conocerlos todos?

No, no hace falta. Mi consejo es que primero intentes asociar el problema - o como decia al principio, las fuerzas - y el nombre del patrón que lo resuelve. Cuando tengas el problema, recordando el nombre podrás buscarlo en internet para ver alguna implementación en algún blog o en GitHub. Después apréndete bien aquellos que consultes más.

Lo que si tienes que saber es que hay diferentes patrones para diferentes paradigmas o ámbitos. Por nombrar algunos tienes patrones de programación orientada a objetos, de programación funcional, de cloud, de concurrencia, de domain driven design, etc.

¿Qué diferencia hay con los principios de desarrollo?

Te lo explico con un ejemplo. Si quieres diseñar un coche que tenga adherencia, tienes que hacerlo con tracción delantera. Esto es un ejemplo de problema recurrente y solución asociada, es decir un patrón. Siguiendo con el ejemplo, los principios serían las normas básicas para que un motor funcione.

Los principios de desarrollo representan una guía que te ayuda a tener código fácil de mantener y fácil de cambiar, y que no sea frágil ante el cambio - aquello de que tocas en un lado y deja de fusionar otro. Para mis los principios están antes que los patrones, y los patrones suelen aplicar estos principios.

¿Hay que usarlos siempre?

No, forzar el uso de un patrón suele ser un error. Volvemos por un minuto a la pregunta anterior. Hay un principio que se llama YAGNI, que viene a decir que no hagas algo que no necesitas. Y créeme, hay dos cosas que nunca necesitaras, una arquitectura mal hecha y una sobre-arquitectura, que al final no es otra cosa que una arquitectura mal hecha.

Conclusión

He usado patrones por más de 15 años y seguiré usándolos por las ventajas que ofrece. Te insto a que puedas aprender sobre ellos y usarlos. El coste beneficio es bestial.

Actualizado el 03/Mayo/2017 - Se agrega el uso de colecciones immutables.

pero ... ¿porque necesito saber programación funcional?

Para tu vida profesional es muy bueno que manejes al menos tres tipos de lenguajes

• Orientado a Objetos (c#, java)
• Dinámico (javascript, python)
• Funcional (scala, f#, Haskeel)

Porque detrás del lenguaje en si, esta la forma en resolver el problema. Y eso es lo que más cuesta de la programación funcional. No hablo de que una es superior a la otra, sino que son dos paradigmas diferentes y que es bueno que las tengas en tu caja de herramientas mental.

¿Que necesitas saber para seguir leyendo

• Estar familiarizado con los conceptos (clase, objetos, polimorfismo y herencia) de programación orientada a objetos (POO en adelante)
• Poder leer código c#

¿Que no necesitas?

• Ser un experto en POO
• Ser un maestro ninja de c#
• Conocer algo de Haskeel, Scala, F# y otros lenguajes funcionales.

¿porque tengo que confiar en las mates?

En la wikipedia, si buscas programación funcional dice

En ciencias de la computación, la programación funcional es un paradigma de programación declarativa basado en el uso de funciones matemáticas...

¿que tienen las mates que me ayudaran a ser mejor programador? ¿porque tengo que confiar en ellas cuando casi arruinan mi adolescencia? :)

Vamos a empezar con un ejemplo sencillo. Una función que me devuelve el iva de un importe dado.
Primero definimos la función, en mates sera IVA(importe, porcentajeIva) = importe * (porcentajeIva/100) mientras que en C# sera

public decimal GetVat(double amount, double percentageVAT)  
{
   return (amount * (percentageVAT/100));
}

Ahora llamamos a la función definida con el valor 100 y 21

En mates IVA(100, 21) y en C# var result = GetVat(100, 21);

De este ejemplo, vemos 3 cosas en común que tienen las mates y esta función de c#

1. Solo se dedican a calcular el iva.
2. La única dependencia que tienen es hacia las variables de entrada.
3. Para un conjunto de valores de entrada solo le corresponde un valor de salida. No importa cuantas veces ponga 100 y 21, siempre me devolverá 21.

Primero: La S de solid.

En las mates, sumar solo suma. Puedes hacer que se combinen diferentes fórmulas, pero cada cual se dedica a lo suyo, tiene una sola responsabilidad, es decir son Single responsability, la S de SOLID

Ahora déjame poner una función típica de programación orientada a objetos, agregar un detalle de factura a una factura.

void AddLine(InvoiceLine newInvoiceLine)  
{
    this.lines.Add(newInvoiceLine); // 1
    this.totalPrice += newInvoiceLine.Total; //2
}

Una de las propiedades de la programación orientada a objetos en la encapsulación, y esta función lo cumple muy bien porque oculta lo que sucede después de agregar. Pero como bien te haz dado cuenta, hace dos tareas, 1 - agrega un item y 2 - recalcula el total.

Lo primero que piensas es en separarlo en dos métodos

void AddLine(InvoiceLine newInvoiceLine)  
{
  this.lines.add(newInvoiceLine);
}
void UpdateTotal(InvoiceLine newInvoiceLine)  
{
  this.totalPrice += newInvoiceLine.Total;
}

Pero el problema de esta solución es que generas una dependencia entre las funciones, teniendo que ser la segunda llamada luego de la primera para que el estado interno siga siendo coherente. Así que vamos a cambiar la clase para que el total sea una función en lugar de un resultado materializado.

decimal GetTotal()  
{
   decimal total = 0;
   foreach(var line in this.lines)
   {
      total += line.Total;
   }
   return total;
}

Ahora podemos quitar variable totalPrice porque es reemplazada por la función GetTotal.

Podemos hacer la función GetTotal un poco diferente, que tengo un toque más funcional sin usar la variable interna total, para ello usaremos Linq.

decimal GetTotal()  
{
   return this.details.Sum(item => item.Price);
}

O mejor aún, como una propiedad de solo lectura

public decimal Total  
{ 
       get { return Details.Sum(l => l.Total); } 
}

Ahora bien, apunta la primer lección de la programación funcional. Cuando refactorizas hacía programación funcional el estado interno de los objetos se reduce.

Ahora tenemos el primer objetivo completo. Cada función tiene una única responsabilidad.

Segundo: Sin efectos colaterales.

Cuando una función causa un cambio en algo fuera de su alcance, se llama side effect. Para ello la función tiene que recibir todo lo necesario para poder completar su responsabilidad por medio de parámetros.

Continuando con el ejemplo de la factura, imagina que tienes un método llamado cancelar.En el momento que cancelas la factura actualizas el saldo del cliente.

private Customer customer;  
public void Cancel()  
{
    this.state = StateKind.canceled;
    this.customer.UpdateBalance(this.GetTotal());
}

Ahora pongamos un escenario donde el cliente tiene un saldo de 500 € y se cancela una factura de 100 €.

customer.Balance; // 500€  
invoice.Cancel();  
customer.Balance // 600€  

Este es un ejemplo claro de side effect y de una función que no es matemática ya que no devuelve siempre el mismo resultado. ¿Como puedo hacer para que Cancelar sea no-side-effect?

Pues otra vez volvemos al tema de responsabilidad. No es la responsabilidad de cancelar la factura actualizar el saldo del cliente.

public void Cancel()  
{
    this.state = StateKind.canceled;
}

La clase Cliente será la encargada de recibir una factura para cancelar y así actualizar su saldo. Después de verificar que la factura está cancelada, ajustará el saldo.

public class Customer  
{
   void CancelInvoice(Invoice invoice)
   {
      if (invoice.State == StateKind.canceled;)
      {
         this.UpdateBalance(invoice.Total);
      }
   }
}

Con este diseño tenemos dos buenas noticias.
1. El método Cancelar ya no necesita de la clase cliente. Puede que en otra parte de la clase factura si, pero este metodo ya no. Esto hace que el alcance (Bounded context) del objeto cliente para el sistema de facturación quede más limitado.
2. En la clase cliente ahora el método ActualizarSaldo puede ser un método privado.

Volviendo al ejemplo anterior ahora tenemos que

customer.Balance; // 500€  
invoice.Cancel();  
customer.Balance; // still is 500€  
customer.CancelInvoice(invoice);  
customer.Balance; //now is 600€  

Le hemos pasado la responsabilidad al cliente para que haga las dos llamadas en forma secuencial.

A pesar que este diseño es mejor, no es 100% funcional, porque el método Cancelar modifica una variable (estado) que no se recibe por parámetro.

Tecero: funciones puras o transparencia referencial

En mates, todas las funciones son referencialmente transparentes. El coseno de un ángulo de 90 grados sigue siendo 0, no importa cuantos años han pasado y cuantas veces lo repitas, siempre Cos(90) = 0. No importa como le pases la referencia Cos(89+1) o Cos(91-1), te dará lo mismo.

Volvamos a la función AddInvoice. Aunque es perfectamente valida en programación orientada a objetos, en términos de transparencia referencial no lo es porque cambia el estado interno al agregar un ítem a la lista.

void AddLine(InvoiceLine newInvoiceLine)  
{
  this.lines.add(newInvoiceLine);
}

Para que esta función sea una función pura y no-side-effect necesitamos algunas cosas

1 - Poner un constructor donde le poner todas las propiedades del objeto.
2 - La lista interna que esta como List, pasarla a ImmutableList.
3 - Crear una funcion local que maneje los cambios en la coleccion, y si hay cambios que retorne una nueva instancia de la clase Invoice.
4 - Agregar el item a la lista immutable.
5 - Devolver una nueva instance de Invoice en lugar del void que hay ahora.

Pues manos a la obra. Primero paso. En los siguientes pasos necesitaremos crear una nueva instancia de Invoice con los nuevos valores. PAra ello necesitamos un constructor. En el constructor usaremos un IEnumerable para hacer la llamada al constructor mas facil, pero internamente lo convertimos a Immutable.

public Invoice(IEnumerable<InvoiceLine> lines, StateKind state)  
{
    this.lines = lines.ToImmutableList();
    State = state;
}

Segundo paso.

private ImmutableList<InvoiceLine> lines;  
public IEnumerable<InvoiceLine> Lines  
{
     get { return lines; } 
}

Tercer paso. Nuevo metodo local. Si la instancia de immutable list son diferentes, entonces hay que crear un nuevo objeto Invoice.

private Invoice WithLines(IEnumerable<InvoiceLine> value)  
{
      return Object.ReferenceEquals(lines, value)
         ? this
         : new Invoice(value, State);
}

Cuarto y quinto paso. Devolver la nueva instancia.

public Invoice AddLine(InvoiceLine newOrderLine)  
{
    return WithLines(lines.Add(newOrderLine));
}

Que pasa con el metodo Cancel? Lo haremos immutable tambien.

public Invoice Cancel()  
{
    return (State == StateKind.canceled)
        ? this
        : new Invoice(Lines, StateKind.canceled);
}

Nota dos, cuando intentas hacer transparencia funcional cae por su propio peso la inmutabilidad de los datos. Es decir, la inmutabilidad es una consecuencia de la transparencia referencial que se usa en las mates.

Genial!! Ahora la clase invoice es immutable, todas sus propiedades son de solo lectura y los metodos devuelven una nueva instancia cuando realizan un cambio.

Ahora, hacemos lo mismo en la clase Customers.

public class Customer  
{
    public Customer(decimal balance)
    {
        this.Balance = balance;
    }

    public decimal Balance { get; private set; }
    public Customer CancelInvoice(Invoice invoice)
    {
        return (invoice.State == StateKind.canceled)
            ? DiscountFromBalance(invoice.Total)
            : this;
    }

    private Customer DiscountFromBalance(decimal toTake)
    {
        return new Customer(Balance - toTake);
    }
}

Ahora veamos como se llama a estas funciones. Empezaremos suponiendo que la lista de detalles tiene 2 items, uno de 5 € y otro de 15 €, y el nuevo que queremos agregar tiene un precio de 20 €.

List<InvoiceLine> lines = new List<InvoiceLine>  
{
    new InvoiceLine(1, 5),
    new InvoiceLine(1, 15)
};
Invoice invoice = new Invoice(lines, StateKind.incomplete);  
var invoiceWithNewItem = invoice.AddLine(new InvoiceLine(1, 20));  
Console.WriteLine($"older total -> {invoice.Total}");  
Console.WriteLine($"new total -> {invoiceWithNewItem.Total}");  

Lo realmente importante aquí es que no importa cuantas veces ejecutes invoice.Total; siempre te devolverá 20 porque a) todos los metodos retornan una nueva instancia y b) porque el calculo del total no guarda ninguna información interna.

Ahora lo haremos con la clase customers.
Entonces ahora lo vemos así

Customer customer = new Customer(500);  
Console.WriteLine(customer.Balance);  
var invoiceCanceled = invoice.Cancel();  
var customerWithInvoiceCanceledProcessed = customer.CancelInvoice(invoiceCanceled); 

Console.WriteLine(customerWithInvoiceCanceledProcessed.Balance);  

Conclusiones y próximos pasos / desafios

Vimos una intro muy práctica de programación funcional -eso espero :) - y de cómo las mates nos pueden ayudar a programar por medio de funciones que:

1. Solo tengan una responsabilidad.
2. Sean no side effect.
3. Usen transparencia referencial.

Vimos como impacto esto en el diseño de nuestra aplicación. Y cómo nos ayuda a pensar diferente a la hora de resolver un problema.

Pero solo hemos rascado un poco, nos deja algunas preguntas que iremos viendo en otros artículos como:
1 - No cabe duda que los datos inmutables son seguros, pero ¿qué pasa con el rendimiento? Si tengo que agregar 1000 item a la factura creará mil instancias diferentes de la lista para terminar usando sola la última. ¿Que pasa con la memoria?
2 - Si en los métodos no se guarda estado que vaya mutando, ¿qué pasa con las variables de índice del comando for o con la variable de item en un foreach?