Hi, Thufir!

OK, lets aim this baby in the Model-View-Controller direction, and
kill half a flock of birds with one stone.

In the previous email, I mistakenly showed Driver as implementing a
View interface, but I will correct this in this example, and portray
Driver as a Controller. Do forgive this changed point of view, but it
should make the example more, "Real world."

It should forever strike you as odd when you hear a designer say,
"I've used the MVC pattern to organise my classes for this problem,"
and then when you see the design there's no model package, no view
package, and no controller package. A mistake we won't make as we
embellish this example.

The first principle of OO states, as you know, "Program to an
interface, not an implementation."

The theory we're discussing here can also be reduced to a shockingly
similar principle, "Program to an interface repository, not an
implementation repository."

We will hereby define an interface repository as a package containing
at most one concrete class. An implementation repository is a package
containing more than one concrete class.

Note that this theory was developed for industrial-sized systems, so
looks overkill here, but it should get the point across.

We will split this example application into five packages: model,
view, controller, start, and ir1. "ir1" is the standard name for the
first
interface repository. All these packages are usually peers (i.e., they
have the same parent package). model, view, and controller will all be
implementation repositories.

The start package is special: it contains just one class, Start, which
holds the public static void main() method, and is responsible for
triggering one public class in each of the three other implementation
repositories. So, in the model package, there will be one public
concrete class called, "ModelStart;" in the controller package, there
will be, "ControllerStart," etc. Crucially, these XStart classes are
the only public concrete classes in the implementation repositories;
all other classes in the package will be package-private. These XStart
classes then tell as many as necessary of the other, package-private
contrete classes in the implementation repositories that the system has
started, and they must register themselves in the registry.

The ir1 package will contain the singleton, concrete class Registry,
and will also contain the View interface. (In fact, ir1 will contain
*all* the interfaces visibile to all other packages; all the
interfaces - as well as the Registry class - in ir1 will be public.)

The model package will contain, as well as ModelStart, the concrete,
package-private class Database, which will implement the interface
ir1.Model.

The view package will contain, as well as ViewStart, the
package-private, concrete classes TextView, FileView, and SocketView,
all of which will implement ir1.View.

The controller package will contain, as well as public class
ControllerStart, the package-private concrete class Driver, which will
implement ir1.Controller.

When the start.Start class's main() method is called, it will, as
mentioned, contact all the other XStart classes, and they will order
the relevant package-private implementation classes to register in the
Registry. (Of course, in reality, only a few classes will need to
register.)

Thus, for example, controller.Driver will register its Controller
interface
in the Registry by calling:
Registry.getInstance().register(this).

Next, a user will make some input; we needn't specify how, here, but
suffice it to say that when that input is made, an object will need to
get that input into the system. It will do this by doing something
like:
Controller controller = Registry.getRegistry().getController();
controller.process(input);

The Driver object will have its process() method called, and will kick
the database into life, by something like:
Registry registry = Registry.getInstance();
Model model = registry.getModel();
model.doThis();
model.doThat();
Result result = model.getResult();

(OK, here's an interface I'd forgotten; any guesses where we'd declare
it?)

The Driver object would then output the result to the use by:
int viewID = registry.getCurrentViewID();
View view = registry.getView(viewID);
view.show(result);

Thus we have a system in which there are only two types of
inter-package, concrete class dependencies:

1) From Start to XStart - and these XStart classes only contain enough
  logic to kick start the business logic, in other words, these
  dependencies do not change as business logic changes.

2) Dependencies on the Registry concrete class - but this class simply
  stores and erturns interfaces, and has no dependencies on the
  methods of those interfaces, and thus is immune to changes of the
  interface methods (although of course will change as whole
  interfaces change, and new ones are added).

And *all* other inter-package dependencies are on interfaces
only. Thus, you can switch in any database you like, as long as it
conforms to the Model interface (this will, in reality, probably be
JDBC, or a wrapper thereof). The same goes for the Views and even the
Controller itself.

Hence, "Program to an interface repository, not an implementation
repository."

Note that model package, view package, and controller packages do not
depend on one another (you can Google for the heated discussions on
which of these packages should depend on one another, and which must
not), and that the system is guaranteed to be free from inter-package
circular dependencies.

Of course a full system will have hundreds of packages, and there will
be hierarchical start/implementation repository/irX packages, but the
design is - and particularly the benefits listed above are -
wonderfully extensible.

.ed

www.EdmundKirwan.com - Home of The Fractal Class Composition.