Architecture and design patterns

Jonathan Einav

Lecture Objectives
Open a window to the architecture and design patterns world, explain why are they needed and where did they came from, and give some examples and real world tastes of chosen DP and architectures not a programming language oriented lecture, we will mainly discuss the paradigms and uses with examples in various programming languages.

Programming paradigms Evolution

Block Programming Procedural programming Object Oriented Component Oriented SOA (?)

What are design patterns?

The Beginning - Gang of four (Gama et al 1995) What's the difference between an architecture and a Design patterns? Patterns sub types:

Creational Structural Behavioral

Observer design patterns

Behavioral Pattern one-to-many dependency model, so that when one object changes state, all its dependents are notified and updated automatically without coupling the notifying object to the objects that are notified. Example: Button expose a clicked event that encapsulate click state, thus publish himself as an observable. Clients that are interested in this event register to it, thus becomes observers. Observer and observable are bonded in a contract and can be completely loosely coupled from one another.

Singleton design pattern

Creational pattern ensure that a class has only one instance, and to provide a global point of access to it Example: Class SomeClass { static SomeClass singleTonInstance = null; static SomeClass GetInstance() { if(singleTonInstance == null) singleTonInstance = new SomeClass() return singleTonInstance; } }

Factory design patterns (abstract\method\Lightweight)

Creational pattern Can be given to client (abstract), pass construction parameters or read creation types from configuration or system environment Can use object pool (Lightweight)

Factory design pattern - example

abstract class GUIFactory { public static GUIFactory getFactory() { int sys = readFromConfigFile("OS_TYPE"); return sys == 0 ? new WinFactory() : new OSXFactory(); } public abstract Button createButton(); } class WinFactory:GUIFactory { public override Button createButton() { return new WinButton(); } } class MacFactory:GUIFactory { public override Button createButton(){ return new MacButton(); } } abstract class Button { public string caption; public abstract void paint(); }

Factory design pattern - example

class WinButton:Button { public override void paint() { // paint a button with Win API} } class MacButton:Button { public override void paint() { // paint a button Mac style } } class Application { static void Main(string[] args) { GUIFactory aFactory = GUIFactory.getFactory(); Button aButton = aFactory.createButton(); aButton.caption = "Play"; aButton.paint(); } }

Faade design pattern

Structural Pattern Provide a unified interface to a set of interfaces in a subsystem without damaging the genric form of the sub system.

Decorator design pattern

Structural Pattern Avoid excessive sub-classing and gain run time flexibility Example: Java.IO package
BufferedReader br = new BufferedReader( new InputStreamReader( new FileInputStream(inFile)));

All derives from abstract io.Reader

Strategy design pattern

Behavioral Pattern defines a family of interchangeable encapsulated algorithms that receives the same input type and provides the same output type in different manners that can be determined in run-time. static void Main( { SortedList studentRecords = new SortedList(); studentRecords.Add("Samual"); studentRecords.Add("Jimmy"); studentRecords.Add("Sandra"); studentRecords.SetSortStrategy(new QuickSort()); studentRecords.Sort(); studentRecords.SetSortStrategy(new ShellSort()); studentRecords.Sort(); }

Strategy design pattern - example

abstract class SortStrategy { public abstract void Sort(ArrayList list) } class QuickSort : SortStrategy { public override void Sort(ArrayList list) { list.Sort(); // Default is Quicksort } } class ShellSort : SortStrategy { public override void Sort(ArrayList list) { //list.ShellSort(); not-implemented } }

Strategy design pattern - example

class SortedList { private ArrayList list = new ArrayList(); private SortStrategy sortstrategy; public void SetSortStrategy(SortStrategy sortstrategy) { this.sortstrategy = sortstrategy; } public void Add(string name) { list.Add(name); } public void Sort() { sortstrategy.Sort(list); } }

Consumer/Producer
Concurrency Pattern This design pattern coordinates the concurrent production and consumption of information among producer and consumer objects that are working on different threads. This pattern is used with some type of semaphore

Consumer/Producer - example
static AutoResetEvent eventProducerDone = new AutoResetEvent(false); static AutoResetEvent eventConsumerDone = new AutoResetEvent(false); static int currentNum = 0; static void produce(object stateInfo) { eventProducerDone.Set(); while (true) { //wait for the consumer eventConsumerDone.WaitOne(); currentNum++; eventProducerDone.Set(); } }

Consumer/Producer - example
static void Main(string[] args) { ThreadPool.QueueUserWorkItem(new WaitCallback(produce)); for (int i = 0; i < 20; i++) { eventProducerDone.WaitOne(); System.Diagnostics.Debug.WriteLine(currentNum); eventConsumerDone.Set(); } }

Model View Controller

The Model-View-Controller (MVC) pattern separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes The controller changes the model The View Listens to Model Changed events and update itself Recursive MVC

N tier Architecture
The n tier architecture is based on the concept of separating a system to different layers (usually 3) Each layer interacts with only the layer directly below, and has specific function that it is responsible for. Classic for IT systems

N tier Architecture
3 Tier architecture:

Presentation Layer Presentation Layer is the layer responsible for displaying user interface. Business Tier Business Tier is the layer responsible for accessing the data tier to retrieve, modify and delete data to and from the data tier and send the results to the presentation tier. This layer is also responsible for processing the data retrieved and sent to the presentation layer. BLL and DAL Often this layer is divided into two sub layers: the Business Logic Layer (BLL), and the Data Access Layers (DAL). Business Logic Layers are above Data Access Layers, meaning BLL uses DAL classes and objects. DAL is responsible for accessing data and forwarding it to BLL. Data Tier Data tier is the database or the source of the data itself.

Common mistakes tightly coupling layers in technology and writing business logic in presentation tier

Hexagon Architecture
Allow an application to equally be driven by users, programs, automated test or batch scripts.

SOA
SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer in SOA, services are the mechanism by which needs and capabilities are brought together.

SOA - Principles
Visibility the ability for a service consumer to see a service provider (Awareness, willingness and Reachability) Interaction - the activity of using a capability. (usually message exchange by contracts, constraints and policies, for example Web Service Description Language) Effect the result of an interaction

SOA - example

Component Manager and EXE Runner paradigm

Why should the GUI client have the EXE main thread? Why shouldnt we have a visual and easy to use interface for configuring and\or adding\removing physical components? Solution:

Component Manager drag and drop assemblies and connect functionality using events and delegate signatures, eventually compile an XML file that will represent all assemblies and connections EXE Runner Run the XML file with the EXE main thread loading the application assemblies and connecting relations in run-time

Components Vs namespaces Vs Classes

Classes separation OOP concepts Namespace separation -Logical domain considerations (functional) Assembly separation - Physical domain considerations (maintenance, usability)

Thin, rich and smart clients

Thin client web Rich client full blown application Smart client components on demand in click-once deployment and update approach

Code and configuration separation

Hard Code AS LITTLE AS POSSIBLE Pros Extensibility, less bugs (less code changes), different suite support under the same code base with less administrative overhead (documentation, deployment, QA etc.) Cons performance, coding overhead EL 2.0 Configuration application block Near future - XAML of Avalon

About me
B.A with honors in CS. Assumed different industrial positions such as R&D Manager, chief Architect and Projects manager in Various industry domains such as the Medical , Education and the Security domains. Consultant to various companies in software management, architecture and MS .NET issues Member of the Microsoft .NET Fight Club.