Mar 20

As we’ve seen, we can define generics in interfaces, classes, delegates and methods. In a previous post, I’ve already mentioned that you cannot define generics for properties. Besides properties, you can’t also define generics  for indexers (aka parameterful properties), events, operators, constructors and finalizers. Notice that these members can use eventual generic type parameters defined at interface or class level, but they cannot introduce their own generic type parameters. Here’s an example of what you can’t do:

public class Test {
public Test<T>( ) {

You might be curious to understand why you cannot define generics for these members. I was curious too…the best answer I got pointed to two interesting facts:

  • it seems like there aren’t really many cases where this feature would be needed.
  • allowing it would mean that the languages would have to be redesigned to allow these features.

The best example for understanding this last point relies in understanding how operators are used. For instance,there’s currently no way to specify a generic type with an operator. Lets walk through a simple example:

var str1 = “Hello, “;
var str2 = “there!”;
var str3 = str1 + str2;

We’re adding two strings through the operator+. Suppose we could use generics when defining the operator+. How would we write the code for specifying the generic type? I mean, would this be a good option?

var str1 = “Hello, “;
var str2 = 1;
var str3 = str1 +<Int32> str2;

In my opinion, that wouldn’t really contribute to improve the readability of the code…and that’s it for now. Stay tune for more.

Mar 08

Greg Young DDD presentation on E-VAN

Posted in DDD       Comments Off on Greg Young DDD presentation on E-VAN

Really interesting talk by Greg Young on DDD and on how to apply CQS to your domain. Recommended.

Dec 10

Is DDD for me?

Posted in DDD       Comments Off on Is DDD for me?

I think it’s really hard to present a definitive definition for Domain Driven Design. In my opinion, Domain Driven Design can be seen as a philosophy for developing applications based on specific domains and their logic where an ubiquitous language use is probably one of its most important features. If you’ve read Eric Evan’s book, then you’d probably agree that Eric hasn’t really introduced (or invented) anything new. On the other hand, you’ll surely noticed that his book (which is responsible for introducing DDD concepts to many!) presents several good design practices, techniques and principles which you can apply to solve problems associated with complex domains. So, in a way, you can see DDD as something that has grouped several known principles for domain modeling.

Now, do pay attention to the term complex! Yes, DDD really shines when you have complex (or complicated) domains. If you don’t have a complicated or complex domain, then probably you won’t be gaining much from DDD. Why? well, because the truth is that you’ll end up paying a penalty for using DDD (it’s really great for expressing relations between domain objects, but not so good for building objects that should be directly consumed by data bound applications). Don’t get me wrong: I do love DDD and I think it has helped me a lot in solving some complex problems. Following its recommendations has led me to deliver some pretty good models that express what’s going on in the “real” world.

However,it might be too much for several applications. Whenever you have a “data” bound application,you’ll probably end up hurting yourself if you try to apply all the principles advocated by Eric in his book. In theses cases, what you should do is follow what is now know as “DDD-lite”. But what is “DDD-lite”? Well, you can think of it as subset of good OO techniques which you can reuse in your projects without going all the “DDD way”. I’ve found this post which talks about several principles that lead to “DDD-lite” and I do agree with the author in most of the topics he presents.

For instance, in my projects (even in those where I don’t go full DDD), I’ll always use concepts like repositories, factories and services. These concepts aren’t enough for saying that you’re using DDD but they sure are reusable across different projects and will improve the final product. So, is DDD for you? The truth is that you’re the only one that can answer this question, but don’t forget that the subset of principles now know as “DDD-lite” can (and should!) be applied to all good OO projects.