Language-integrated design patterns

I've noticed that getting started with design patterns is pretty difficult for beginners. Understanding the design patterns structure requires a lot of time. Applying the design patterns to your practice requires a lot of time too. Agree, you can't see the differences between various types of the design patterns for the first time if you're not familiar to them. This problem is partially solved, if your classes have the suitable names. Also you can break the design patterned class structure you implement, if you're missing some rules writing your code by chance or you're not so experienced in the design patterns. The compilers can protect you and help you to implement the interfaces - if you're not implementing interface, you can't compile your application. It's a good and safe approach. And if the compilers could protect you when you implement design patterns classes too? Look, a lot of programming languages s开发者_JAVA技巧upports "foreach" statement. And if the programming languages could provide support for the factories, bridges, proxies, mementos, etc? If it could be true, you could use something like the following to apply abstract and concrete factory pattern (I prefer C# as the base language for the pseudocode; it's assumed that the contextual keywords are used):

public abstract factory class AF {
    public product AP1 GetProduct1();
    public product AP2 GetProduct2();
};

public concrete factory class CF1 : AF {
    public product CP1 GetProduct1() { ... }
    public product CP2 GetProduct2() { ... }
};

It think it could help you to understand the new sources and keep the application source code structure integrity. What do you think about this?

If I understand what you're saying, you think that new language features ought to overcome the need for the boilerplate code usually associated with implementing design patterns.

This is already happening, it is nothing new.

Take the singleton, for example, one of the most well known patterns. Everyone knows how to implement it: you declare the constructor private, you keep a single global instance of the object as a static property, and add a public method to retrieve it.

It's quite a few lines of code for what is conceptually very simple.

In Scala, you don't need any boilerplate to create a singleton. To complement the class keyword, Scala has an object keyword, which declares a singleton object:

object MainApp {
  def main(args: Array[String]) {
    println("Hello, world!")
  }
}

At runtime there will be one single, global instance of MainApp. There is no need to instantiate it using new; in fact, you can't use new MainApp at all.

There is an argument that the existence of a design pattern in a language demonstrates a weakness in the design of the language itself, and that the next generation of languages should learn from the design patterns that were common in the previous generation.

For example, see Peter Norvigs famous presentation about Design Patterns being invisible in Dynamic languages.

In fact, it's easy to come up with examples of this process already happening - as you say, foreach loops are arguably embedded iterators, Ruby has a Singleton mixin to inherit from, any language with multimethods doesn't need a Visitor pattern. Groovy has built-in Builders.

Your specific example of a factory sounds a bit like Noops integration of Dependency Injection into the language spec.

Of course there's only so far a type-checker can go in assuring correctness of code (at the moment). And embedding design patterns into the language isn't going to obviate the need for familiarity with the core concepts, or to think hard about the application to the problem at hand.

Your example is interesting, you suggest adding several keywords and rules to the language that (and I'm not that familiar with C#) add no clear benefit. What would the "factory" keyword tell the type checker (or another programmer) that isn't clear from declaring "AF" as the equivalent of a Java interface, and having "product" as the return type for its methods?

I think you are on to something. But where you miss the point (in my opinion) is that you're trying to specify a design pattern, which, as MHarris said, they tend to become deprecated or obsolete as time passes, making the language dependent of them is not such a good idea.

What I think is that, there could be a 'composite' language, where you have two artifacts: the design specification language (coupled to the implementation language, don't think UML) and the implementation. So taking your example, it could be done like this:

Design specification:

single public Factory
    methods:
        T Get[T]

Notice that if done like this, because the design specification is meant to be abstract (no need to specify low level details right there and then), it can have constructs that facilitate writing specifications. Know that in the specification you don't need to say if a method is public or private, design specifications (not included algorithm pseudocode) only cares about publicly visible behavior, not private implementation details.

Implementation:

public class ConcreteFactory : Factory {
    public Product1 GetProduct1() { ... }
    public Product2 GetProduct2() { ... }
};

Here two approaches could be used:

1. The compiler could take the design as an artifact, and then check if the implementation code is congruent with it.

2. The compiler or runtime could provide part of the implementation that can be automatically generated (like the singleton implementation), and the code itself could assume its a singleton and not need to re-specify, for example:

   class ConcreteFactory : Factory {

     Product1 GetProduct1 { new ConcreteProduct1 }  
   
     Product2 GetProduct2 { new ConcreteProduct2 }  
   

   }

Notice that the implementation can overlook higher-level stuff like the visibility of the class and visibility of the methods, because this is already specified at the design level (DRY). If you ask me, this type of language would have to come with a specialized IDE too, so as to provide context information about the design for a type. As Jeff Atwood has commented, any new language should come with its specialized IDE.