Command Pattern


Definition of a Macro: “An object that contains a symbol, name or key that represents a list of commands, actions or keystrokes”. This is the basis of the Command design pattern.

The Command Pattern encapsulates commands (method calls) in objects, allowing us to issue requests without knowing the requested operation or the requesting object. This pattern provides the options to queue commands, undo/redo actions etc.


  • Encapsulate a request in an object
  • Allows the parameterization of clients with different requests
  • Allows saving the requests in a queue

The classes participating in the pattern are:

  • Command
    • declares an interface for executing an operation
  • ConcreteCommand
    • extends the Command interface, implementing the Execute method by invoking the corresponding operations on Receiver. It defines a link between the Receiver and the action.
  • Client
    • creates a ConcreteCommand object and sets its receiver
  • Invoker
    • asks the command to carry out the request
  • Receiver
    • knows how to perform the operations

The Client asks for a command to be executed. The Invoker takes the command, encapsulates it and places it in a queue, in case there is something else to do first, and the ConcreteCommand that is in charge of the requested command, sending its result to the Receiver.

I’ve basically nicked all this, word for word, from the source below but it seemed pointless to reword and rework it too much. It’s good info.




Factory Pattern

Factory Pattern

The Factory Pattern creates objects without exposing the underlying logic to the calling class, which then refers to the newly created object through a common interface.

The advantage of this pattern is that new “products” can be added without changing a single line of code in the framework (the client code that uses the resultant objects).



Singleton Pattern

The Singleton Pattern basically restricts the instantiation of a class to one object.

An very simple example of this is as follows:

    public class Singleton {

        private static Singleton singleton = new Singleton();
        private static double randomNumber = (Math.random() * 100000);

        /* A private Constructor prevents any other
        * class from instantiating.
        private Singleton(){ }

        /* Static ‘instance’ method */
        public static Singleton getInstance() {
            return singleton;

        /* Other methods protected by singleton-ness */
        protected static void demoMethod() {
            System.out.println(“demoMethod for singleton (” + randomNumber + “)”);

    public class SingletonDemo {

        public static void main(String[] args) {
            Singleton tmp = Singleton.getInstance( );
            tmp.demoMethod( );

            Singleton tmp2 = Singleton.getInstance( );
            tmp2.demoMethod( );

The reason we include a random number is to prove that we get the same instance of Singleton whenever we call getInstance().



Observer Pattern


So, I’ve been looking at Design Patterns lately, and I’ve decided to document a couple, starting with the Observer Pattern.

The basic gist of it is that you have an “observable” class/interface (in this case Subject implemented as MyTopic) which has, amongst others, the methods register(Observer obj) and notifyObservers().

You then pass in concrete instances of the interface Observer (in this case MyTopicSubscriber) via the subject.register() method, and then – any time the Subject is altered or otherwise interacted with, it can then call notifyObservers() and then – via calls to each of the Observer object’s update() method, everyone in that list of Observers can be informed.

That’s about it, really. Seems simple!



You Just Got Served

Screen Shot 2014-08-19 at 13.55.37

Got myself a nice little nano PC to act as my server (thank you, Louise) and I’ve been a busy little bee since Friday night getting it set up.

I’ve now got it doing pretty much exactly what I need, and I can summarise it as follows:

  • Installed Git and Maven
  • Implemented fully functioning remote git repository with (almost) all my projects loaded in
  • Installed PHP, Apache, MySQL etc.
  • Published basic website to www, using no-ip to keep a static URL
  • Got PHP-based Mantis bug tracking system running on an Apache server, behind a protected folder, published to the www
  • Implemented remote SSH access
    • Although this was just an exercise to see if it can be done – I’ve now closed the relevant ports on the router
  • Installed TeamViewer so that I can remotely administer the server

So I’ve got my home development environment set up pretty nicely now. I think the bug tracking thing is crucial – it will help give me visibility and guidance throughout the development process. I may even end up with useful estimates of completion times!

Future tasks which will continue to improve my system are as follows:

  • Get Maven builds working for Android projects
  • Get ProGuard working
  • Produce Java applications as executable installers

That should do for now. I’m off!



Plans For DiagramBuilder

Screen Shot 2014-08-11 at 11.58.23

I’ve implemented quite a few improvements and bug fixes to DiagramBuilder lately, notably:

  • Removed right-click drag diagram
  • Implemented Ctrl-A select all
  • Implemented cut, copy and paste
  • Implemented Alt-drag to create/destroy links
  • Implemented alpha colour setting/saving
  • Implemented “bring to front”/”push to back” object reordering

My next few tasks will be amongst the following:

  • Implement curved lines
    • Setting and saving – might be complex
  • Implement diagram-type specific icons (ie. servers, DBs etc.)
  • Get multi-layer diagrams working again
  • Implement plugin mechanism
  • Allow basic primitive shapes
    • Creating and saving
  • Allow primitive shapes to be auto-merged into polygons where overlap occurs
  • Keep ZM splash screen on top until finished
  • Implement a “snap to” option, which keeps nodes to the nearest 45˚ in relation to their linked node(s)
  • Improve dragging of nodes (and node size, font size etc.) to take into account difference between initial dragPoint and node centre

That should be enough for now. This application should really start taking shape soon.



Git Yourself Together

Right, I was having a good think yesterday on how to re-organise my working environment at home. Obviously, I’ve already blogged about using Git etc. but my plans went a bit further.

I’ve ordered a mini PC, which will function as my home server, on which I will host Git etc. and now I’m itching to get all my projects under proper control.

One of the first things I want to do is implement all the required fixes for DiagramBuilder, and get it working in Maven. I would like to release this as a full product soon, and then continue to produce better iterations. Once I get my bug-tracking stuff sorted, applications and updates should be flying out the door.

Also, once I get an improved DiagramBuilder up and running, I can actually use it to help plan everything else anyway.

I will need to get ProGuard working before I release anything else though, definitely.

So, a quick high-level plan for the near future:

  • Get home server running
  • Set up as a Git server
  • Set up as mantis server
    • Enter all known issues for all existing products
  • Convert all existing projects to Git projects
    • Convert to, and build with, Maven (where possible)
  • Finish v1.0 of DiagramBuilder
  • Continue working on main app

That’s general enough I suppose. And I’m off!