After seeing 1000 ctors

I heard it a lot of times. When I was learning Java, a flash definition about constructor methods faded away in the classroom. A “silly” definition that nobody seemed to remember a bunch of years later.

Sometimes the things that are easily forgotten are the most basic principles. We take them as a fact and we rarely reevaluate them.

One of the basics in OOP is the role of a constructor method:

A constructor method is a special method that contains ONLY the required initializations for the instance to be created in a valid state, ready to be used.

Said this, any constructor what invokes complex methods, services to retrieve data, contains lots of lines of code, or even loops, IS A MISTAKE and needs to be fixed.

A constructor has to be minimum! The instance should be created just in time and any complex initialization should be the responsibility of any other method of the instance.

This answer on Stack Overflow is very good. Be sure to read it 🙂 and keep you ctors clean!

http://stackoverflow.com/questions/1183531/how-much-work-should-the-constructor-for-an-html-parsing-class-do

Modelo inusual: Núcleo de la composición contendor/contenido.

¡Saludos, ávidos reventadores de teclados!

Después de consultarlo con algunos krakens de la escena y ser guiado por ellos he decidido ponerme manos a la obra y darle al diseñador de diagramas para ilustrar lo que creo que me han contado. Y parece ser que el núcleo de la composición es esto.

ClassDiagram1

Aunque como mis facultades están a nivel de 2 de Agosto, tullido mentalmente y con hambre de bollos, puede que se me esté escapando la esencia de lo que me han contado (¡que soy muy torpe a veces!).

De esta manera podríamos tener el mismo elemento en varios contenedores, de manera que podríamos escribir el siguiente código:


        public void AddTwoRelationsForTheSameObject()
        {
            var element = new ComposableElement { Name = "Element1"};

            var rel1 = new Emplacement { Left = 0, Top = 0, Target = element };
            var rel2 = new Emplacement { Left = 20, Top = 10, Target = element };

            element.Contents.Add(rel1);
            element.Contents.Add(rel2);
        }

Como podéis ver, los elementos no poseen de forma intrínseca unas coordenadas, sino que la relación (Emplacement) es quien completa esos datos del modelo.

El problema que publiqué ayer podría empezar con algo así, ¿qué os parece? ¿Errado o fetén?

Caso de un modelo inusual: Elementos relacionados con la presentación.

¿Qué pasa, chavales? A pesar de que normalmente no me lee ni el Tato, ayer mantenía una “conversación” por Twitter, dentro de lo puede ser una conversación en Twitter, con @XaviPaper y con @gulnor. Era sobre un modelo un tanto raro que incluye objetos que normalmente estarían representados directamente en la interfaz gráfica de usuario y no en el modelo. En este caso, los elementos gráficos SON EL MODELO. Se presenta, pues, un problema un tanto atípico. Fundamentalmente, las relaciones son de contenedor/contenido y lo primero en lo que he pensado es en un patrón Composite que incluya a la mayoría de elementos del modelo. También es interesante el tema de que la estructura no es un árbol, sino un grafo. Algunos elementos especiales (formularios) pueden tener más de un padre.

Aquí va todo el enunciado con la descripción completa del problema.

ABSTRACTO

En mis ratos en casa estoy construyendo una especie de maquetador de formularios dinámicos. ​​​​El usuario puede añadir elementos a un formulario, arrastrarlos a diferentes posiciones, redimensionarlos y cambiar sus propiedades. Llegado el momento, el usuario decidirá “renderizar” el formulario y donde corresponda, los elementos del formulario que son dinámicos (campos) tomarán un valor “real” formulario de acuerdo con una fuente de datos (sea un XML, una tabla de una base de datos, un archivo CSV…). Esto sería algo similar a lo que hacen los Bindings en XAML.

He estado dándole vueltas al coco para hacer un modelo flexible, elegante y que “hable” por sí mismo.

He probado varias cosas y no me acaban de convencer. O bien es demasiado restrictivo o demasiado permisivo. T​e​n​g​o​ ​u​n​ ​p​a​r​ ​d​e​ ​prototipos actualmente, pero he decidido no seguir adelante porque la implementación y el modelo empiezan a no casar como me gustaría.

El dominio es un documento destinado a la presentación/impresión, con la particularidad de que habrá partes dinámicas que dependerán de una fuente de datos (por ejemplo, un XML, un archivo de texto o una base de datos).

Podéis imaginar que es un PDF que acepta una fuente de datos “externa” y renderiza el contenido dependiendo de la misma. Si dentro del documento existe un campo que hace referencia a un dato llamado “NombreUsuario”, en el proceso de renderizado, el campo tomará el valor de esa variable y en el campo podrá, por ejemplo “Pepito López”.

ESPECIFICACIONES

Un documento está compuesto de páginas. El tamaño de las páginas es un tamaño estático (ancho x alto). El usuario podrá cambiar el tamaño de la página, pero no estará enlazada con datos (al contrario que los campos dinámicos).

Una página (formulario) está compuesta otros elementos que pueden ser:

  1. Formas (rectángulos, líneas, elipses…). No tienen ningún tipo de dinamismo.
  2. Campos dinámicos: textos. Se enlazan a una variable y se reemplaza al renderizarse.
  3. Imágenes dinámicas: Imágenes. De acuerdo a un token (o ruta de acceso) se pone una imagen u otra.​
  4. Textos fijos.
  5. Elementos compuestos.
  6. Tablas
    1. Tablas cuyos elementos son generados dinámicamente: se sabe el número de columnas, pero no el número de filas.
    2. Tablas cuyos elementos (m x n) se conocen, aunque su contenido puede ser variable.
    3. COMPOSICIÓN: Podrán tener imágenes, texto, campos ¡u otras tablas! Es más puro estilo tablas embebidas de Word o HTML
  7. Gráficos estadísticos
    1. El valor de las variables es dinámico
  8. Secciones (COMPOSICIÓN). Es una especie de contenedor cuyo contenido, además de elementos de su mismo tipo, puede contener todos los anteriores.
  9. El tamaño de una sección es el tamaño que ocupen sus elementos hijo.

Todos los elementos tienen ancho y un alto. La manera de indicar la posición que ocuparán en la página es mediante coordenadas absolutas respecto al punto superior izquierdo de su contenedor.

NOTA. Una sección puede estar contenida en varias páginas o en varias secciones. Es decir, si la página 1 y la 2 comparten la misma sección y la modificamos, el cambio se reflejará en ambas páginas. A la hora de componer una sección a base de otras, la restricción será que una sección no podrá contenerse a sí misma, recursivamente.

Los elementos compuestos me vuelven un poco loco, porque son bastante dinámicos. Por ejemplo, en el caso de una tabla, no solamente las filas se generan de acuerdo a la fuente de datos, sino que los elementos de cada columna son dinámicos ​​​y además hay composición (recursivamente una celda de una tabla puede contener una tabla u otro elemento complejo).

También el tema de la composición de elementos, dudo en cómo se podría hacer.

¿Qué opináis, lobos de mar? ¿Es todo tan jodido como parece? ¿Tengo que hacerme un sistema de layout de doble pasada como el de  WPF para solucionar el tema?

Espero que opinéis 😀 ¿Alguna propuesta?

Más adelante trataré de poner algún diagrama de los que he estado haciendo.

Desde el núcleo hasta las ventanitas

Solamente una reflexión. He notado que en mi código me gusta todo sólido, FUERTEMENTE TIPADO, que en la medida de lo posible, todo quede atado y bien atado.

Sin embargo, en la parte de la UI que representa el modelo me gusta poder elegir entre tipar o no hacerlo en absoluto. Hay situaciones en las que puede interesar indicar el contexto a nivel de tipo, otras veces no solamente no quiero, sino que me gusta que sea completamente dinámico.

A este respecto casa perfectamente C# + XAML + MVVM. Todo lo que se salga de esa concepción me resbala BIG TIME!

ICollection<T> vs IEnumerable<T> vs IList<T>

Por si las dudas, hermoso.

IEnumerable, ICollection, and IList (generally, any type with an I prefix) are just interfaces. They let you expose what your class will do, but unlike if you inherit a class, interfaces do not provide you a default implementation of any of the things they say you must do.

As far as choosing which interface, here’s a quick guide:
An IList is an ICollection that can be accessed by index.
An ICollection is an IEnumerable with easy access to things like Add, Remove, and Count.
An IEnumerable is anything that can be enumerated, even if the list of those things doesn’t exist until you enumerate it.

Some classes that you might want to extend (or keep as a private field that runs most of the logic) for your collection are List<T>, Collection<T>, (which implements IList<T>, but with easier access to overriding implementation, see Collection<T> versus List<T> what should you use on your interfaces? for the big differences between these two) ObservableCollection<T>, or collections that are not lists, like Dictionary<T, U> and HashSet<T>. For more info on any of these, look up the MSDN documentation on the class.