The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

OOP Question for you OO Gurus - best way to implement this?

My background is VB3 and not much OOP, however I'm trying to take advantage of the OOP approach in

I'm trying to create a visual control that provides the functionality of  a "matching" type exercise.


We show the user Answers:
A      B      C
they must match them correctly to a Cue:
1    2        3

E.g., user clicks B first.
They see:

A              C
1      2        3

I'm trying to figure out what the most logical way is to organize the data associated with this.

-User Clicks an Answer (A,B, etc.)
-Answer moves to the next "open" Cue( 1, 2, or 3)
-If user Clicks an already-answered Answer then we "unAnswer" it.
  (So if they clicked A and and it was then matched up to #1 and clicked A again, it would move back from #1 to it's original position)

-Visual controls displayed for A, 1, etc.
- Information for each Answer (OriginalPosition, CorrectCuePosition {i.e., which Cue that anwer goes with), Answered (T/F, T=use clicked it and we moved it down to a Cue), AnsweredCorrectly ( assumes Answered=T)
-Information about the "Array" of Answrs and Cues. (NextUnMatchedCue  (this is where the next Answer they click on will be matched to)

OPTION I:  put all the data in each control. 
    + seems more "object oriented" and keeps data with object
    -  couples the visual control with the "behind the scenes logic"  (I think this was always frowned on in classic VB b/c it couples the logic to the UI too closely.
  -very difficult to keep track of the "NextUnMatchedCue" because each individual Control doesn't know about the whole list of Cues and Answers.  (So, I'd have to inform each Control about a whole array that it has "no business knowing about"

OPTION 2 :  Put all "logic" data in an object, one object for each Answer or Cue.
Same pros/cons as #1 but doesn't couple the Visual Control to the 'logic'. I think the gains aren't worth the effort here.

OPTION 3:  Put all the logic into an object that "knows about" the whole list of Answers and Choices
  - This doesn't seem very object oriented
 - We still have to relate each visual control to an element in the array.

Have I missed an option?
Is any method significantly better than the others?
Mr. Analogy {Shrinkwrap µISV since 1995} Send private email
Wednesday, June 21, 2006
> This doesn't seem very object oriented

OO is about structuring behavior in code. Your choice to answer map doesn't really have any behaviour so there's no real reason to take an OO approach. A simple hash will do fine.
son of parnas
Wednesday, June 21, 2006
Ok, 'son.  I didn't understand half of that <grin>.

Which of my options is an "answer map" ?

I'm confused as to how a Hash would work here.
I assume you mean the classic Hash function:
Mr. Analogy {Shrinkwrap µISV since 1995} Send private email
Thursday, June 22, 2006
As described, the whole thing seems like just a single, "simple" GUI control that lets you drag stuff around. That would be your only object, the "Answer/Cue Matcher Control." And the only logic that you separate out is the application logic (such as the part that gets the answers and cues to fill the control with, and the extracts the data from the GUI to check the final results). But if that's all the app does, don't make separate controls out of all the elements in the GUI and all those crazy controls and objects you were thinking of. Keep it simple!
Thursday, June 22, 2006
With GUI's you usually use Model-View-Controller, or MVC.  Wikipedia probably has a good explaination, but basically:

Model- the object(s) that represent the logical data structure.
View- the object(s) that display, the buttons and the sorting.
Controller - Acts as the broker between the Model and View.  Clicking on a button sends something to the controller which in turn updates the Model.  The View then picks up the update and displays it.
Thursday, June 22, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz