Carlos Peix

As I said before, it’s a valuable experience for me to keep in touch with different development teams.

Last week we were discussing the best method to validate domain model objects. My first response to that question is: model objects should never be invalid, in the first place.

Each domain object should be fully initialized in its constructor, either by initializing default values or receiving values ​​from the constructor.

Sometimes someone says that does not appreciate consructors with 20 parameters, then I question if the object is large because one or more objects are not yet discovered.

Not to make this post too long, suppose we agree that completely initialize the object with valid values ​​in the constructor and that no public method allows us to modify the state leaving it invalid. In this case, it is never necessary to validate our object because we know that it can never be invalid.

And here we come to the practice recommended to fellow developers last week: if it’s not trivial to validate a data and, once validated, to build the object, then use a Builder. Builder’s responsibilities are:

• Make sure you have all the necessary data to construct the object
• Provide a friendly interface for specifying the data
• Construct the object

The following example “fluent API”:

public class InvoiceBuilder {
    private Customer _customer;
    private DateTime _date;

    public InvoiceBuilder WithCustomer(Customer customer) {
        _customer = customer;
        return this;
    }

    public InvoiceBuilder WithDate(DateTime date) {
        _date = date;
        return this;
    }

    public Invoice Build() {
        AssertDataCompleteAndValid();
        return new Invoice(_customer, _date);
    }

    private void AssertDataCompleteAndValid() {
        if (_customer == null)
            throw new ArgumentNullException("customer");

        if (_date < DateTime.Today)
            throw new ArgumentOutOfRangeException("date");
    }
}

And this code would be used this way:

var invoice = new InvoiceBuilder().
    WithCustomer(jose).
    WithDate(DateTime.Today).
    Build();

See you!

Como ya he dicho antes, el estar en contacto con equipos de desarrollo me resulta una experiencia muy valiosa.

Estábamos la semana pasada discutiendo sobre el mejor método para validar objetos del modelo de dominio. Mi primera respuesta ante esa pregunta es: nunca los objetos del modelo debieran estar inválidos, en primer lugar.

Cada objeto de dominio debiera inicializarse completamente en su constructor, ya sea inicializando valores por defecto, ya sea recibiendo valores desde el inicializador.

Algunas veces alguien menciona que no aprecia los constructores con 20 parámetros a lo cual respondo con un cuestionamiento sobre si realmente ese objeto debe ser tan “grande” o si hay uno o mas objetos no descubiertos aun.

Para no hacer esta entrada demasiado larga, supongamos que acordamos que inicializamos completamente el objeto, con valores válidos en el constructor y que ningún método publico nos permite modificarlo dejándolo en estado invalido (1). En este caso, nunca es necesario validar nuestro objeto puesto que sabemos que, si esta instanciado, nunca puede ser inválido.

Y aquí llegamos a la práctica que recomendé a unos colegas la semana pasada: si no es trivial validar una serie de datos y, una vez validados, construir el objeto, entonces usen un Builder. Las responsabilidades del Builder son varias:

• Asegurarse de tener todos los datos necesarios para construir el objeto
• Proporcionar una interfaz amigable para la especificación de todos los datos
• Construir el objeto

A continuación ejemplo con “fluent API”:

public class FacturaBuilder {
    private Cliente _cliente;
    private DateTime _fecha;

    public FacturaBuilder ConCliente(Cliente cliente) {
        _cliente = cliente;
        return this;
    }

    public FacturaBuilder ConFecha(DateTime fecha) {
        _fecha = fecha;
        return this;
    }

    public Factura Build() {
        AssertDatosSuficientesYCorrectos();
        return new Factura(_cliente, _fecha);
    }

    private void AssertDatosSuficientesYCorrectos() {
        if (_cliente == null)
            throw new ArgumentNullException("cliente");

        if (_fecha < DateTime.Today)
            throw new ArgumentOutOfRangeException("fecha");
    }
}

Y este código se usaría de esta manera:

var factura = new FacturaBuilder().
    ConCliente(jose).
    ConFecha(DateTime.Today).
    Build();

Nos vemos!

Ayer comencé el curso Elementos avanzados de arquitectura de software con objetos de 10Pines, a cargo de Hernán Wilkinson (@HernanWilkinson).

Intentaré contar mis vivencias luego de cada una de las 6 clases, sin mucho análisis, en su versión cruda. Luego vendrá el tiempo de las conclusiones.

Antes de comenzar el curso estuve releyendo algún material relevante sobre diseño orientado a objetos (DOO), sobre todo el libro Smalltalk, Object and Desing, de Chamond Liu. Recomiendo este libro que, a pesar de su apariencia sencilla, no tiene desperdicio, una ganga por USD 24.

Vuelvo al curso. Es evidente que Hernán tiene mucha experiencia enseñando “objetos” ya que nos mantuvo interesados durante cuatro horas con tres simples conceptos: objetos, colaboración y mensajes, todo esto sin tocar las computadoras.

Lo primero que nos pidió fue que, momentáneamente, nos olvidáramos de todo lo que sabíamos de diseño orientado a objetos (DOO). Creo que es el enfoque apropiado para el curso ya que es usual que tengamos muchos conceptos mal aprendidos y eso dificultaría bastante el aprendizaje.

Aquellos con los que he hablado del tema sabrán que hace varios años hice mi “click” y comencé a dar el próximo paso en DOO, empezando a prestar mas atención al comportamiento en los objetos y menos al estado.

Ese fue el eje de la clase de ayer, el funcionamiento de cualquier programa consiste en objetos colaborando entre si mediante el envío de mensajes (“aproximadamente” métodos en Java o .NET). Cuales son esos objetos, cuales son esos mensajes forma parte de la tarea difícil del diseñador. Es ahí donde esta la fortaleza del diseño que hará que nuestro código sea fácil de mantener o una verdadera pesadilla.

Hernán destila Smalltalk por los poros y no tiene manera de disimularlo (y creo que tampoco quiere), personalmente valoro mucho esto porque nos permite aprender las técnicas en un entorno puro, ya habrá tiempo luego para “perder flexibilidad” en otras plataformas.

El próximo jueves o viernes la próxima entrega.

Nos vemos.