• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Where do I put bus. logic for GUI class?

 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm new to OOP, and everything I read says to keep all of my classes small if possible. I'm setting up a data entry screen that have a large number of fields and writes to one table in the database. This one screen is quite isolated so there is not much intermingling with the rest of the application. I am unsure how to design the classes. Here are the possibilities that I have come up with... please advise me on which is the best or if I need to do something totally different.
Possibility 1: Just design the one GUI class to handle the data entry and one class to store the data from the screen. When the user clicks the 'submit' button on the screen, the GUI class sends a message to the other class and then the other class writes the information to the database.
Possibility 2: Forego the second class. When the user clicks the 'submit' button on the screen, the GUI class gathers up all of the data needed to write to the table and writes the record to the database.
Possibility 3: Break the data from the screen into chunks and make classes that represent these chunks. Each chunk would store the data for its section of the screen. (This breaking the screen data into chunks and making classes out of them seems like a very arbitrary way to do this!)
HELP!!!
 
Trailboss
Posts: 23773
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The first technique sounds like the best.
As for making classes small - I don't think this is a general rule. A class that is too big can sometimes indicate poor OO, but not always.
 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This problem was conceptually addressed in Smalltalk's Model-View-Controller (MVC). If you are not familiar with it, you might look into a detailed description of it. It essentially advocates the break down of class responsibilities so that you don't have business objects (the Model part) worrying about how to present (the View part) themselves.
In terms of a Java implementation, you would probably put your business objects into a separate package than the package(s) that contain your GUI (View and probably Controller) classes. That is certainly your scenario #1.
However, if you have data from that form where some is a logical fit for relating to other pieces of data on the form, but not all, you may find it easiest (and more appropriately a better OO model fit for that data and its behavior), to break that up into individual classes as well.
Hope this helps.
 
James Beeson
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So you're saying I should:
1) put my business logic and the GUI code in a seperate classes. I get that-good.
2) Try breaking down the elements from the screen that seem to be related into groups. Ok, I understand that but what do I do with the fields that are not related to anything else. Just cutting the screen into chunks just to make the class that stores the data seems arbitrary...
Should I group the fields that can be grouped together into thier own classes and make up a hodge-podge class that stores the rest of the fields from the screen? Thanks.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, let's consider an example. Say you're storing and displaying info on employees. For a given employee, you want to display all the info you have on him/her. So you create an Employee class which ultimately contains everything you need. However, within that class, you might have a reference to an Address object which contains street number, street name, apartment number, city, state, zip, etc. And another class for PayrollInfo, containing salary, tax withholding info from the W-2 form, accumulated vacation days, etc. And then you might have other miscellaneous info, like birthday, office number, hair color, whatever, which does not logically group with any of the other data except that it relates to the Employee. So, I'd just make these extra fields in the master Employee class. Alternately, you could create a Miscellaneous class which Employee contains an instance of - but I don't really see the need.
 
James Beeson
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That was very helpful! But I have another question. Given the code example in the previous post, how would I validate the char[2] stateCode attribute. Let me explain. If I have a GUI class that I am using to update an employee object, and I want to make sure that the user enters a valid state... where would I put the code and the list of valid states. I can only see two ways:
First, I could store a valid list of states (or at least a means to create a valid list of states) within the Address class and a method to compare the value the user enters on the screen with the valid list of states in my address object within my employee object. Or.... I could store a valid list of states (or at least a means to create a valid list of states) within the GUI class. In addition, I would put a method to compare the value the user enters on the screen with the valid list of states being stored in my GUI class.
My question boils down to this:
Given the code in the post above, where would I put code to validate the stateCode attribute of the address object? Should the valid list of states and the code to validate the user�s input be in the screen or should these items be in the Address class?
Thank you very much!
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmmm... there are several possibilities. The one I like best offhand it to put the list of valid values in the Address class - let's switch that char[2] representation to String for simplicity:
<code><pre>class Address {
...
public static final String[] validStates = {"AB", "AL", "AZ", ...};
public String state;
...
}</pre></code>
And then in the GUI, use a JList created thus:
<code><pre> JList stateField = new JList(Address.validStates);</pre></code>
It will populate the list of possible values using your list. The user will not be able to select any value other than a valid value, so no further validation should be necessary. Later you can retrieve the state string from within the GUI code using
<code><pre> address.state = (String)stateField.getSelectedValue();</pre></code>
Of course, there are lots of other things to figure out when you start using Swing . But many of the components are designed for easy separation of the data from the GUI view of it (MVC paradigm).
For the more general problem, if you can't find a simple way to design the GUI so that invalid choices are impossible, then I'd recommend giving your data classes methods which can determine if a given input is valid, so that the GUI code can call these methods when deciding whether to accept a value. Say that you want to make sure the zip code is valid for the city & state combination selected. This may be a fairly elaborate bit of code, and it's logically associated with the data, not with the GUI. GUI code can be ugly enough without unrelated stuff cluttering it up. So put a method in Address:
<code><pre> public boolean isValidZip(int zip) {
// complex code which accesses this.state and this.city
// (which must have already been set)
}</pre></code>
or
<code><pre> public static boolean isValidZipCombo(String state, String city, int zip) {
// complex code using all three variables passed
}</pre></code>
Then your GUI validation code can be relatively simple looking:
<code><pre> int zipCandidate = zipField.getValue();
if (address.isValidZip(zipCandidate)) {
address.setZip(zipCandidate);
} else {
zipField.clear();
showMessage("Hey schmuck, your zip code didn't work. ");
}
</pre></code>
That's my opinion, anyway.
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One thing to beware of here. While making an invalid input impossible is a nice way of designing a UI, you should only use it if you are really sure that you know the requirements. Validating states and zip codes is a typical situation where your assumptions can trip you up.
I am continually bumping into input forms designed assuming a solely USA market, but pressed into service for a wider audience. Canada is just next door, for example. Are you 100% sure that you will never need to enter a Canadian address? Can you easily add the list of Canadian provinces to your list of states (ideally with no recompilation)? Canadian postcodes contain letters as well as numbers; can you allow that input in your "zip" field? And that's just Canada. Here in England we don't have states, but the county is a vital part of the address. Our postcodes also contain both letters and numbers (in a different format to canadian postcodes). Our phone numbers have varying numbers of digits, and don't conform to the USA 3-3-4 groups. And so on, And so on. I tried three banks in the USA before I found one that could open a bank account for me. The one without the address validation got my business...
The bottom line is: THINK VERY HARD before you build specific types of address and validation into your object model. Even if you only need USA addresses now, you could need Canadian addresses next week, or World-wide addresses next month.
 
James Beeson
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I work for a state agency in Texas that only servers Texas, but putting that aside my example of verifying a state was just that.
I would like to thank you all very much. Your responses have helped solve several very critical issues as my team and I design our first large (for us) scale application.
Thanks again!!
James
 
I didn't like the taste of tongue and it didn't like the taste of me. I will now try this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic