So is this the author is talking about?? But again what I am talking about are not language extensions .. rather just API additions. Mohn mentioned language extensions but somehow I could not relate those to Design Patterns... Any ideas??
What I wrote in my previous post doesn't technically count as design patterns in the way it's used today. You're right. I suppose I was lumping the "hacks" or workarounds together with design patterns. Basically, something that isn't enforced by the compiler or the language but is agreed upon by the community.
As far as design patterns go, they are becoming language features. The Singleton pattern which you mentioned is one example. In the next version of C# (and VB.NET too I think), you can declare a "static" class. This makes it so that you can't create an instance of it. The constructor is automatically private. Another good example in the is the Observer pattern. This is where you want to "observe" another object and be notified when an event occurs (correct me if I'm wrong, or confused it with another pattern). In .NET the concept of an Event is built into the system. So you can actually create events, have other objects delegate their own methods to those events so that they are invoked when that event occurs.
So this is different to what you said about design patterns being built into the API's instead of the language itself.
I find that Design Patterns are discussed more on the Java side. I haven't found much material with regards to .NET. Dunno why.
No comments:
Post a Comment