Why POCO is well implemented and designed?

When i searched for a description of POCO i found the following definition:

"The POCO C++ Libraries are a collection of open source class libraries for developing network-centric, portable applications in C++. POCO stands for POrtable COmponents. The libraries cover functionality such as threads, thread synchronization, file system access, streams, shared libraries and class loading, sockets and network protocols (HTTP, FTP, SMTP, etc.), and include an HTTP server, as well as an XML parser with SAX2 and DOM interfaces and SQL database access. The modular and efficient design and implementation makes the POCO C++ Libraries well suited for embedded development."

The Abstract Factory Pattern provides an interface for creating families of related objects without specifying their concrete classes. The Abstract Pattern makes sure that the client does not know anything about the objects being created. The pattern hides the implementation of the product definitions and their class names and the only way the client can create a product is through the factory.

Let’s discover the benefits of this Pattern using CppDepend, and for that we analyze the following example.

in this example we have a code source before and after refactoring, you can copy the code into two distincts files factorybefore.cpp and factoryafter.cpp.

CppDepend Analysis

To analyze this example with CppDepend, do the following steps:

- Lanch VisualCppDepend.exe and create new project.
- Use “Create Project Description “ Button to lauch the project maker wizard

- Add Project to solution.
- Add Files to project created

- Save as “Factory.sl”
- In VisualCppDepend use “Browse” button to specify Factory.sl file.
- Launch the analysis.

After the analysis of the example before using factory pattern, we analyze it after the modifications, for that we have to change the description of the project by removing “factorybefore.cpp” and adding “factoryafter.cpp”.

CppDepend provide an interesting functionality to compare between two version, in our case we compare the project before and after refactoring and there's the result.

we can see that there are some added new classes in the browser characterized by the Bold Style and there's also a modification in dependency matrix.

Where WindowsButton class is created?

To answer to this question let’s execute the following CQL request:

SELECT METHODS WHERE CreateA "WindowsButton" ORDER BY DepthOfCreateA

Before:

After:

So we can observe that before refactoring, the class is created in many places, but after refactoring the creation is isolated in WindowsFactory, the responsibility of the creation is now isolated and it impact the cohesion, so we have a high cohesion than before.

What the impact for coupling?

Using Matrix can help to detect coupling between projects and classes.

If you look at the intersection between main method and MotifButton class we observe a red “-“sign, so we lose a dependency between Main and other classes like WindowsButton, MotifButton.

Let’s discover the dependency graph before and after:

Before:

After:

So the global methods are now isolated form concretes classes used, and we have a low coupling so we can add another family of classes without changing the client that use them, only the factory will be changed.

Conclusion:

Abstract Factory can improve the cohesion and coupling of classes.

A quick analyze of the MFC evolution

Let’s have a look to see what the tool CppDepend shows when comparing MFC 2005 with MFC 2008 ones. I will use a few CQL Queries to get fact from the code base of the Framework.

A view of the work achieved

SELECT METHODS WHERE CodeWasChanged OR WasAdded

The following treemap shows in blue, new methods (i.e WasAdded) and methods that have been refactored (i.e where CodeWasChanged). A rectangle represents a method and the size of the rectangle is proportional to the size of the method (in terms of Code Line ). It is pretty impressive to see that a big part of the framework is still evolving.

The Info panel of CppDepend shows that MFC 2008 is bigger twice than MFC 2005

New Types

SELECT TYPES WHERE WasAdded

367 new types added including:

• Menus
• Toolbars
• Panes
• Ribbon Control
• Outlook Alert
• Controls
• Dialog Boxes
• Customization
• Visualization

New Namespaces

SELECT NAMESPACES WHERE WasAdded

Only 1 namespace was added it contains classes to integrate Winform into MFC.

Methods where visibility changed

Only the visibility of the CHtmlEditCtrl destructor was changed from protected to public.
It was a design bug in MFC 2005, you can discover here why it was problematic.

Types Removed

All classes relative to ISAPI were removed; it’s a break change that can be very embarrassing for developers who used them before.

Conclusion

The major evolution of MFC includes a new types to support modern user interface (UI) elements such as the Office Fluent UI, docking windows and MDI tabbed windows similar to those used in some releases of Visual Studio, enhanced toolbars, a rich new set of controls, support for controlling the overall visual style, support for desktop alerts, and much more.

but no big changes concerns the MFC design,it's true that MFC now use more manager classes as controlers than before

but the design of the new functionalities still unchanged, for example only one namespace is added.