Software Engineering - design sanity check/advice

Author

design sanity check/advice

GDW

2006-06-26, 10:01 pm

I'm relatively new to "real" object-oriented design/development (i.e.
patterns/refactoring etc.) although I've been working with OOP
languages for quite some time. I've been doing a lot of
reading/research in order to take it to the next level and am
incorporating it into a new project I'm working.

The app is a survey engine developed using Java/Spring/Hibernate.
Surveys contain pages which contain questions (different variations of
multiple choice and essay-type). Surveys exist in 3 distinct phases:
survey design, survey response entry and survey analysis/reporting.
I've started out with a domain model which represents just the design
phase of a survey lifecycle. The classes contain just the information
which needs to be persisted to define the structure/layout of the
components.

e.g.:

public class SurveyDefinition {

private Long id;
private String title;
private String description;
private List pages = new ArrayList();

public abstract class QuestionDefinition {
private Long id;
private Integer questionNumber;
private String prompt;
private boolean answerRequired;
private PageDefinition page;
..
..
..
}

public abstract class MultipleChoiceQuestionDef extends
QuestionDefinition {

private boolean singleAnswer;
private List choices = new ArrayList();
..
..
..
}

This initial design was really just created to get my feet wet with
Hibernate to make sure that I could get all of the ORM
inheritance/polymorphism/association mechanisms working. I have kind
of a vague idea of where I want to take this but I want to make sure
that I'm not too far off base before I get too far into the design.

Does it make sense to have the survey design phase entities (e.g.
SurveyDefinition, PageDefinition, QuestionDefinition etc.) as separate
classes distinct from the survey response entry phase entities (e.g.
Survey, Page, Question etc.)? I'm thinking that the survey response
entry phase entities really are different animals with richer behavior
and that these could be created by passing the definition entities
into a factory/creation class/method.

Are there any (other) strategies/patterns etc. that I might want to
pursue?

Any suggestions/advice/admonitions/coaching/counseling/encouragement
and/or hot stock tips would be greatly appreciated.

Thanks,
Gary

GDW

2006-06-27, 7:02 pm

Nick Malik [Microsoft] wrote:
> sounds like three different 'views' but two 'models' (to use the terms from
> the somewhat dated 'Model-View-Controller' high level pattern).
>
> You have a view that allows surveys to be created. The controller builds
> survey-model data when this view is active. You have a view that presents
> the survey. The controller uses survey-model data to drive the pages and
> collect information into the response-model. You have a very similar view
> that presents the data from the response-model in a reporting interface.

That sums it up well

> I hear you saying "I'm starting with the survey-model... I'll get to the
> response-model later." Correct me if I'm hearing you incorrectly.

correct

> OK, now this is odd...
>
>
> what is a SurveyDefinition? If it is a model, then why does it have a
> 'page' construct in it? Perhaps I'm not understanding, but is the page
> intrinsic to the survey, or is it just a display mechanism? If I was to
> access your survey on my smartphone, would I still get the same number of
> pages? (Gosh, I hope not, although most of the web is completely unusable
> from my phone).

I started out calling it "Survey" but then changed it to
"SurveyDefinition" as I started toying with the idea that the
classes used in the design/definition phase might be different than the
survey model used in the reponse collection phase. After I posted the
question and before I received any replies I changed it (and all child
classes) back and decided to just go with one survey model for both the
design and response phases.

The issue with the Page entity (and other view-related
objects/properties) is actually one I've been pondering.

I'll start with the page issue. I'm basically creating a
much-enhanced new version of an existing ColdFusion survey app. That
app just displays all survey questions all on one page and is quite
unwieldy when surveys have many questions. I needed a mechanism to
break the display up into sections. I guess I could rename Page to
Section to remove any connotations of the entity being view-related. I
could also create a decorator class to group questions into sections
but this seems to unnecessarily complicate the model. I'm guessing
from your smartphone comment that you are discouraging any static
page/section definition and instead are recommending a more dynamic
paging mechanism at the view level to make it device/display
independent (correct?). I had already thought of this as well but the
requirement from the client was that they want the ability to clearly
define individual pages for a survey. Perhaps it would be better to
think of the pages as sections that may (or may not) have some logical
grouping (e.g. instructor ratings, classroom conditions, course content
etc. for a training survey) and then leave it up to the view to decide
how it wants to display them. Any ideas?

A similar issue has to do with various question-related properties.
I've tried to avoid putting any view-related properties in the
various question classes but there are a couple that I have struggled
with. For example, a multiple choice question can be displayed either
vertically or horizontally. I toyed with the idea of creating a
decorator class to capture this property but I realized that this
strategy could lead to having dozens of cryptic one or two column
tables if I got too "decorator-happy" throughout the model. I know
that in a perfect world I would design my model first and not worry
about the effects on the persistence layer but then again we're not
in a perfect world. What's a good strategy to deal with this issue?

> Also, I'm a C# person, not a Java person, and perhaps I'm just missing
> something, but in C#, the ArrayList() construct is not strongly typed. I
> can add any object. When you want a list of objects, it is nearly always
> better to store it in a strongly typed arraylist construct. So, wherever
> you put that list, make it strongly typed.

I agree. The convenience methods for adding to the collections will do
type checking. If I was using Java 5 I could use Generics but we're
using 1.4.

BTW, I'm also coming from the C#/.NET/MS world (MCSD, MCDBA, MCSE).
My colleague who still does .NET always jokes about trying to bring me
back from the dark side (Java).

> OK, so same concern. Why does a question care about what page it is on?

You're probably right. I set up the page to questions association to
be bidirectional when unidirectional will probably suffice. I may have
been thinking about the response collection phase and having the
ability to access getPage().getSurvey().getId() when persisting
responses to individual questions. Since I haven't gotten that far
yet, I'm not sure exactly how that will work. I'm open to
suggestions.

> Look at your design from the standpoint of what you want to DO with it. Do
> you want to be able to say "page.displayYourself()" ? If so, the the page
> object should know what questions are on the page and each question object
> should know how to paint itself. Note that collecting responses is a
> function of displaying a page, and then collecting responses... so it is OK
> to say "page.displayYourself" in the course of constructing the form that
> the user will respond to.

I had thought about this but I decided that for a survey/page/question
to know how to display itself would mean that it was too tightly
coupled to the presentation layer. My plan was to have SpringMVC pass
the model to a JSP (or some other view) which would know how to display
it. Thoughts?

>
> Be careful of your tools. They can make it easy to code, and easy to mess
> up as well. In other words, moving up from a .22 Caliber pistol to an AK47
> doesn't make you a better shot... it just means you have the ability to
> shoot your foot off WITH GUSTO!
>
> In other words, work on the design first. Then fit that into the tools.

Point noted. Again, this exercise was just to get my feet wet using
Hibernate. I could have created an app to catalog my CD collection for
this exercise but I thought it would be more useful to incorporate the
project at hand, even it that meant scrapping most of it because my
model sucked.

> Let me encourage you in a couple of ways:
> 1) Excellent first attempt.
> 2) Please consider reading "Head First Design Patterns" or "Design Patterns
> Explained"
> 3) Remember that much of the real power of OOD comes in the relationships
> between objects, not in the object definitions.

Thanks for the encouragement and not trying to seel me any stock.

I already have Head First Design Patterns, J2EE Design Patterns,
Refactoring to Patterns (Kerievsky), Refactoring (Fowler) as well as
another half-dozen or more Java/J2EE-related books. It's a lot to
get your head around all at one time but I'm getting there.

> Is this reply helpful?

Yes, thank you very much.

GDW

2006-06-27, 7:02 pm

Thanks for the reply Ed.

Ed Kirwan wrote:

> GDW wrote:
>
>
> Hmm, I just can't get my head around this.
[snip]
> My point being: I don't see a different type of Survey in each phase.

Yeah, I went back to my original single Survey model after some
reflection last night. I guess the SurveyDefinition model was just a
phase (ouch!) I was going through trying to sort things out. (see my
response to Nick Malik)

> For what it's worth, whereas, "Survey," and, "Question," seem like good
> classes, "Page," seems a little odd. The first two are inherent to the
> surveys themselves, but, "Page," seems more like a presentation issue; I
> don't think it makes sense to define how many pages a Survey might have
> when thinking up the questions it should offer. On the other hand, I
> could see how something like a QuestionGroup might be a useful subdivision

See my previous reply. I'm definitely open to suggestions.

> How, as a matter of interest, are you going to create Surveys and have
> your clients answer them? Do you have a configuration tool for creating
> them, and a servlet for answering them?

I'm going to use SpringMVC and JSPs or some other view type TBD. I
haven't gotten that far yet; I wanted to design the domain/business
models first.

Thanks again,
Gary

Sponsored Links