Group items tagged

Here's a short overview of four major user interface patterns in their original form, put together and illustrated. A bit of information is added to patterns (with notes to highlight these additions) to show a slightly different viewpoint and different ideas.

"The singleton pattern is one of the best-known patterns in software engineering. Essentially, a singleton is a class which only allows a single instance of itself to be created, and usually gives simple access to that instance."

"Service Locator is a well-known pattern, and since it was described by Martin Fowler, it must be good, right? No, it's actually an anti-pattern and should be avoided."

"I'm getting really tired of all blog posts that states that service locator is an anti pattern. It's not."

"This is going to be the first post in a new series that I'm doing on design patterns. [..] So, my idea here is to relate the design patterns in the context of a story rather than a stuffy-sounding taxonomy. Why do people do this? What problem does it solve? Why is my code potentially worse if I don't do this?"

"Recommendation: Go for the lightweight Factory Delegate approach. As with all patterns, use with caution and watch for overuse & abuse. In particular, if you need to manage state between multiple delegate, fall back to the overriding approach, because you can keep the state in the subclass."

"When you really boil it down to its implementation, FizzBuzz is something of an irritating program. I'm not sure how much the author of the problem really thought about FizzBuzz, but it turns out it's difficult to express well with the tools available to most imperative programming languages and easy to express using functional patterns available in Haskell and ML."

"Interfaces are wonderful for a language like C#. Interfaces give us everything we need to work with an object in a strongly-typed manner, but place the least number of constraints on the object implementing the interface. Interfaces make the C# compiler happy without forcing us to pay an inheritance tax for working with a class hierarchy. We'll define an interface that describes exactly how we want to fetch customers and how we want the customers packaged for us to consume."

"This is the first of a two-part series that will tell the long story of the C# memory model. The first part explains the guarantees the C# memory model makes and shows the code patterns that motivate the guarantees; the second part will detail how the guarantees are achieved on different hardware architectures in the Microsoft .NET Framework 4.5."