If you like practicing in identifying code smells, then you can find below a short class called TimerManager.
public class TimerManager
public delegate void TimerCallback(object data);
private static readonly object _sync = new object();
private readonly Dictionary<int, Timer> timers = new Dictionary<int, Timer>();
private readonly Dictionary<int, TimerCallback> callbacks = new Dictionary<int, TimerCallback>();
public void SetTimeout(TimerCallback timerCallback, int snooze)
var timer = new Timer(snooze);
Once upon a time, there was a class called Invoice. Its responsibility was to calculate a final
price being presented to the customer.
Time went on; The autumn passed, the winter fade out and the spring was already at the door and our class started to
Each time a developer found a new set of relevant parameters (that should have been passed to the Invoice class) he added a new
constructor, to support them.
And so it happened, that after...
One of the key aspects of a Software Craftsmanship is constant practice.
Kata (from Martial Arts) is one form of such practice. The notion of a Code Kata was first introduced by Dave Thomas and can be viewed as:
Practice of the same methods, solutions and activities to a perfection.
Practice of the same problem, tackling it each time from a different angle or with a different solution.
Solving a known problem multiple times utilizing the same methods, enhances the understanding of the specific steps; It especially enhances the understanding of unit tests, refactoring steps or "Design" approaches. Moreover, striving to do better...
This week we concluded the Experts Days.
The sessions were effectively organized (by Eyal Vardi from E4D), the audience was amazing and the atmosphere was energizing .
Here are the headlines of my sessions:
I. What's new in .NET 4.0 and VS 2010:
The main focus was to emphasize the most important (in my opinion) upcoming features.
Here they are:
Task Parallel Library, PLINQ and Coordination Data Structures
Reaction (Rx) Framework
Managed Extensibility Framework (MEF)
Dynamic Language Runtime (DLR - and especially F#)
Also, we reviewed a lot of other upcoming features in .NET 4.0 and Visual Studio 2010 (IDE).
For those, willing to have a deeper look, here...
When designing an application, one can easily confuse DTOs, Business Entities and Persistency.
Using the following simple examples I will demonstrate design considerations and thoughts that will dispel some mists.
Consider that you want to represent an audio or a movie located on a web page.
When you visualize such an object, the first thing you probably see is the data that characterizes it.
No surprise here. You applied, without knowing it, an "Information Expert" pattern when you visualized the object's knowledge responsibilities.
So, what are they? Clearly such an object will have:
Uri - object's URL
Content - object's content
DateCreated - object's creation date
Well, there is none...
Simply to put, there is no silver bullet.
Yet, while designing an application, there are several well known extremes:
"Heavy weighted design" - Such a design will use almost each and every pattern described in the bible of "Design Patterns" - by the Gang of Four.
However, squeezing as much as possible patterns into your design has a bad smell.
Here is what
Erich Gamma has to say on the matter:
This is a third post in the series of posts about “Separate Domain from Presentation” Refactoring. Previous Posts: Separate Domain from Presentation – part I Separate Domain from Presentation – part II Last time we explained how to refactor towards MVP – Supervising Controller pattern. We left our project in the following state: In this post I will complete the required refactoring steps and will suggest more steps to even deepen the separation of UI and BL concerns. Refactoring Steps: ...
This is a second post in the series of posts about “Separate Domain from Presentation” Refactoring. Previous Posts: Separate Domain from Presentation – part I Last time we discussed the ways to disconnect the Presentation (FrmMain) from the Domain Object (CoursesDS) in the IRefactor.CoursesView project. As a consequence, instead of the bloated all-in-one initial project we ended with the following: IRefactor.CoursesView – represents the View (CoursesView) without the domain object. IRefactor.Common – represents the domain object (CoursesDS) without the UI elements. It’s time...