Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #15485 > unrolled thread

object oriented design question in context of Java program

Back to article view | Back to comp.lang.java.programmer

Contents

  object oriented design question in context of Java program J W <jjw101023@gmail.com> - 2012-06-21 04:42 -0700
    Re: object oriented design question in context of Java program markspace <-@.> - 2012-06-21 07:20 -0700
      Re: object oriented design question in context of Java program markspace <-@.> - 2012-06-21 08:06 -0700
        Re: object oriented design question in context of Java program Lew <lewbloch@gmail.com> - 2012-06-21 11:33 -0700

#15485 — object oriented design question in context of Java program

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

[toc] | [next] | [standalone]

#15488

On 6/21/2012 4:42 AM, J W wrote:

> 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.


The general idea seems fine.  However, the "other similar but separate" 
classes does bother me a bit.  It depends on how repetitious and how 
confusing (or clear) the result is.

Your basic plan is to avoid any switch-case statements or if-else 
cascades selecting different hierarchies, or different members of the 
same hierarchy.  You want to use a single method call, like

   stage.workPlan( item );

rather than a bunch of if-else statements selecting different work plans 
based on the type of item.  If you can avoid switch-case or if-else, and 
the break-down of responsibilities is clear and loosely coupled, I don't 
think you'll have much code smell.  Complexity is OK as long as its 
required:  complex problems require complex code to satisfy their 
requirements.

Mostly code smell depends on unnecessary complexity, so depending on how 
rough the code is will affect the amount of code smell.  By itself, a 
few class hierarchies aren't code smell.  The devil of course could be 
in the details.

We'd have to see the whole code base, or a large part of it, to 
determine any further code smell.  Short examples won't cut it because 
short examples will be short, and therefore won't smell.  I think you 
should ask your co-workers for advice.  Or heed their subtle hints; 
sometimes unspoken advice is the more important.

[toc] | [prev] | [next] | [standalone]

#15489

On 6/21/2012 7:20 AM, 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.

[toc] | [prev] | [next] | [standalone]

#15491

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web