Monday, January 29, 2018

State Design Pattern combined with Console.ReadLine

Some times we want console application, when one screen changes other depend on user console read line input

Example:

Start:

user select P:
user select M:
User select P:
User Select F:

It is very easy do with using State design pattern.

Solution:

Classes:

Program.cs:

class Program
{
static void Main(string[] args)
{
IState state = new MainMenuState();
Context context = new Context(state);

while (true)
{
context.Request();
}
}
}

Context.cs:

public sealed class Context
{
public Context(IState state)
{
State = state;
}

public IState State { get; set; }

public void Request()
{
State.PrintOptions();
string userChoise = Console.ReadLine();
State.UpdateState(this, userChoise);
}
}

IState.cs:

public interface IState
    {
        void PrintOptions();
        void UpdateState(Context context, string userChoise);
    }
}

State classes:

public sealed class MainMenuState : IState
{
public void PrintOptions()
{
Console.Clear();
Console.WriteLine("Hello. Is Main menu");
Console.WriteLine("P - print hello");
}

public void UpdateState(Context context, string userChoise)
{
switch (userChoise)
{
case "P":
context.State = new PrintHelloState();
break;
}
}
}

public class PrintHelloState : IState
{
public void PrintOptions()
{
Console.Clear();
Console.WriteLine("Hello my little friend!");
Console.WriteLine("M - main menu");
Console.WriteLine("F - finish menu");
}

public void UpdateState(Context context, string userChoise)
{
switch (userChoise)
{
case "M":
context.State = new MainMenuState();
break;
case "F":
context.State = new FinishMenuState();
break;
}
}
}

public sealed class FinishMenuState : IState
{
public void PrintOptions()
{
Console.Clear();
Console.WriteLine("Bye Bye");
Thread.Sleep(1000);
Console.WriteLine("See you");
Thread.Sleep(1000);
Environment.Exit(0);
}

public void UpdateState(Context context, string userChoise)
{

}
}

Also, some functionality can be added in one of overloaded function, or added new one.

 

Wednesday, January 24, 2018

Multi threading initially supporting in Domain Object and Business Logic

In previous post i was make superficial review on DO and BL

DO should not, generally, support Multi threading initially.

BL should support initialy Multi threading in next case: static methods or static members

In case of static member always should support multi threading. It is shared entity by a-priory
In case of static method, if this method uses static member (which was described earlier) so it also should support multi threading.  If static method not uses any static members, it is should not support multi threading initially

Initially - i mean without considering customer. If customer wish DO supports multi threading -  this is the customers's concern.

Partitioning of application into main modules

Application should be partitioning to main modules.

For example, i will consider train system.
It is consists from: Train, routes, stations, search train, add route, rich WPF UI, console UI, user click some button to get stations etc.

DO - domain object. It is anemic entity, consists only Train, Route, Station
BL - business logic. It is operations on DO: search route, serialization/deserialization of DO objects etc.
UI - is how all this looks like on screen. Can be made by WPF, WinForms, Console etc.

How knows who?

DO do not know anyone.
BL knows DO only.
UI knows both BL and DO.

Its very superficial review, but it is very important to understand this concept