help me structure my classes oop way
I have a combo box for color which takes it's items from a specific table from database. I don't want it to take items directly from db.
I make a Color class which holds id and name, has public methods like getName, setName and save().
I have also made 2 packages to divide GUI and other classes:
GUI
- window.java
core
Color.java
So now I'm confused. Ofcourse there are lots of different ways but I'd like to know the oop way.
Where do I write the code that gets all colors from database?
I'll make a class that basically is a combobox?
I'll make a new class called Colors that extends Color?
[667 byte] By [
hkirsmana] at [2007-11-27 2:03:30]
What exactly do you need to know? Where are you stuck? What do you have thus far?
Its a model ofcourse...I have combo box that should show all colors in dbI also have Color class.
It sounds like the DAO pattern that we use to get database objects to our jsp's.
See this link: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
It's going to be very complicated code though for a simple app. I think you need to reword your question for exactly what you need. Making general comments like I need this in an OOP format doesn't help much. Too many open ended answers.
I don't want to write "select name from colors" and put the result into combo....Maby do Colors class?And then MyColors class?colorCombo.setModel(new MyColorCombo());?I wang nice and cool code but I'm not sure how
You can't honestly think that you have given a good description of your needs.
> I don't want to write "select name from colors" and
> put the result into combo....
You'll have to write that somewhere though, right?
As mentioned, look at the DAO pattern. Then consider writing an implementation of
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/ComboBoxModel.html
Or mess with an existing one (like DefaultComboBoxModel) to provide the neccessary code for getting elements & sizes and adding/removing listeners (from ListModel) and getting and setting selected items (from ComboBoxModel.
Good Luck
Lee
Oh well... I'll try again First....In real world there are thousands of classes. You don't put them all in 1 directory right?So if I have classes like Color, Colors and MyColorCombo where should they be?
I'm not convinced there needs to be a special combo box model. What's wrong with:HisColor[] colors = ... JComboBox cboColors = new JComboBox(colors);Until something indicates it's insuffient, I wouldn't go around creating extra
I expect you have questions something like this:
1. I can go through the database and create a bunch of Color objects, but then how do I go through them all and build a list box so the user can choose one? (Not a combo box, unless you want to allow the user to create new Color objects.)
2. When the user chooses an entry from the list box, how do I identify which Color object they meant to choose?
And so on. Try to identify your requirements. There is no process like "Sprinkle on OO and bake for 15 minutes", all of your code must come from your requirements.
> I'm not convinced there needs to be a special combo
> box model. What's wrong with:
> > HisColor[] colors = ...
> JComboBox cboColors = new JComboBox(colors);
>
> Until something indicates it's insuffient, I wouldn't
> go around creating extra work.
Yeah, very good point.
> Oh well... I'll try again
>
> First....
>
> In real world there are thousands of classes. You
> don't put them all in 1 directory right?
>
> So if I have classes like Color, Colors and
> MyColorCombo where should they be?
That's a bit better. Depends on what they do.
If Color is a class that sub-classes java.awt.Color (not sure why you would do that, and the description of it does not sound like it is or would be), then it might go in a package like com.colorapp.color.
A class called Colors that is a "collection" of Color classes - if that's what it it, might go in a package perhaps like com.colorapp.utils.
A class like MyColorCombo - if it's a widget, and why do you need to subclass one of those? - might go either in some main class package, or in something like com.colorapp.gui ...
~Bill
> That's a bit better. Depends on what they do.
>
> If Color is a class that sub-classes java.awt.Color
> (not sure why you would do that, and the description
> of it does not sound like it is or would be), then it
> might go in a package like com.colorapp.color.
>
> A class called Colors that is a "collection" of Color
> classes - if that's what it it, might go in a package
> perhaps like com.colorapp.utils.
>
> A class like MyColorCombo - if it's a widget, and why
> do you need to subclass one of those? - might go
> either in some main class package, or in something
> like com.colorapp.gui ...
>
> ~Bill
heh. Color was my bad. Dog would have been better.
You made things clearer.
I thought if ComboBoxDogs extended Dogs, and Dogs extended Dog then they had to make up something like this visually
Dog
Dogs
--ComboBoxDogs
Like package dog, dog.dogs and dog.dogs.comboboxdogs .
> I thought if ComboBoxDogs extended Dogs, and Dogs
> extended Dog then they had to make up something like
> this visually
> Dog
> Dogs
> --ComboBoxDogs
>
> Like package dog, dog.dogs and dog.dogs.comboboxdogs .
You lost me there. That didn't make sense. Dogs is-a Dog?
Second thing...
in my real app I have
speciality.setModel(new javax.swing.DefaultComboBoxModel(new String[] { "Choose", "Teacher", "IT", "Business"}));
Because I want those items to come from database It's going to get ugly If id try to squeese that code there...
So is it possible to do something like that:
speciality.setModel(new MyCombo);
?
> I wang nice and cool codeQuote of the day?
> > I thought if ComboBoxDogs extended Dogs, and Dogs
> > extended Dog then they had to make up something
> like
> > this visually
> > Dog
> > Dogs
> > --ComboBoxDogs
> >
> > Like package dog, dog.dogs and
> dog.dogs.comboboxdogs .
>
> You lost me there. That didn't make sense. Dogs is-a
> Dog?
Well, no :) Dogs is not the same type as Dog... I know it's wrong.
I guess they are on the same level because they are 2 different types?
if class A extends B it doesn't mean A and B are same type right?
> > I wang nice and cool code> > Quote of the day?lol. thank god today was over few minutes ago in my time zone :)
> Well, no :) Dogs is not the same type as Dog... I know it's wrong.>> I guess they are on the same level because they are 2 different types?What were you trying to say? I assume Dogs represents a collection of Dog objects.
> > Well, no :) Dogs is not the same type as Dog... I
> know it's wrong.
> >
> > I guess they are on the same level because they are
> 2 different types?
>
> What were you trying to say? I assume Dogs represents
> a collection of Dog objects.
yeah. class that can get all Dog objects out of database;
Message was edited by:
hkirsman
> > > I wang nice and cool code> > > > Quote of the day?> > lol. thank god today was over few minutes ago in my> time zone :)Really? It's only 5:14 out here.
aha moment?So Dogs dont extend Dogwhy would Dogs need methods like getName, setName and variables like name? Right?
I thought your Dogs looked like this:
public class Dogs {
public Dog[] selectAll() {...}
}
What would be the point of Dogs having methods like set/getName?
> What would be the point of Dogs having methods like> set/getName?Yeah. Heureka moment hit me few minutes backThis kinf of confusion made me start this thread
> > I wang nice and cool code> > Quote of the day?Thanks cap'n that cheered me up!I'm off sick with a bad cold today.
Dogs can extent PaperAirPlane is you like - that is, you could have a class called Dogs that really is a subclass of PaperAirPlane; but you'd confuse everyone if you named them that way.
Point is, you could either have a Dogs class that really does extend the Dog class, but is poorly named as such ... or ... you could have a Dogs class has in no way extends Dog class, and is still poorly named and misleading. Either way it's wrong.
Dog class - for example - is simply a base class for kinds of Dog. If it gets subclassed at all, it should be subclassed by Terrier, Beagle, German Shephard, etc. In turn, it might be logical to have Dog class extend Animal ... or perhaps Mammal.
Like other's have said, if you have a Dogs class, it would probably not be a subclass of anything ... except Object, of course. Rather, it would probably be the name of some kind of Collection, and as such would probably be better named Kennel, Pack, PetShop or something like that ... at least to my mind.
And again, as others have said, there is likely no need to subclass a Collection - just pick the one you like ... ArrayList, HashMap, whatever. IOW,
Collection<Dog> = new ArrayList<Dog>();
... something along that order.
Before when I offered some help with situating packages, I did not mean to imply that I agreed with your setup or ordering of classes, only that if you had valid reason to do it that way, perhaps then you might think to organize then similarly.
~Bill
