«

Hi all,

I'm writing to request pointers on design questions that I've
encountered while implementing a small scheduling program in Java. The
questions seem to be more closely related to basic object-oriented
design than they are to Java specifically, so please let me know if
there are more suitable forums for these questions.

Background: the program I've been implementing is a simplistic
scheduler for a set of work items that must each proceed through a
lifecycle that contains a fixed set of six stages. The scheduler input
is a sequence of work items, where the sequence specifies the order in
which the items should enter the first work stage. The input for each
work item includes details that apply to the item for each of the six
stages, including how much effort needs to be expended on the item to
complete processing for a stage. For example, the input may specify
that a work item requires one day of work in stage 1, three days in
stage 2, ... (for now, the effort is specified in terms of days
instead of hours). Based on the input provided, the scheduler will
assign dates for each of the stages to each of the items and will
return the resulting schedule.

The scheduler must abide by particular rules that constrain how work
items are permitted to proceed through the stages. In the initial
implementation, the only rules I've implemented specify how many items
can be in a particular work stage simultaneously. For example, the
rules might specify that it is permissible to have a maximum of one
work item in stage 1 at any point in time, while stage 2 supports four
items concurrently, and stage 3 supports an unlimited number of
concurrent items. (Note that the scheduler is intended to be flexible
enough to support more complex types of rules than these.)

While I've provided the description above to motivate my questions, my
questions aren't related to the complexities of scheduling. Rather,
what I've found is that my initial implementation contains a number of
distinct class hierarchies that consist of an abstract base class and
a set of six subclasses - one for each of the six work stages. The
most clear example of such a hiearchy is one to capture the stage-
specific scheduling rules. However, there are other similar but
separate hierarchies as well.

My question is whether the repetition of the work stage-based
inheritance hierarchies constitutes a poor design or "a design smell",
and whether there are alternatives or design patterns that can be
applied to improve it.

I spent some time trying to determine whether using an Enum for the
work stage type would improve the design, with little success. Having
said that, as I don't have extensive experience using Enums, it's very
possible I missed something here.

I've also spent a bit of time attempting to reformulate and/or
generalize the question to understand it better, again with limited
success. In particular, I've been unable to identify terminology that
describes the role of the work stage in spawning the repeated class
hierarchies, and I've struggled to formulate effective searches to
identify whether others have encountered questions similar to mine.

I'm not sure that I've described the context or the questions very
well, so please let me know if I can clarify anything. Also, please
note that I would consider it as beneficial to clarify my questions or
understand them more fully as I would to have "an answer" that
improves the design. As such, any information or pointers would be
greatly appreciated.

Thanks,
Josh

J W <> writes:
>distinct class hierarchies that consist of an abstract base class and
>a set of six subclasses - one for each of the six work stages. The

I have skipped reading parts of your article, trying to find
the actual question. So now here I can add something: It
seems you possibly use the template-method pattern: Today,
often the strategy pattern is preferred in Java.

>inheritance hierarchies constitutes a poor design or "a design smell",
>and whether there are alternatives or design patterns that can be
>applied to improve it.

Try to be sure that your program is free from errors and
maintainable (readable). It can still contain a number of
what some people might call a »smell«, you don't have to
please everyone. You don't want to do

http://en.wikipedia.org/wiki/Gold_pl...re_engineering)

markspace wrote:
> markspace wrote:
>
> > We'd have to see the whole code base, or a large part of it, to
> > determine any further code smell.
>
>
> Forgot to add: Martin Fowler's Refactoring: Improving the Design of
> Existing Code is a good introduction to refactoring and code smell. If
> you can find your design in his code smell descriptions, then you might
> consider changing the design.

In /Effective Java/, Josh Bloch recommends to prefer composition to inheritance.

OP: You might be in a bad direction with inheritance ("is-a" relationship)
rather than composition ("has-a" relationship). You need to share details.

http://sscce.org/

Hand-waving and vague architectural generalities are all well and good,
but it sounds like your problems are in the details.

--
Lew