Design Patterns for Multi-Threaded Applications

(4 Days - 5,495 NIS)

1-04/9/08

Register Here     Syllabus for Printing       View chapter one

Course Description

The course reveals the motivation, complexity and implementation of some design patterns, idioms and principles which are essential in real-life object-oriented design. Especially, this course is…

·       Requirement driven. The patterns are presented as solutions to real world problems.

·       Concentrated. The course focuses on a few pattern languages, rather than spreading over a catalogue of numerous, unrelated patterns.

·       Useful. The learnt material may be applied in the obvious way to almost any real-world application, during both design and maintenance. No further training or tutoring is required to apply the learnt material to begin with.

·       Practical. The form and content of the course is based upon lessons learnt in many years of teaching and applying design patterns and object-oriented design.

·       Productive. The learnt material is exercised thoroughly in C+ + under Windows CE 5.0.

 Lecturer
Avner Ben

Participants

Programmers, software designers, project managers.

Course Objectives

Participants will:

·         Become better C++ programmers.

·         Become proficient object oriented programmers.

·        Know how to design object-oriented multithreaded application architecture simply and efficiently.

·        Master many design patterns needed in everyday use.

·        Acquire the functional paradigm of software design.

·        Exercise under a multi-threaded operating system (Windows CE 5.0)

Prerequisites

Participants should have…

·        Basic knowledge of object-oriented programming

·        Programming experience in C++.

Course contents
Part 1. The Multi-threaded Application Framework

A pattern language for the typical "multi-threaded process", conforming to the current state of the art.

1.       Encapsulating the event loop:

·         The “Active Object” idiom: to send messages to an object asynchronously.

·         The “Multi-threaded Application Framework” architecture: to launch and monitor active objects.

·         The "Event Loop" idiom, the “Reactor” pattern: to wait for predefined input and handle it when it arrives.

·         The "Visitor" pattern: to let any known Handle forward the Application to handle it.

·         The "Open/Closed" principle: to control the Handler population, regardless of the Application.

·         The “Template method” pattern: to open event cycle stages, still closing the event cycle procedure.

·         The “Strategy” pattern: to configure event cycle handling regardless of Active Object type.

2.       Configuring the application:

·         The "Registration" idiom, Configurator: to control the Active Object population, regardless of the Application.

                                                                 i.            The "Startup Registration" variant: to open the Active Object population to unlimited extension.

·         The "Cyclical Dependency" principle: to prevent the Active Objects from knowing the Application.

·         The "Singleton" pattern: to access the one and only Configurator that is always there.

                                                                 i.      The "safe Singleton” variant: to ensure lossless registration.

                                                               ii.      The "Statically-allocated Singleton” variant: to create the Configurator on time, using static memory.

                                                              iii.      The "Disposable Singleton” variant: to ensure that Configurator-allocated resources are finally returned.

3.       Structured message passing:

·         The “Remote Proxy” pattern: to address an Active Object in the object-oriented notation.

·         The "Dynamic pluggable Factory" pattern: to control the Message catalogue regardless of the application.

                                                                 i.            The "Factory Method" pattern: to register Message Creator without allocating a message.

·         The "Base Template" idiom: to define Message Creators without writing class code; to define Message types without writing class code.

                                                                 i.            The "Serialization" idiom: to separate Message block from Message data.

·         The "Command" pattern: to register handlers for any message an Active Object can handle.

                                                                 i.            The "Delegate" idiom: to register handling method, regardless of Handler type (the C++ implementation).

Part 2: A Typical Bit Application

A pattern language for the typical "BIT" (Built-In Test). Given a dictionary of test procedures and given a rule tree, produce an array of test results.

4.       A complicated object structure

·         The "composite" pattern: to traverse the rule tree regardless of node type.

·        The “Recursive Object Structure” idiom: to combine containment and inheritance to a hierarchical structure of arbitrary depth.

·         The “Hierarchical Visitor” pattern: to traverse the rule tree by responding to events.

·         The "observer" pattern: To let real-world changes invalidate rules.

5.       Parsing

·         The “State” pattern: to parse input according to predefined states.

·         The “Builder” pattern: to build the rule tree from outside.