Understanding the problem

Introduction to the problem – User Interface Component Design

In this section we will discuss “Composite Design Patterns” and its applications.

First let me introduce the basic problem statement addressed by this pattern

“Design a whole part structure in such a way so that the user of this structure doesn’t understand the difference between the whole and the part.”

This is a general problem statement.

Let me give you a practical problem that exemplifies this generic problem statement.

Let’s look at the Graphical User Interface drawn below. Every GUI will typically have a structure like this.

Figure- Figure

The figure shows different UI artefacts nested at different levels of granularity. Every UI will typically have a structure like this.

Don’t you think that every UI is a whole part structure?

Fine. Now tell think about who is responsible for rendering any GUI on your computers?

Do you agree that rendering a User Interface is a core operating system task?

Rendering any user interface is a core operating system task. Within every OS there is a component called as Renderer who is responsible for rendering any UI.

The figure below shows the arrangement

Figure- Figure

For the Renderer to render any UI, it should know how to render every other UI artefact from different programming languages, technologies and UI development Frameworks nested at different levels of granularity.

Is it practical for the Renderer to keep track of every other UI artefact supported by different programming languages, technologies and UI development framework?

There are numerous UI artefacts like Window, Panel, Textbox, Hyperlink etc supported by languages like Java, C, C++ etc and by frameworks like MFC, SWINGS, Flex, WebDynPro etc.

If the renderer has to keep a track of all these things, the renderer will soon get over burdened with a large number of UI artefacts and even if it manages to do once, with every other change beginning with respect to UI artefacts at different levels will have an impact on the renderer.

With every UI artefact added or with a new UI development Framework coming, the renderer of all OS should get changed.

Is it a good design?

Does it happen like this in real world?

The problem is multifaceted out here. The OS cannot leave this behaviour with the UI applications as it will lose the control of one of the most fundamental behaviours and would not be able to do the things due to the sheer combinations of UI artefacts.

Don’t you think it is a problem of Flexibility? With every change of UI artefact the renderer is getting impacted.

The answer to this problem is Controlled Flexibility.

The OS controls when the UI needs to be rendered but should allow the native UI application/ Framework to decide how that UI should be rendered. Or in other words, “When” is controlled by the OS but “How” is controlled by the individual frameworks.

The problem is solved by OS deciding and Interface called as UI Component which has a method called as Paint.

This problem is solved by OS Vendors mandating that any UI Artifact that needs to be rendered should have a method called as Paint().

So don’t you think this is the same problem. The user Interface is a whole part structure which has to be designed in such a way so that the Client i.e. the renderer in this case is not able to understand whether it is speaking to the top level window object, left navigation bar, table, form or a button.

How will we solve this problem?

 
Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer

www.VPlanSolutions.co.in