Abstract Factory and Bridge Design Patterns - Felix John COLIBRI.

• abstract : presentation of Abstract Factory and Bridge. Example in the Lexi Document Editor
  
• key words : Design Patterns, Abstract Factory, Bridge, Gof, Gang Of Four, Lexi
  
• software used : Windows XP, Delphi 6
  
• hardware used : Pentium 1.400Mhz, 256 M memory, 140 G hard disc
  
• scope : Delphi 1 to 8 for Windows, Kylix
  
• level : Delphi developer
  
• plan :
  
  • Introduction
    
  • The Round and Square Control Worlds
    
  • The Abstract Factory Pattern
    
  • The Bridge Design Pattern
    
  • Improvements
    
  • Download the Sources
    

1 - Introduction

However Strategy and Decorator use Iterator, and Factory and Bridge are required as soon as you start drawing, which is right at the beginning, since c_glyph, the base of the whole demonstration, will contain some drawing methods.

It turns out that Factory and Bridge are complex patterns because:

• they involve many participants
  
• they assume that you will be using several windowing libraries (Win32, X-Windows, Presentation Manager). You might develop cross platform code, but I very much doubt that any Design Pattern student will work with a multi-windowing development tool to learn patterns.
  

Therefore we simulated the "multi-windowing" development library, and included it in our Lexi project.

2 - The Round and Square Control Worlds

2.1 - Look and Feel

• the "round" control world, where all shapes (button, label, selection rectangle) have rounded edges
  
• the "square" control world, where rectangle have their usual square edges
  

2.2 - The Control specification

To specify and rectangular buttons, we have many choices:

• use Left, Top, Width and Height (Delphi)
  
• use two opposite corners (X1, Y1, X2, Y2) like Win23 Rectangle
  
• any other 4 parameters could be used (X, Y, angle to the center and diagonal size etc)
  

• whith a library specific Rectangle function (Win32)
  
• using a PostScript-like library (SetPath, LineTo, StrokePath etc)
  
• with a page description (PDF)
  
• at a higher level with tagged languages like HTML, XML, possibly style sheets
  
• or at the opposite corner, directly changing the colors of the screen pixels, what everybody ends up doing anyway
  

• interrupt redirection (DOS): the action on the keybord calls an interrupt handler
  
• event driven call backs (Mac, Windows): the OS send a message and the application's message loop dispatches the message to an event handler
  
• TPC-IP communications (X Windows): whenever the user hits "A" on the keyboard, a TCP-IP packet is sent off to Hawaii, travels all the way to Japan, checks what's happening Down Under, and finally comes running back in New York to print 'A' on your screen. Fine.
  

• 2 kind of rectangle specification
  
  • X1, Y1, X2, Y2 for the square controls
    
  • X1, Y1, horizontal size and percentage height for the round controls
    
• a single event call back mechanism for user actions
  

2.3 - The Square Class

From this ancestor, we derive the real controls: buttons, labels, scroll bars etc. The button definition, for instance is the following:

We simply added the additional attributes (caption in our case) and event handler (mouse up and down to display the shadow change which visually shows the push down effect)

2.4 - The Round class

2.5 - The abstract control

Well yes and no. In this case:

• we must keep an access to our controls. This could be through global variables, but, quite naturally, it is better to use some kind of list. In the same way that Delphi uses Components and Controls attached to each tForm
  
• whenever we have to encapsulate a tList or a tStringlist, we start from a template unit with a basic class and a tList or tStringlist container class, and simply change the names
  
• in our case, the unit for the round or square controls would have been identical, but for the "round" or "square" name. So we decided to use the same unit, and made the basic class the common ancestor of the c_round_control and c_square_control
  

You may check that this list does not contain any "round" or "square" specific code.

2.6 - Using the Controls

Should we want to use the other library, we would have called:

The programmer therefore will have to remember all the subtelties of the different calling conventions, like the radius offset and conversion ratios used to have the same final result

Enters the Abstract Factory pattern.

3 - The Abstract Factory Pattern

3.1 - Objectives

• to offer a common single convention creating controls from different windowing libraries
  
• to hide the details of the creation in a separate class
  

A you see, we have standardized all the creation conventions using the Delphi Left, Top, Width and Height parameters. In addition those classes are all ABSTRACT (they are either empty or contain VIRTUAL; ABSTRACT methods).

Now if our user wants to use square controls, he will use descendents of both the factory and of the abstract widgets:

and the user will call:

with the following result:

Also notice that the Abstract Factory not only unifies the calling conventions but also allows RUN TIME change of the creation (in the above example, be creating different concrete factories, we could use controls of both kinds in the same application)

3.2 - UML Class Diagrams

In the previous figure, we have highlighted in blue what has to be added when we want to use a new widget:

• the abstract widget and its two concrete implementations
  
• methods for the creation in the abstract an in the concrete factories
  

• create new concrete widgets
  
• create a new concrete factory
  

3.3 - The Class Explosion

3.4 - Selection of the Concrete Factory

If we do not reference the Factory variable elsewhere, we could even use a "super local" variable within the WITH clause:

So, for all the mutliple windowing systems, we need only a single Factory CLASS. In addition, in the client code, we only need a single Factory object. So the Gof suggest to treat the Factory class as a Singleton class.

This factory would then be fetched using a call like

This is quite elegant. But how is the kind of concrete factory chosen ? The Gof simply show this kind of call.

So we investigated a little bit more. The fact that we live in a square or round world HAD to be used to select the concrete factory, but where was this done ?

Well it turns out that in the Singleton chapter, they suggest using an ENVIRONMENT VARIABLE. Of all things ! We used a local variable, even a "super local", and they suggest a sytem wide global !

Naturally there are other ways to select the concrete singleton, but I wanted to highlighte this recommendation of an environment variable.

You may use without any difficulties a Singleton for this example, but we will stick to our local variables, explicitly creating the required concrete factory.

4 - Bridge

4.1 - Standardizing Behaviour

The widgets created by the Factory could be modified to include in each control kind the attributes and methods specific to this control:

However, each time we want to add a new control, we face the class explosion problem and have many changes to do.

Bridge solves this by allowing to change the widget hierarchy independently from the windowing hierarchy. The hierarchy is separated in two parts:

• on one hand, the routines to perform the primitive functions are modeled in a c_gadget_implementation hierarchy, which will enable to draw text, lines, rectangle.
  This hierarchy hides all windowing library by defining an interface for performing all actions on our controls in a uniform (library independent) way
  
• on the other hand the different controls are modeled by c_gadget hierarchy, whose children contain c_button_gadget, c_label_gadget etc.
  This hierarchy is independent of the windowing library chosen:
  • the ancestor may define some methods used by all the descendent classes (draw text, draw rectangle)
    
  • the descendent have methods specific to their task (set a check, fetch an ItemIndex)
    
  In both cases, the work is performed using only the c_gadget_implementation interface, not the library specific routines.
  

In this diagram:

• c_gadget_implementation
  
  • exports raw tCanvas routines, like set_pen_color
    
  • might add some methods using the previous one (draw_triangle which uses draw_line)
    
• c_abstract_gadget uses m_c_gadget_implementation_ref to add other methods used by all its concrete descendents (draw_rectangle)
  
• the concrete descendents use m_c_gadget_implementation_ref to add specific methods (fill_rectangle)
  
• the client only uses the c_gadget concrete descendents, never directly using c_gadget_implementation or its reference m_c_gadget_implementation_ref
  

4.2 - Bridge summary

In their book, the Gof take the window / window_implementation example. They tell us about "IconWindows" and "TransientWindows", "floating palettes". I assume this means "minimized" window, "dialog" and "dialog with a toolbar". The implementation part then offers all kinds of drawing primitives. Does that mean that to minimize an X-Windows window, we have to draw them ourselves on the screen using the implementation routines ? This would be awfull: we would rebuild the library down to the last pixel. If this is not the recommendations, there should be some library routines, like x_window.iconify() and pm_window.iconify(), but they are not present in the window implementation classes.

Their sample code only talks about drawing inside a window: so bridge would be some kind of "generalized canvas". This bridge example only handles the content drawing of windows. The draw_content is then adapted to the specific control, displaying text for an Edit, or loading a bitmap for an minimized window. But this has nothing to do with control specific generalization (scrollbar position, ItemIndex etc). In addition, the minimized display or scroll position are handled transparently by most windowing libraries: we might have to encapsulate different method names and parameters, but will never resort to actually drawing the scrollbar thumb or marking a checkbox.

In our example, we took the more general position of a Bridge used for ALL control handling: the control-specific tasks (scrollbar position) as well as the general tasks (drawing the content).

4.3 - Our implementation

The c_square_gadget_implementation and c_round_gadget_implementation definitions are similar to this abstract ancestor.

Here is the c_abstract_gadget, which will use the c_abstract_gadget_implementation class:

The c_abstract_gadget offers some routines which might be used by descendent concrete gadgets. If all gadgets had to draw triangles, we could use:

And the concrete gadgets with some specific methods:

As an example, here is the code for the c_label_gadget:

We then added a c_abstract_gadget_factory:

And here is the definition of the concrete square factories:

And here is an example of the use of those classes:

• the creation of a button, a label, a scrollbar and a drawing surface

  var g_c_button_gadget: c_button_gadget;     g_c_label_gadget: c_label_gadget;     g_c_scrollbar_gadget: c_scrollbar_gadget;     g_c_draw_surface_gadget: c_draw_surface_gadget; procedure TForm1.create_bridge_Click(Sender: TObject);   var l_c_gadget_factory: c_abstract_gadget_factory;       l_c_gadget_implementation: c_abstract_gadget_implementation;       l_memo_rectangle: t_wh_rectangle;   begin     // -- 1 - the "windowing libraries"     g_c_control_list.Free;     g_c_control_list:= c_control_list.create_control_list('surface', PaintBox1);     // -- 2 - the abstract factory     display_square_or_round;     if square_.Checked       then l_c_gadget_factory:= c_square_gadget_factory.create_square_gadget_factory('square_fact',           g_c_control_list)       else l_c_gadget_factory:= c_round_gadget_factory.create_round_gadget_factory('round_fact',           g_c_control_list);     // -- now all the calls look the same, whether round or square library     with l_c_gadget_factory do     begin       // -- 3 - the gadget implementation       l_c_gadget_implementation:= f_c_create_gadget_implementation('implem');       // -- 4 some sample gadgets       if button_.Checked         then g_c_button_gadget:= f_c_create_button_gadget('Insert',             5, 5, 150, k_button_default_height, Nil);       if label_.Checked         then g_c_label_gadget:= f_c_create_label_gadget('font size',             5, 5+ k_button_default_height+ 5, 135, k_button_default_height);       l_memo_rectangle:= f_wh_rectangle(5, 5+ 2* (k_button_default_height+ 5),           PaintBox1.Width- 10- 25,           PaintBox1.Height- 5- 2* (k_button_default_height+ 5)- 5);       with l_memo_rectangle do       begin         if scroll_.Checked           then g_c_scrollbar_gadget:= f_c_create_scrollbar_gadget('scroll',               m_left+ m_width+ 5, m_top, 20, m_height);         if surface_.Checked           then g_c_draw_surface_gadget:= f_c_create_draw_surface_gadget('memo',               m_left, m_top, m_width, m_height,               Nil, Nil, Nil);       end; // with l_memo_rectangle       Free;     end; // with l_c_widget_factory   end; // create_bridge_Click

  And here is the result:

• and we interact with the gadgets:

  procedure TForm1.use_Click(Sender: TObject);   var l_c_bitmap: tBitmap;   begin     if label_.Checked       then g_c_label_gadget.set_caption('new caption');     if scroll_.Checked       then g_c_scrollbar_gadget.set_position(20);     if surface_.Checked       then         with g_c_draw_surface_gadget do         begin           draw_text(10, 110, 'ok');           set_pen_color(clRed);           draw_rectangle(30, 110, 70, 20);           l_c_bitmap:= tBitmap.Create;           l_c_bitmap.LoadFromFile('client_pc.bmp');           draw_bitmap(150, 110, l_c_bitmap);         end;   end; // handle_Click

  with the following result on a "round" world:

4.4 - Decoupling of Abstract and Implementation Hierarchies

How well do we fare on this account ?

In the If we add another windowing system, all that needs do be changed is the xxx_implementation part:

However, if we want to add another control with some specific handling, like an edit with text selection and clipboard routines, the hierarchies are no longer independent: the SetSelStart and CutToClipBoard must be added to the "implementation" hierarchy.

4.5 - Mary Bridge and Factory ?

Looking at the UML Class Diagram, if the factory creates a Bridge gadget, it would have to have two

This is just what the Bridge wants to avoid: having to deal with the implementation of the controls in the c_gadget unit.

Using the Bridge for any "classic" windowing library would amount to drag the complete VCL methods into the abstract_implementation class. This clearly is unrealistic.

Ok. Then let's try to limit the Bridge to a part of the classes: the controls would have each their abstract / square / round classes, and for some kind of handling, we would hide the specificities of the windowing libraries with a mini-bridge. We tried this for a "universal canvas":

• the canvas_implementation offers a standardized interface to do client-region drawing
  
• the c_draw_surface_gadget uses this implementation
  

This works, but it is no Bridge: there is an "implementation hierarchy" (the green part) but there is no "abstract hierarchy" (the blue part).

So I tried, and very hard. But somehow, this Bridge thingy does not come across. Pushing all the functionalities into the abstract_implementation violates both encapsulation and loose coupling, and downsizing the abstract hierarchy destroys the Bridge.

What is the lesson ?

• first, in the Bridge chapter in the Gof book, other examples are presented: Collections, String hierarchies with cache and reference counting, bags of different data types. Many papers and tools performing reengineering or refactoring, like FAMOOS This will be the next trial. I shall return !
  
• second, the exercise demonstrates the usefulness of the UML notation: we can sketch out several architectures, compare their benefits and costs, before jumping to the keyboard. And even if you do not have a nice drawing tool with colors and all, pencil and paper will already allow to reason about several alternatives.
  

5 - Improvements

5.1 - The architecture

There are 4 levels in our hierarchy:

• Win32, with routines like RegisterClass, CreateWindow
  
• Delphi encapsulates those routines in the VCL Classes, with the tPaintBox and a tCanvas
  
• to simulate two different windowing libraries, the square and the round worlds, we created the c_square_controls and c_round_controls
  
• to insulate our application from the windowing libraries, our Bridge defined
  • a c_abstract_gadget_implementation to define the library independent gadget handling interface
    
  • a c_gadget hierarchy with all the gadgets we intended to use: c_button_gadget etc
    
  • an Abstract Factory creates
    
    • the concrete gadget_implementation
      
    • all the concrete gadgets
      

We did not display the "widget" classes, which were the first encapsulation of the controls, but not with a bridge.

So our naming conventions are:

• "controls" for the windowing libraries simulations
  
• "widgets" for the first factory trial
  
• "gadget" for the Bridge example
  

5.2 - Improvements

• the "events" are not completely working (if you click on a button and move the mouse outside of the button area, the button remains pushed. We should capture the mouse)
  
• the list of controls could also have been separated in two, to improve the simulation of two different libraries
  
• the Paint function has been totally ignored
  
• the freeing of objects also has not been much taken care of
  

6 - Download the Sources

• factory_and_bridge_patterns.zip: the complete project (36 K)
  

The .ZIP file contain:

• the main program (.DPR, .DOF, .RES), the main form (.PAS, .DFM), and any other auxiliary form
  
• any .TXT for parameters
  
• all units (.PAS) for units
  

• are self-contained: you will not need any other product (unless expressly mentioned).
  
• can be used from any folder (the pathes are RELATIVE)
  
• will not modify your PC in any way beyond the path where you placed the .ZIP (no registry changes, no path creation etc).
  

• create or select any folder of your choice
  
• unzip the downloaded file
  
• using Delphi, compile and execute
  

As usual:

• please tell us at fcolibri@felix-colibri.com if you found some errors, mistakes, bugs, broken links or had some problem downloading the file. Resulting corrections will be helpful for other readers
  
• we welcome any comment, criticism, enhancement, other sources or reference suggestion. Just send an e-mail to fcolibri@felix-colibri.com.
  
• or more simply, enter your (anonymous or with your e-mail if you want an answer) comments below and clic the "send" button

  Name :
  E-mail :
  Comments * :

• and if you liked this article, talk about this site to your fellow developpers, add a link to your links page ou mention our articles in your blog or newsgroup posts when relevant. That's the way we operate: the more traffic and Google references we get, the more articles we will write.
  

7 - Conclusion

8 - References

• The FAMOOS Reengineering Handbook : references about the printed book, a downloadable handbook and many papers about this reegineering effort. Sadly enough, I could not find the tool anywhere, even in .EXE
  
• The Lexi Editor : the companion paper presenting the 6 other Design Pattern (Composite, Decorator, Iterator, Strategy, Visitor, Command) included in the Gof Lexi Case Study, with Delphi sources, of course.
  

9 - Other Papers with Source and Links

10 - The author