Post by AlexanderPost by Marco HunsickerEine saubere Lösungen sieht sicher anders aus.
Vorschlag?
Repost eines meiner Postings:
A component here is an object controlling an area of a
graphical user interface, like a command button or a window.
(A degenerate component might also be an »invisible«
component, i.e., a simple object.)
MVC or model-view-separation deals with the internal structure
of a single GUI component.
An application usually has multiple components, often nested in
the form of a tree.
Therefore, I would like to plan the relationship between
several components.
I write down some ideas here. Possibly someone already has
heard about similar schemas and can tell me if there already
is a name for the following plan.
A window (which is a component), for example, might have an
upper part with a list (which is a component) and a lower part
with a log console (which is a component).
window
component
/\
/ \
/ \
/ \
/ \
table console
component component
.---------------------------------.
| window component |
| .-----------------------------. |
| | table component | |
| | | |
| | | |
| | | |
| '-----------------------------' |
| .-----------------------------. |
| | console component | |
| | | |
| | | |
| | | |
| '-----------------------------' |
'---------------------------------'
How does the table component request some text to be logged?
I do not want the table component to be aware of the console
component. This would make it more difficult to reuse the
table component in other contexts without a console component
or to add or remove the table component or the console
component independently of other components. (If you do not
accept this reason, I also might refer to Demeter's law.)
So, instead of directly accessing the console component, the
table component "escalates" a log-report to the window
component, which is its container. The window component then
knows that it has a "log-report-handler" (i.e., the console
component), and then delegates the log-request to the console
component.
Thus, the application component structure I made up recently is
to build an application as a tree of components which obey
Demeter's law and therefore only communicate via the /edges/
of this component tree, i.e., each component communicates only
with its direct container or one of its direct containees.
A common special case are several components sharing a single
model. Then, I want a common container component of these two
components to be (or hold) the model. For example,
window (and model for "view 0" and "view 1")
/\
/ \
/ \
/ \
/ \
view 0 view 1
.---------------------------------.
| window |
| .-----------------------------. |
| | view 0 | |
| | | |
| | | |
| | | |
| '-----------------------------' |
| .-----------------------------. |
| | view 1 | |
| | | |
| | | |
| | | |
| '-----------------------------' |
'---------------------------------'
Here, the window doubles as the model for its subcomponents,
when they both need to refer to common data. (The observer
relation might hold between any two components of an application,
but has to be initiated via the edges of the tree.)
The layout of an application might be changed at runtime by
adding components to a container component. When this happens,
some requirements will be checked: A certain container might
only accept components implementing certain operations and the
components might require its container to implement certain
models for it.
The tree structure means that each component (except the root
component) has a single container component that represents
the rest of the application to the contained component.
Whenever a component needs something it can not do itself, it
will request this from its direct container.
When a container receives a request from one of its directly
contained subcomponents, it might handle it or it might
delegate it to another of its subcomponents.
When a container can not handle a request in one of these ways
(for example, a request of an unknown type), it will escalated
it to its own container.
When the root component receives a request it can not handle,
it might report this as an error or silently drop the request,
depending on what is most useful or appropriate in this
application.
For example, a component deep down in the tree might need to
know the »current directory« of the application, so it will
ask its container:
this.container.getEnv( "cd" );
If the container does not have an environment variable »cd«,
it will escalate the request to its own container:
Object getEnv( name )
{ if( this.env.contains( name ))return this.env.get( name );
else return this.container.getEnv( name ); }
Or, if a component does not have an own environment storage
itself, it will immediatly escalate:
Object getEnv( name )
{ return this.container.getEnv( name ); }