TheCodedWorld

Today I wrote some tests with the goal to verify thread safety on a part of production code. Using TDD I wrote a test that started two new threads that both updated the same object, and while they were running I verified the object's data. By putting this in a loop I was able to get a unit test that failed on each run. By adding locks at the correct places I got the test to pass. But looking at the time it took to run the test I noticed that it was quite slow. I knew that the updates to the object's data were fast and started wondering if it was the start and join of the threads that were slowing it down. So, instead of using new Thread(task) I switched to using Task.Run(task) and task.Wait() instead of thread.Join() . The main difference here being task adding a job to a pool of worker threads while new Thread creates a completely new thread that is stopped and disposed after it has run to completion. By doing this small change the test time decreased by 25% (from 80...

For reasons at work I am currently looking into how storing and retrieving data from databases works. Was introduced to an abbrivation that I didn't know of earlier, ACID. ACID is a combination of Atomicity, Consistency, Isolation, and Durability. Atomicity - requires each transaction to be "all or nothing". A transaction may consist of several writes to the database, however, if any of these fail, or is interrupted, the entire transaction must be invalidated in order to have the database in a valid state. Consistency - requires that any transaction will bring the database from one valid state to another. No transactions may currupt the database. Isolation - ensures that concurrent transactions results in a system state that would be obtained if they were executed sequentially . Read that sentence again, it is a tricky one. Be able to perform concurrent transactions in a way that the result is like they have been done sequentially... Durability - ensures that a tra...

The observer pattern is a behavioral pattern that lets several objects, observers, subscribe to state changes at another object, the Subject. As with the Iterator, the .NET framework contains interfaces that are recommended when implementing the design pattern. These are named IObservable and IObserver. The subject should implement the IObservable interface while the observers implement IObserver. Of course, you do not absolutely need to use these interfaces in order to implement the observer pattern but it is good to know that they exist.

The iterator design pattern is an integrated part in many languages and frameworks. In C# you can implement the IEnumerable interface (defining the GetEnumerator method) to make a class iterable. Using the yield keyword makes the method return an iterator. This is so simple in the .NET framework that I did not bother to create a UML diagram this time. Check the code in my GitHub repository  for an example on how to implement IEnumerable.

No software design patterns overview can be complete without describing the Factory pattern. I would say this is one of the most commonly used patterns. Let's get right to the UML diagram. As can be seen an interface, Creator, is defined for creating a Product, but it is the ConcreteCreator that decides which subclass of Product to instantiate. From the client you instantiate the ConcreteCreator and use that to create the products. It is the resonsibility of the ConcreteCreator to see to it that the product is created correctly. This adds a nice level of abstraction since any changes to how the ConcreteProduct is created only needs to be reflected in the ConcreteCreator. The users of the product does not need to change their implementation.

Ok, time for a structural pattern. I really like the Decorator pattern idea. Basically you create an abstract base class, Component. This you subclass to create concrete components, AND, to create Decorators. The decorators add functionality to the concrete components, and since they all subclass the abstract components you can add several decorators, add just the functionality you need. As with the previous patterns I have added example code in my  repository on GitHub .

The Builder Pattern is another creational pattern. It is used for creating different setups of complex aggregated objects. This sounds a lot more complex than what it really is. One easy to understand parable I like is when you go to a fast food restaurant and order a hamburger meal. In order to create the meal, different parts need to be combined. There might be 5-10 different burgers, fries or salad, different soft drinks etc. Ok, so create (build) a meal, start off by creating a new HamburgerMealBuilder, then using that you define the type of burger, fries or salad, Coke or Fanta, and so on until you have the complete meal. There you have it, a perfect use of the builder pattern. To understand the diagram better, take a look in my repository on  github . And by the way, do not use the C# code from Wikipedia, it is incorrect (the [NotNull] attribute does not exist any more, and far worse, the CarBuilder does not Build new cars, it only hands of references to the same sing...