Multiple client implementations.

[Rowland]

Hi all,

I've written a server program in Java that allows clients to transmit
commands and recieve an appropriate response (e.g. some data from a
database, etc.). There will be several different clients, designed for
people with different roles within the company. These different clients will
share a number of forms, with maybe one or two role specific forms being
added, and certain buttons being disabled within each client.

What would be the best way to go about implementing this in terms of
code-reuse, modularity, etc.

My original idea was a BasicClient superclass with most of the forms
contained within that.
This would then be extended to an AdminClient, UserClient, ManagerClient
(for example), which would enable / disable specific forms/buttons. Would
this work well, or is there a better suggestion?

Many thanks,

Rowland.

 

[Sudsy]

Rowland wrote:

What would be the best way to go about implementing this in terms of
code-reuse, modularity, etc.

<snip>

I'd use a Struts/Tiles combination. How's this for simple?:
<tiles:insert name="adminButtons.jsp" role="admin">
The content is only included if the user is in the specified
role.
It might be worth picking up "Programming Jakarta Struts" by
Chuck Cavaness (ISBN 0-596-00328-5). The whole book is great
but you will be particulary interested in chapter 14, "Using
Tiles".

 

[Chris Smith]

What would be the best way to go about implementing this in terms of
code-reuse, modularity, etc.

My original idea was a BasicClient superclass with most of the forms
contained within that.
This would then be extended to an AdminClient, UserClient, ManagerClient
(for example), which would enable / disable specific forms/buttons. Would
this work well, or is there a better suggestion?

It's hard to answer general design questions like this on USENET where a
lot of details aren't available. That being said, my initial hunch is
that you'd be better off going for either of the following instead,
depending on exactly how similar these clients are:

1. Composition; provide the building blocks, and let each client
assemble them in the way appropriate for that piece of software, or:

2. One piece of software with all the code, and a configuration file
specifying how it should appear to this specific user.

Inheritance is not generally well-suited as a fundamental approach to
these kinds of problems. That's not to say that there won't be some
inheritance involved in your implementation; but at the most basic
level, I'd think of it as a composition problem.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation