The Return of the Intent

Gentle readers, I am returning with renewed intent and vigor to the task of programming my legal costs application. The new program is to be known as Visibill. This weekend I have been wrestling with the concept of channels and things. Among the key questions I have are:

(1) I can readily understand why a ServerSocketChannel must have a selector. Why does a client SocketChannel need a selector too?

(2) How does a blocking Socket handle asynchronous (non-blocking) input from a ServerSocketChannel?

In other news, my christening of the server application has been successful. Unsuspecting public, I present to you Visibill Control! As for the client... Visibill Receipt?

More puzzlement to come!

The remembrance of patterns past

The Observer pattern is a pattern that is easy enough to grasp and remember. Yet it has proved a struggle for me to implement this pattern in the context of a client-server application using Java sockets. The issue boils down to this. The client subscriber or observer must be Serializable enough to pass through the socket to the server for it to register with its subscribers list. Yet the socket reference that the client communicates with the server by is non-Serializable.

More to come. :)

Contract abstraction

I am puzzled about adding another layer of abstraction to my dice simulator, a contract that enables the code to slip easily between changes to my GUI and my data.

Perhaps two sets of Model, View, Controller? One set for a basic program to receive user input, and another set which varies according to the user’s input?

Depilatory programming

My Shadowrun Dice Simulator vexes me in several ways, all to do with object-oriented design:

• the user's choice of test affects the user interface as well as the object representing the test data
• the user's choice of test parameters affects the user interface as well as the object representing the test data
• accordingly, the construction of the user interface depends on a number of conditions
• similarly, the construction of the object representing the test data depends on a number of conditions
• this raises the consequent question of how the MVC architecture can be satisfactorily implemented

Well, I'm on the cusp of something. I don't know what it is but my mockups - JFrames, JDialogs, etc - make for a nice application. It's a matter of applying object-oriented design principles properly. Goodness knows how I am going to do that, with Stackoverflow.com unhelpful on such things.

Encapsulate what varies: the choice of test, the choice of test parameters, the user interface, the object representing the test data.

Abstract Factory Pattern

The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.

This pattern saves clients the bother of instantiating families of products. The client is written against an abstract factory interface. The interface, which creates products in the abstract, is implemented in concrete factories which create the particular families of products from concrete implementations of abstract product classes.

One question I have is whether the client needs to also be written against the abstract product classes, as the Wikipedia article on this pattern suggests.

Decorator Pattern

The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Subclassing components would extend functionality at compile time. Fortunately, however, the Decorator Pattern does this at run time. The pattern means that classes are open for extension but closed for modification.

This pattern wraps a concrete component with one or more decorations, or additional responsibilities. Decorations are derived from an abstract decorator class which in turn inherits from an abstract component superclass.

The concrete decorator class is passed a component in its constructor, so that operations inherited from the abstract component superclass can build on - decorate - the component.

An implementation of the Decorator Pattern carries with it an assumption that the abstract component superclass type is satisfactory to the rest of your code. You should consider another pattern if the concrete component type is what the rest of your code depends on.

Observer Pattern

The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.

This pattern is useful for the loosely coupled way it disseminates the fact of a data event or data change in a single subject to as many observers of that subject as have subscribed to receive such notifications.

Apparently, usual practice is for observers to "pull" data from the subject rather than for the subject to "push" the data to observers; in other words, usual practice is for the subject to have getter methods for its state rather than send its data as a parameter in a notifyObservers() call.

A concrete subject implements an interface to register, unregister and notify observers and has a list of registered observers that receive notifications. Concrete observers of the subject implement an interface to update themselves or other objects upon receiving notification of data events or changes in the subject.