tags:

views:

35

answers:

2

I have two essentially separate applications for configuring two pieces of hardware sold by this company.

I've been asked to put the two applications together so that they can be accessed from within the same program in such a way that both are accessible. An analogy to the idea would be opening a program, selecting a file to open, then opening a document editor or a spreadsheet editor depending on the type of the file.

This isn't particularly difficult for most aspects of the application, but my problem comes mostly from the main toolbar for the consolidated application. Each of the two different applications has its own set of functions relating to a common set of buttons, as well as having its own set of buttons.

I could separate the button responses in code with typechecking, i.e.

If documentOpened.isSpreadsheet
  spreadSheetFunction()
Else
  documentFunction()

but this seems messy to me, incorporating the functions of two classes into one bloated interface class.

Is there some way to achieve a greater degree of encapsulation, here, given that the two interfaces are so different?

+1  A: 

I don't know .Net, so this is general object-oriented programming advice. However, you look like you're asking a general OO design question.

It looks like you're trying to do double dispatch; that is, choose the actual code that gets executed based on the runtime type of two different things.

The traditional clean-OO way to accomplish double dispatch is with the visitor pattern. Don't get fooled by the name or by examples describing the pattern to walk some sort of containing strucutre; it's also very useful even if you only have one object at a time!

Basically, what you would do is define some interface - CommonButtonHandler - and then have an implementation for both spreadsheets and documents. When the common "twiddle" button is clicked, you do:

// Inside CommonTwiddleButton.onClick()
currentCommonButtonHandler.twiddleButtonClicked()

There are some nice examples online of using the visitor pattern for double dispatch; just be sure to search for both terms, or you'll end up with either a bunch of visitor pattern examples that assume you need to walk some sort of heterogeneous collection or a bunch of lisp weenies bragging about how their object system just does multiple dispatch by default.

Daniel Martin
+1  A: 

The thing that springs to mind is the Visitor design pattern (though it's probably not applicable in the strictest sense). If you defined an interface that embodied all the buttons on your toolbar and then implemented a class for each document type that would work fine as Daniel suggests. Outline code would be

public interface IToolbarHandler {
  void ButtonOne;
  void ButtonTwo;
  //etc
}

public class SpreadsheetToolbarHandler : IToolbarHandler {
   public void ButtonOne {
      //Do Some action
   }
   public void ButtonTwo {
      //Do Some action
   }
}

public class DocumentToolbarHandler : IToolbarHandler {
   public void ButtonOne {
      //Do Some action
   }
   public void ButtonTwo {
      //Do Some action
   }
}

Then simply have a form level variable which is of type IToolbarHandler and set to an instance of the relevant handler for the document currently being viewed. Then your toolbar event handlers simply invoke the relevant method of that variable.

RobV
Okay, I'll try that. I guess that the non-common buttons will just end up with event handlers that don't do anything on the interfaces where they don't occur...
Frosty840