views:

103

answers:

2

Hi.
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 supports "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?

+5  A: 

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.

Ben James
You've provided a sample for a singleton only, one of the most simple patterns. But anyway, I see that I have just another view for the design patterns use approach. Thanks.
Lyubomyr Shaydariv
Can you do a lazily initialized singleton using that approach in Scala?
MHarris
+1  A: 

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?

MHarris
Thank you for reply and for the presentation. I'll learn it as soon as I have enough free time.The "factory" contextual keyword would to pass "product" methods into the class. So when another class is derived from the class, the compiler can check whether all products have been correctly described. I see it's similar to interface approach, but as far as I understand, interfaces and factory classes are somewhat different things.
Lyubomyr Shaydariv