Category Archives: Diseño

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!


Number of attibutes in a class

Anything more than 10 attributes is starting to smell.

“No shit is accepted.”

Courtesy of Javier Peris Morillo.

ICollection vs IEnumerable vs IList

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.

Translator Pattern. Know Your Patterns :)




This pattern is really simple. It provides a method to convert from a representation to another. The same concept can be represented in many ways. Sometimes you have to “import” and “export” representations, so you have to provide a proper encapsulation for the logic that converts from one object to another.

Why would you need to do that? In my personal experience I have used it to convert instances of “legacy” clases that are not too well designed. It happens that a lot of logic already exists in the solution that work with those clases, so redefining them would be really expensive. The brand new features use better an more robust clases. For newer parts, I use a translator to perform a one time time conversion. When a legacy part of the application needs a “new” instance, I request a conversion to the old class instance.

It can be seen as a pattern similar to Adapter or Builder. But Adapter translates interfaces and provide a “wrapper” that interacts between the outer world and the wrapped classes along all its lifecycle. Builder creates complex objects. It’s a similar pattern, but I don’t feel it’s the same as the builder doesn’t translate, it builds up an instance.

What do you think about it? Do you see a Builder here? Smile

Differences between Abstract Factory / Builder / Adapter

When it comes to patterns, it’s important to know the differences. Sometimes you have to name a class and you tend to call it “a X-builder”, or a “X-Generator”. But… are you sure you gave it the correct name?

It’s important to name things properly in our projects. From variables, to methods and classes. It REALLY matters. Even more when you are part of a team. When we are implementing a pattern we should give every entity the right now to avoid ambiguity.

In this particular case, those patterns may seem to do similar things, but they don’t. So, how to identify each one?


I hope somebody is kind enough to point out the differences between them. Come on, participate! Comments are welcome.

Handling selected items in a parent. Part 2.

Last time I tried to put you down to the problem: you have a container and some children. We wanted to handle the selection of items.

Until now we had to decide who will be the one that is in charge of setting the IsSelected property of each child. At first glance, we can see that the child itself is the Information Expert in which we can delegate the responsibility. After all, the children carry the  IsSelected property!

Well, I think it’s true, but that makes the design unnecessarily complex.


Imagine a Single selection mode! Just like ListBoxes have. Just one item can be selected.

I gave you a hint in the last post. It works as you should expect: Each click in a child selects it, but it also makes the previous children to be unselected.

“Wow, boy, it sounds pretty simple!”

I prepared you for the answer: it’s not the child that controls its IsSelected property… it’s the PARENT! In my opinion, it’s the only that can observe the changes and control the flow of events. If a child is clicked, the parent must know. Why? Because the it can decide if the change is allowed of not.

What way, you can even have some selection modes. For example, you can have a selection mode that toggles selection when a child when it’s clicked, or one in which you always add items.

In other words, it gives you a lot of variants to choose.

This is what I finally chose in my personal designer and I think it’s the right decision. What do you think? would you have solved the situation like me? Sonrisa C’MON tell me.