Re: static or not?



hawat.thufir@xxxxxxxxx wrote:
> iamfractal@xxxxxxxxxxx wrote:
> > Hi, Thufir,
> ...
>
> There'd be package "driverAndViews," or something, with the various
> view interfaces package private; or, the views would be nested
> within Driver. The view interfaces are registered in Registry to
> enable Database to send that e-mail to the CEO.
>
> How does the communication between Database and Registry work?
>


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.

.

Relevant Pages

  • Re: Separate Compilation in Programming Languages
    ... within one package body. ... all, separate or otherwise. ... OK, so you like having textually separate spec and body, ... Clients of an interface do not depend ...
    (comp.lang.ada)
  • Re: Global variables
    ... I have a litte OT question: how do you initialize the Repository? ... first class triggered the Starter class. ... principle of object orientation is to design towards an interface, ... Starter class must not reside in the interface respository package. ...
    (comp.object)
  • Re: static or not?
    ... > Thus, for example, controller.Driver will register its Controller ... then I can strip away an interface from this ... and have it register that interface in the Registry. ... if this is done from class foo, what's foo's package? ...
    (comp.lang.java.help)
  • Re: Classes vs functions
    ... Interfaces were Java's "solution" to multiple inheritance. ... in a way that one class may implement one or more interface. ... PHP; nobody would be obligated to use or abuse it. ... > resource-consuming) to be able to include an entire package. ...
    (comp.lang.php)
  • Re: Interface Delegation or ??
    ... otherwise for public classes use a public interface. ... I don't think the visibility of the interface makes much ... practical difference if the interface is only implemented in package ... public class NewClass implements HiddenInterface { ...
    (comp.lang.java.programmer)