1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
This directory contains "controllers". These are non-GUI objects that
manage GUI objects by connecting to their signals and updating them as
appropriate. Using controllers to manage GUI elements rather than
creating new widget types has several benefits:
1) It allows logic that involves several collaborating widgets to be
localized into a single code module. e.g., the widgets involved
in performing a package search might be in different parts of the
GUI rather than in a single container, but a single controller
can manage all of them.
2) It can make it easier to reuse logic in a new context (due to 1).
3) It can simplify some memory management considerations, by using
classes whose lifetimes are detached from the lifetimes of the
physical widgets they manage.
4) If controllers don't interact explicitly with GUI objects, they
can be unit-tested. e.g., the controller could interact with the
GUI via an abstract interface, and the unit test could provide an
implementation of this interface that is entirely non-interactive.
This directory, being in the generic section of the aptitude source
code, should not contain references to any UI-level objects.
For at least some of aptitude's code, 4) will require refactoring,
which should be done opportunistically as usual.
Controllers might provide an interface to the outside world; if so,
they should declare that interface as an abstract class in their
header file, deriving from sigc::trackable. This reduces compile-time
build dependencies and allows the controller to be mocked out for
testing.
Unlike views, controllers are implemented in this directory. This is
because controllers are less likely to have multiple implementations,
and also because they won't contaminate the abstract interface file
with GUI dependencies (whereas view implementations by definition must
be constructed from GUI objects).
|
