Where Does the Code Go?

[Rv5]

I have a good programming practice question. Just for fun, Ive taken on a
side project that will help a teacher friend of mine work out grades. I
want a GUI interface that will store and retrieve grading info. So Im
hoping someonecan walk me through my class structure. My biggest question
regards whether or not it is good programming practice to have data objects
as members of my GUI class or if it should be done another way? I have my
main class which calls the GUI class. For now in my most basic skeleton, I
have a very simple student class, contains has a grade class. How should
these classes be arranged?

My first thought was have student a member of the GUI class. Say I have a
form with nothing more then two text fields for name and grade, and a
button. When I click the button, I want to store the the textfield data in
the student/grade classes. I can do that fine if student is a member of the
GUI class, but for some reason Im uncomfortable with this design. It seems
the GUI should be design only, no data access code in there. Eventually I
want to add database connection objects to this model for permanent student
data storage and would need to know where those would be called from as
well. So what do you guys think?

Classes:
Main
Gui
Student -> Grade
How to arrange?


Thanks
Rv5

 

[Missaka Wijekoon]

my thoughts only,

The GUI is intepretation of data.
The student related classes should be data centric.
In other words data and presentation should be seperated (kind of like
the way xhtml/xml and css are evolving.)

I have a good programming practice question. Just for fun, Ive taken on a
side project that will help a teacher friend of mine work out grades. I
want a GUI interface that will store and retrieve grading info. So Im
hoping someonecan walk me through my class structure. My biggest question
regards whether or not it is good programming practice to have data objects
as members of my GUI class or if it should be done another way? I have my
main class which calls the GUI class. For now in my most basic skeleton, I
have a very simple student class, contains has a grade class. How should
these classes be arranged?

My first thought was have student a member of the GUI class. Say I have a
form with nothing more then two text fields for name and grade, and a
button. When I click the button, I want to store the the textfield data in
the student/grade classes. I can do that fine if student is a member of the
GUI class, but for some reason Im uncomfortable with this design. It seems
the GUI should be design only, no data access code in there. Eventually I
want to add database connection objects to this model for permanent student
data storage and would need to know where those would be called from as
well. So what do you guys think?

Classes:
Main
Gui
Student -> Grade
How to arrange?


Thanks
Rv5

--
========================================================================
Missaka Wijekoon (a.k.a. Misk) (e-mail address removed)
Sr. Software Engineer http://www.villageEdocs.com
VillageEdocs
========================================================================

 

[jhking]

Like Missaka said, separate your data and presentation. When you build
the web version of this, or need to store the grades in an excel
spreadsheet you'll be glad you did.
Another way to look at things is that class descendants should follow
the 'is-a' rule. Car 'is-a' Vehicle, so a Car class is a descendant of
Vehicle, Porsche 'is-a' Car so Porsche is a descendant of Car. Another
rule is 'has-a' and that implies the object of 'has-a' is a member
variable. Vehicle 'has-a' Motor so Motor and Vehicle are not
ancestor/descendant, the Vehicle class has an attribute of Motor (I'm
ignoring the more complicated cases of bicycle (no motor) and Airbus Jet
(multiple motors) but you get the idea.
As Student 'is-a' Gui doesn't apply and Gui 'is-a' Student doesn't apply
neither should be a descendant of the other.
This also applies to Student and Grade Student 'has-a' Grade, not
Student 'is-a' Grade (or vice versa).

 

[Scott Ellsworth]

I have a good programming practice question. Just for fun, Ive taken on a
side project that will help a teacher friend of mine work out grades. I
want a GUI interface that will store and retrieve grading info. So Im
hoping someonecan walk me through my class structure. My biggest question
regards whether or not it is good programming practice to have data objects
as members of my GUI class or if it should be done another way?

I tend to go with Model-view-controller most of the time.

The model is the pure data, such as Student, Grade, Classroom classes,
plus whatever contains them. There are accessors to add students to a
classroom, and grades to a student. There also getters to get the data
back out. For example, the model might have methods like
"createStudent(String name)", "getStudent(String name)", and so forth.

The view might consist of a DisplayStudent window and a DisplayClassroom
window.

The controller knows of them both, and each knows of the controller.
The controller is told by the model when underlying data has changed,
and tells the view windows to update in return. Similarly, when someone
tweedles a field in the view, it is sent to the controller to pass on to
the model.

Your Main class would instantiate a controller, and then it might create
the DisplayStudent window and underlying Model, which is then passed to
the controller. You could also have the controller create both the
views and the models - both designs work.

This is almost certainly overkill for a quickie project like this, but
if you move towards a database, or a more fully featured app with more
than just one text field, then the added flexibility will help.

Scott

 

[Rv5]

Ok thats a good example that I understand. Perhaps Ill need to do more
research, but if the GUI is a standalone class, how do I get the data from
the text fields to the student class when the button is clicked if the GUI
doesnt have a student object?

 

[Jon A. Cruz]

I tend to go with Model-view-controller most of the time.

I prefer the more Java-style Model-View/Controller approach (where view
and controller are merged to a single entity).

The model is the pure data, such as Student, Grade, Classroom classes,

Yes. I like that also

For example, the model might have methods like
"createStudent(String name)", "getStudent(String name)", and so forth.

This is where I'd go a little farther.

'name' being a plain String is probably limited. A name is a complex
thing with different parts. So instead of passing it as a single
monolithic String and parsing it back all over the place, I'd suggest a
'Name' class that does intelligent things with names.

That way you avoid problems with "Cruz, Jon", "Jon Cruz", "Jon A. Cruz",
etc.

The controller knows of them both, and each knows of the controller.

This, in general, seems a bit off.

Usually a view knows only of a Model. The model class only knows of
object that have chosen to be notified of the model's updated, not of
specific view or controller classes.

Or I think we might be thinking of it the same, but describing it
differently.

To clarify: In the sense of "knowing", the model class only "knows" of
those who implement the model's listener interface and have registered
it. It knows nothing else of those classes. And it does not "know" of
views nor controllers in the sense that the model class does not import
any view or controller classes, nor should it probably even be in the
same package.

The controller is told by the model when underlying data has changed,
and tells the view windows to update in return.

Actually, the windows *are* the views (in the general use of the term)

Similarly, when someone
tweedles a field in the view, it is sent to the controller to pass on to
the model.

And this is where I think a lot breaks down. Usually a "view" has no
fields, and a "controller" would be a widget that does the tweedling and
updates the model directly.

Views only reflect what state in the model is, controllers tweak the model.

A controller takes user input then tweaks the model. The model then
notifies listeners that it has changed. The views receive these
notifications from the model, then query the model and update their
appearance.

Your Main class would instantiate a controller, and then it might create
the DisplayStudent window and underlying Model, which is then passed to
the controller. You could also have the controller create both the
views and the models - both designs work.

This, also, is where I would disagree.

I'd think the Main class would instantiate a Model, then create a
View/Controller of that Model. For any non-trivial application, a few
models and a vew view/controllers for each would probably be made.

This is almost certainly overkill for a quickie project like this

Again, I would disagree here. I'd say that a basic Model -
View/Controller separation would help just about any application.

Yes, it might take a bit longer before you saw the first things on the
screen, but usually the time to functional stage would be shorter.

 

[Jon A. Cruz]

My biggest question
regards whether or not it is good programming practice to have data objects
as members of my GUI class or if it should be done another way?

Probably not good practice to mix GUI and Data. At least not like that.

I have my
main class which calls the GUI class. For now in my most basic skeleton, I
have a very simple student class, contains has a grade class. How should
these classes be arranged?

I'd say maybe the following classes might help

Person
Student
Grade
Teacher
Class

Make those all pure data classes (Models)

Teacher and Student inherit from Person. Person has a name. I had
mentioned name before, and I think Person might be good to centralize
standardizing and looking up names.

Student could have a member that lists the student's classes. It could
also have a member that lists the grades for each class. One way would
be a Vector member to list Classes, and Hashtable for grades that could
use something from Class as a key.

My first thought was have student a member of the GUI class. Say I have a
form with nothing more then two text fields for name and grade, and a
button.

Change your thinking.



Think of the data Model classes as the bones and muscle of your program.
And the GUI classes are the skin. Start by first thinking about the
abstract data and functionality. Then think of how to show it. Build the
muscle and bone, and then hang the skin on after.

 

[Jon A. Cruz]

Ok thats a good example that I understand. Perhaps Ill need to do more
research, but if the GUI is a standalone class, how do I get the data from
the text fields to the student class when the button is clicked if the GUI
doesnt have a student object?

No:

public class StudentView extends JPanel
{
Hashtable grades;
String name;
Vector classList;

public StudentView()
{
grades = new Hashtable();
classList = new Vector();
....


Yes:

public class StudentView extends JPanel
{
Student student;
...

public StudentView( Student student )
{
this.student = student;
// Add a listener to student, etc.
...

}

....

Does that give you a hint for starting?

 

[Rv5]

Yes, that will get me started. Very good, thank you.

 

[Patrick B. Haggood]

I tend to go with Model-view-controller most of the time.

The model is the pure data, such as Student, Grade, Classroom classes,
plus whatever contains them. There are accessors to add students to a
classroom, and grades to a student. There also getters to get the data
back out. For example, the model might have methods like
"createStudent(String name)", "getStudent(String name)", and so forth.

Unless you abscribe to the belief that such accessors are evil:

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

( jury for me is still out on this one, but it does give me much to think
about).

 

[Chris Uppal]

My biggest question
regards whether or not it is good programming practice to have data
objects as members of my GUI class or if it should be done another way?

Just to add to what everyone else has said.

One rule of thumb for whether you have achieved a clean separation of concerns
is whether you can test the bits independently of each other.

In this case, I'd hope (if I were writing this) to be able to test my classes
that represent Students, etc, without having to write most of the GUI first.

In a more complicated project I'd also want to be able to the test the GUI
without having to write the final versions of the Student, etc, classes.

-- chris

 

[Scott Ellsworth]

Unless you abscribe to the belief that such accessors are evil:

That is a bit more radical an OO position than I usually take. Worth a
read, since there are times you want to break exposing your internal
implementation that way.

That said, if "what it means to be a Shape" is to have a center Point
and a float Area, then accessors for those make sense regardless of how
I architect the guts of it.

Scott
Java, Cocoa, WebObjects and Database consulting

 

[Scott Ellsworth]

Scott Ellsworth wrote: [...]

Similarly, when someone
tweedles a field in the view, it is sent to the controller to pass on to
the model.

And this is where I think a lot breaks down. Usually a "view" has no
fields, and a "controller" would be a widget that does the tweedling and
updates the model directly.

Fields in the TextField sense, not the "String name" sense.

Views only reflect what state in the model is, controllers tweak the model.

A controller takes user input then tweaks the model. The model then
notifies listeners that it has changed. The views receive these
notifications from the model, then query the model and update their
appearance.

'Zactly, with the combined controller/view approach you favor.

If you have the controller as a seperate beast, then it is notified by
the model that changes have taken place, which it notifies views of,
which then query the controller for needed info, which query the model
in turn. Similarly, when views have a change to push to the model, they
push it to the controller, which forwards as needed.

The extra complexity of having the controller as a broker pays off when
the model and the views begin to drift apart in functionality. The
controller becomes the adapter between the two interfaces. This can
also be accomplished with strategies and the like, and should be if the
controller starts to become a hydra of code.

Scott
Java, Cocoa, WebObjects and Database consulting

 

[Chris Uppal]

Unless you abscribe to the belief that such accessors are evil:

That is a bit more radical an OO position than I usually take. [...]

That said, if "what it means to be a Shape" is to have a center Point
and a float Area, then accessors for those make sense regardless of how
I architect the guts of it.

I think the idea is that accessors are conceived of as being a way of
reading/setting the value of an internal value. The example methods you cite
may be *implemented* that way, but there is nothing in the public contract of
the Shape object that means they have to be implemented that way. If the
methods are conceived as ways of passing information to or from an object then
they are not (by normal definitiion) "accessors" -- even if the Shape does
cache its area in an instance variable.

Which means that, oddly enough, you can't tell whether a method is "evil"
(assuming you subscribe to the view -- as I do) just by looking at the code!
It's the mindset of the designer that may be "evil", not the way the method is
implemented....

-- chris