November 30, 2010 Design Patterns No comments
November 30, 2010 Design Patterns No comments
Many people like watching box fights. But besides of this, someone have to pay for all of this, and most of the money come from people who put some money on boxers and then lose it. Or… maybe I’m wrong, but for this example, let it be so. Imagine that we have box fight tonight and there are two persons interested in game, so they OBSERVE fight and UPDATE their rates. One of them likes risks, so he always put money on boxer who has less chance to win, and other is very conservative and likes small bird in hand instead of big in the sky.
Observer is design pattern, that allows automatically update many observers if there was change in state of some subject object.
So, each gambler (Player, Observer) likes to adjust his rates, that is why he has Update() method.
public interface IObserver
{
void Update(ISubject subject);
}
public class RiskyPlayer : IObserver
{
public string BoxerToPutMoneyOn { get; set; }
public void Update(ISubject subject)
{
var boxFight = (BoxFight)subject;
BoxerToPutMoneyOn = (boxFight.BoxerAScore > boxFight.BoxerBScore) ? "I put on boxer B, if he win I get more!" : "I put on boxer A, if he win I get more!";
Console.WriteLine("RISKYPLAYER:{0}", BoxerToPutMoneyOn);
}
}
public class ConservativePlayer : IObserver
{
public string BoxerToPutMoneyOn { get; set; }
public void Update(ISubject subject)
{
var boxFight = (BoxFight)subject;
BoxerToPutMoneyOn = (boxFight.BoxerAScore < boxFight.BoxerBScore) ? "I put on boxer B, better be safe!" : "I put on boxer A, better be safe!";
Console.WriteLine("CONSERVATIVEPLAYER:{0}", BoxerToPutMoneyOn);
}
}
Here below we have subject which is observed by players:
public interface ISubject
{
void AttachObserver(IObserver observer);
void DetachObserver(IObserver observer);
void Notify();
}
public class BoxFight : ISubject
{
public List<IObserver> Observers { get; private set; }
public int RoundNumber { get; private set; }
private Random Random = new Random();
public int BoxerAScore { get; set; }
public int BoxerBScore { get; set; }
public BoxFight()
{
Observers = new List<IObserver>();
}
public void AttachObserver(IObserver observer)
{
Observers.Add(observer);
}
public void DetachObserver(IObserver observer)
{
Observers.Remove(observer);
}
public void NextRound()
{
RoundNumber++;
BoxerAScore += Random.Next(0, 5);
BoxerBScore += Random.Next(0, 5);
Notify();
}
public void Notify()
{
foreach (var observer in Observers)
{
observer.Update(this);
}
}
}
Usage, or how we build one-to-many relationship by attaching observer-s:
var boxFight = new BoxFight();
var riskyPlayer = new RiskyPlayer();
var conservativePlayer = new ConservativePlayer();
boxFight.AttachObserver(riskyPlayer);
boxFight.AttachObserver(conservativePlayer);
boxFight.NextRound();
boxFight.NextRound();
boxFight.NextRound();
boxFight.NextRound();
Output:
RISKYPLAYER:I put on boxer A, if he win I get more! CONSERVATIVEPLAYER:I put on boxer B, better be safe! RISKYPLAYER:I put on boxer B, if he win I get more! CONSERVATIVEPLAYER:I put on boxer A, better be safe! RISKYPLAYER:I put on boxer B, if he win I get more! CONSERVATIVEPLAYER:I put on boxer A, better be safe! RISKYPLAYER:I put on boxer B, if he win I get more! CONSERVATIVEPLAYER:I put on boxer A, better be safe!
Been very short explanation. Just take closer look on interfaces in examples, this should be enough to understand everything.
November 23, 2010 Design Patterns No comments
Did you ever think why so many things around us have tree-similar structure? Top management of your company can delegate some work to middle management, and it can delegate it to your direct manager, who will ask you and your colleagues do something. In one of your tasks you had to gather data for some customer into xml. XML has also tree-similar structure. Why? Because it is the best way to serialize data, that can have data, that can… You got that! Now imagine that you want to gather data for some document part by part.
Composite is design pattern that provides us tree-similar structural representing of classes, this allows us work uniformly with parents and Childs.
So interface that defines common requirements for parents and kids:
public interface IDocumentComponent
{
string GatherData();
void AddComponent(IDocumentComponent documentComponent);
}And here we see some leaf component implementation. It is Customer Component, which gathers some data about customer basing on id provided to the class.
public class CustomerDocumentComponent : IDocumentComponent
{
private int CustomerIdToGatherData { get; set; }
public CustomerDocumentComponent(int customerIdToGatherData)
{
CustomerIdToGatherData = customerIdToGatherData;
}
public string GatherData()
{
string customerData;
switch (CustomerIdToGatherData)
{
case 41:
customerData = "Andriy Buday";
break;
default:
customerData = "Someone else";
break;
}
return string.Format("<Customer>{0}</Customer>", customerData);
}
public void AddComponent(IDocumentComponent documentComponent)
{
Console.WriteLine("Cannot add to leaf...");
}
}And not-leaf implementation of the component below. Please take into account that it simply loops through Childs and executes GatherData method.
public class DocumentComponent : IDocumentComponent
{
public string Name { get; private set; }
public List<IDocumentComponent> DocumentComponents { get; private set; }
public DocumentComponent(string name)
{
Name = name;
DocumentComponents = new List<IDocumentComponent>();
}
public string GatherData()
{
var stringBuilder = new StringBuilder();
stringBuilder.AppendLine(string.Format("<{0}>", Name));
foreach (var documentComponent in DocumentComponents)
{
documentComponent.GatherData();
stringBuilder.AppendLine(documentComponent.GatherData());
}
stringBuilder.AppendLine(string.Format("</{0}>", Name));
return stringBuilder.ToString();
}
public void AddComponent(IDocumentComponent documentComponent)
{
DocumentComponents.Add(documentComponent);
}
}Gluing parts to be some kind of document:
var document = new DocumentComponent("ComposableDocument");
var headerDocumentSection = new HeaderDocumentComponent();
var body = new DocumentComponent("Body");
document.AddComponent(headerDocumentSection);
document.AddComponent(body);
var customerDocumentSection = new CustomerDocumentComponent(41);
var orders = new DocumentComponent("Orders");
var order0 = new OrderDocumentComponent(0);
var order1 = new OrderDocumentComponent(1);
orders.AddComponent(order0);
orders.AddComponent(order1);
body.AddComponent(customerDocumentSection);
body.AddComponent(orders);
string gatheredData = document.GatherData();
Console.WriteLine(gatheredData);Output is somewhat similar to XML. At least I tried to keep it similar.
<ComposableDocument>
<Header><MessageTime>8:47:23</MessageTime></Header><Body>
<Customer>Andriy Buday</Customer>
<Orders>
<Order>Kindle;Book1;Book2</Order>
<Order>Phone;Cable;Headset</Order>
</Orders>
</Body>
</ComposableDocument>
Also GoF guys suggest having Remove(Component) and GetChild(int) methods in your Component, so you might want to add them. Just don’t limit yourself with any kind of explanations. You might have some unique need.
November 15, 2010 Design Patterns 4 comments
You have a boss, who doesn’t care who will be doing some work or how it will be done, he just want it to be started and completed at some point of time, say after customer signed contract. Since you are at high position you were asked to form team A that will be working at some project X, you also got list of high-level requirements from your boss. You should be ready to start all work at the moment your customer signs contract.
So you are Command – you encapsulate receiver team A and parameters to start work (project and requirements). Team and requirements are given to you by your boss – Client.
You are able to delegate all work to team A and provide requirements at the moment customer triggers process. Your customer is Invoker, they have contact to you, so can use you as they want.
Command – is design pattern that allows us encapsulate request, tune it with parameters as needed and then execute at one point of time, without knowing how actually executes work.
Client code
Here is how story looks from code perspective. Taking a look at client code (boss):
var customer = new Customer();
// for some reason boss always knows that company has money
// only for team Z
var team = new Team("Z");
// he also managed to get high-level list of requirements for you
var requirements = new List<Requirement>() { new Requirement("Cool web site"), new Requirement("Ability to book beer on site") };
// you should be ready to be invoked by Customer
ICommand commandX = new YouAsProjectManagerCommand(team, requirements);
customer.AddCommand(commandX);
// there is also here developer who can code at light speed
var heroDeveloper = new HeroDeveloper();
// boss decided to give him project A
ICommand commandA = new HeroDeveloperCommand(heroDeveloper, "A");
customer.AddCommand(commandA);
// when customer signs contract with boss
// your team and hero developer start executing their job
customer.SignContractWithBoss();
Command
Now lets take a look on two concrete commands:
public interface ICommand
{
void Execute();
}
public class YouAsProjectManagerCommand : ICommand
{
public YouAsProjectManagerCommand(Team team, List<Requirement> requirements)
{
Team = team;
Requirements = requirements;
}
public void Execute()
{
// implementation delegates work to concrete receiver
Team.CompleteProject(Requirements);
}
protected Team Team { get; set; }
protected List<Requirement> Requirements { get; set; }
}
public class HeroDeveloperCommand : ICommand
{
public HeroDeveloperCommand(HeroDeveloper heroDeveloper, string projectName)
{
HeroDeveloper = heroDeveloper;
ProjectName = projectName;
}
protected HeroDeveloper HeroDeveloper { get; set; }
public string ProjectName { get; set; }
public void Execute()
{
// implementation delegates work to concrete receiver
HeroDeveloper.DoAllHardWork(ProjectName);
}
}
Receiver
Team and HeroDeveloper are receivers of work that should be done.
Invoker
Customer simply aggregates many commands and without knowing how those commands were built by boss. Customer as true invoker simply triggers work using Execute method:
public class Customer
{
public Customer()
{
Commands = new List<ICommand>();
}
public void AddCommand(ICommand command)
{
Commands.Add(command);
}
protected List<ICommand> Commands { get; set; }
public void SignContractWithBoss()
{
foreach (var command in Commands)
{
command.Execute();
}
}
}
Output
User Story (Cool web site) has been completed
User Story (Ability to book beer on site) has been completed
Hero developer completed project (A) without requirements in manner of couple of hours!
UPDATE: Nov 18, 2010
UML-Diagram
Here below I added diagram showing two commands exactly as in example. Please take into account that for simplicity you can remove one pair HeroDeveloperCommand-HereDeveloper. Also take into consideration that in our example concrete commands are aggregating receivers, but this is not common situation. In most cases receiver is some another system.
November 8, 2010 Design Patterns 2 comments
Imagine that you own huge building company. It builds houses and apartment blocks all around your city. Building are of two types – either built with concrete blocks or with bricks. Since you are boss when you were deciding how to divide work you have decided that all crews will have same operations like BuildFoundation, BuildRoom, BuildRoof. But because houses are of two types you had to always keep two teams (aka. two concrete).
Once it turned out that couple of buildings were of mixed type where you had to build some rooms with concrete blocks and some with bricks. For this reason you had to move whole teams from one part of the city to another. You got many complains from your employees, they suggested moving only that part of team that is specialized in building rooms, so you can easily move small crew of workers and reassign it easily to any team instead of having two separate teams. And that is idea.
BRIDGE
Bridge is design pattern that allows you decouple realization from its abstraction, therefore your realization can be changed separately from abstraction because does not implement it directly.
In other words, our IBuildingCompany might have two concrete realizations like NearSeeBuildingCompany and CityBuildingCompany, each of them does probably something different for their foundation and roof, but at the same time we can easily and quickly reassign WallCreator crew for each of those companies to build either brick or either concrete walls.
Let say we have BuildingCompany as below:
internal interface IBuldingCompany
{
void BuildFoundation();
void BuildRoom();
void BuildRoof();
IWallCreator WallCreator { get; set; }
}
internal class BuldingCompany : IBuldingCompany
{
public void BuildFoundation()
{
Console.WriteLine("Foundation is built.{0}", Environment.NewLine);
}
public void BuildRoom()
{
WallCreator.BuildWallWithDoor();
WallCreator.BuildWall();
WallCreator.BuildWallWithWindow();
WallCreator.BuildWall();
Console.WriteLine("Room finished.{0}", Environment.NewLine);
}
public IWallCreator WallCreator { get; set; }
public void BuildRoof()
{
Console.WriteLine("Roof is done.{0}", Environment.NewLine);
}
}So what is so interested about it? Answer is property WallCreator, which is exactly our bridge to implementation.
Usage code
Let see this in action:
// We have two wall creating crews - concrete blocks one and bricks one
var brickWallCreator = new BrickWallCreator();
var conctreteSlabWallCreator = new ConcreteSlabWallCreator();
var buildingCompany = new BuldingCompany();
buildingCompany.BuildFoundation();
buildingCompany.WallCreator = conctreteSlabWallCreator;
buildingCompany.BuildRoom();
// Company can easily switch to another wall crew to continue building rooms
// with another material
buildingCompany.WallCreator = brickWallCreator;
buildingCompany.BuildRoom();
buildingCompany.BuildRoom();
buildingCompany.BuildRoof();Isn’t it awesome? Output should be intuitive, but since I did not show implementations of BrickWallCreator and ConcreteSlabWallCreator I’m going to list it below:
Foundation is built.
Concrete slab wall with door.
Concrete slab wall.Concrete slab wall with window.
Concrete slab wall.
Room finished.
Brick wall with door.
Brick wall.Brick wall with window.
Brick wall.
Room finished.
Brick wall with door.
Brick wall.Brick wall with window.
Brick wall.
Room finished.
Roof is done.
UML diagram illustrates how this pattern looks like and why it is called bridge.
October 3, 2010 Design Patterns No comments
VISITOR
public interface IVisitor
{
void Visit(OfficeBuilding building);
void Visit(Floor floor);
void Visit(Room room);
}public class ElectricitySystemValidator : IVisitor
{
public void Visit(OfficeBuilding building)
{
var electricityState = (building.ElectricitySystemId > 1000) ? "Good" : "Bad";
Console.WriteLine(string.Format("Main electric shield in building {0} is in {1} state.", building.BuildingName, electricityState));
}
public void Visit(Floor floor)
{
Console.WriteLine(string.Format("Diagnosting electricity on floor {0}.", floor.FloorNumber));
}
public void Visit(Room room)
{
Console.WriteLine(string.Format("Diagnosting electricity in room {0}.", room.RoomNumber));
}
}public class Floor : IElement
{
private readonly IList<Room> _rooms = new List<Room>();
public int FloorNumber { get; private set; }
public IEnumerable<Room> Rooms { get { return _rooms; } }
public Floor(int floorNumber)
{
FloorNumber = floorNumber;
}
public void AddRoom(Room room)
{
_rooms.Add(room);
}
public void Accept(IVisitor visitor)
{
visitor.Visit(this);
foreach (var room in Rooms)
{
room.Accept(visitor);
}
}
} Source code elements in diagram
Usage
var floor1 = new Floor(1);
floor1.AddRoom(new Room(100));
floor1.AddRoom(new Room(101));
floor1.AddRoom(new Room(102));
var floor2 = new Floor(2);
floor2.AddRoom(new Room(200));
floor2.AddRoom(new Room(201));
floor2.AddRoom(new Room(202));
var myFirmOffice = new OfficeBuilding("[Design Patterns Center]", 25, 990);
myFirmOffice.AddFloor(floor1);
myFirmOffice.AddFloor(floor2);
var electrician = new ElectricitySystemValidator();
myFirmOffice.Accept(electrician);
var plumber = new PlumbingSystemValidator();
myFirmOffice.Accept(plumber);Main electric shield in building [Design Patterns Center] is in Bad state.
Diagnosting electricity on floor 1.
Diagnosting electricity in room 100.
Diagnosting electricity in room 101.
Diagnosting electricity in room 102.
Diagnosting electricity on floor 2.
Diagnosting electricity in room 200.
Diagnosting electricity in room 201.
Diagnosting electricity in room 202.
Plumbing state of building [Design Patterns Center] probably is in Good condition, since builing is New.
Diagnosting plumbing on floor 1.
Diagnosting plumbing on floor 2.
Classic UML diagram
September 26, 2010 C#, Design Patterns, Java, Opinion, Personal, Success 12 comments
Yeah, title sounds not logically, but you will understand in a few why it is still relevant to this blog post.
It was and it is a good idea to…
In one of my blog posts I’ve decided to have all of the GoF Design Patterns written with Java. And idea itself is very good. Having all of the design patterns written by your own with you own examples gives you understanding of the DP that you cannot gain anywhere else plus to that if you have industrial experience of using all of them you can start think that you are guru of DP.
Process of writing my post on one of the Design Patterns looks like this: I read chapter of the GoF book on the particular DP, then I think up my own example if I do not have it already in my mind and after I’m done with some preliminary ideas I search over the internet for interesting articles on it and probably rethink some of the aspects of my example. After all of that I proceed to writing blog post and source code with Java.
Conclusion: Awesome and probably one of the best ways of learning DP is to have your own example of using it and industrial experience.
Design Patterns articles
One of the intents of having DP written in Java was to familiarize with that language. But it turns out that I did not learn much from Java (except of few things). Also few months ago I started keeping up Tuesday’s Design Pattern on the Lviv .NET User Group Page. Since it is .NET specific UG, I used to do following: 1) translate and 2) translate. In first place it is translation from English to Ukrainian and in second from Java to C#. When with item number one I have to apply some logic and rephrasing I cannot say the same about second item. I just copy code-paste code into Visual Studio and change few keywords. So what do I learn regarding of Java in this case?
I will continue learning Java, but I have to consider better way of doing it. I will also continue writing about Design Patterns, but with examples in C#.
Conclusion: Learning another programming language (Java) is really great idea, but be sure that you choose right approach of doing this.
First free e-book
On the road to Lviv I got perfect idea to start my first book. Of course this cannot be comprehensive stunning author’s book, but I have to start with something. In other words some probing book and this could be this “try it” case. I’m almost sure that there are no books about GoF Design Patterns in Ukrainian. (I suppose that there are in Russian, which can be easily understandable for most Ukrainians…)
How this book will be different?
Why do I need it?
I understand that this book might not be popular at all. But I have to start with something and plus to this it will help me familiarize with the whole process and build my confidence for future.
Also if you have some doubts about my idea I have a question for you: “Have you ever dreamt about your own book? If yes, do you have at least small book written?”
Conclusion: Never be skeptic about starting your first book. It might be a huge step to your success as anything else you are hesitating about but still dreaming about it!
July 25, 2010 Design Patterns 4 comments
Imagine that your application is very complicated and it happened that you use two logging providers – one is Log4J and another is Java Logging. Your co-worker got great idea to have specification of which of the providers to use in configuration file. As you wrap all logging logic behind some ILogger interface, you also want to hide exact logging provider from client code and pass creating logic to some separate class.
For me this design patter is the most familiar and easiest. I’m sure that most of the readers have seen it many times. So the intent of the Factory Method is to hide exact class that should be created basing on some conditions.
In our example classes that should be created are Log4J or JavaLogging, they both implement interface ILogger, that is widely used in your application.
As you already guess it might be that in future you will decide to use another logging provider. As we already described in our scenario we read which logging provider to use from some configuration. For not exposing exact classes we delegate this work to LoggerProviderFactory. Here is usage:
ILogger logger = LoggerProviderFactory.GetLoggingProvider(providerType);
logger.LogToConsole(“Hello Factory Method Design Pattern.”);
}
private LoggerProviderFactory.LoggingProviders getTypeOfLoggingProviderFromConfigFile() {
return LoggerProviderFactory.LoggingProviders.Log4J;
}
What we are getting back from GetLoggingProvider method is interface. Factory Method decides which of the concretes return basing on the input parameter, which in our case is enum.
Here is implementation of Factory Method:
public enum LoggingProviders{
JavaLogging,
Log4J
}
// this is our factory method…
public static ILogger GetLoggingProvider(LoggingProviders logProviders)
{
switch(logProviders){
case JavaLogging:
return new JavaLogging();
case Log4J:
return new Log4J();
default:
return new JavaLogging();
}
}
}
Because my hardcoded configuration logic returns me Log4J and since implementation of LogToConsole of Log4J concrete logger looks like:
I’m getting this as output: Log4J: Hello Factory Method Design Pattern.
Here is my drawing try:
If you liked or disliked this blog post, just let me know.