oo design questions
Hello
I am trying to sketch out a OO design for this small app with a User Interface.If you guys and gals could offer some comments to the options presented...
This example program will have a UI that will show a list of "produtcs". "Product" is a class and all "product" objects are saved in an array. They are loaded from the database. Then when each product is clicked it's detail information will appear on another part of the UI.
class UserInterface
draws the Swing stuff
has a listProducts method that receives an array and adds it to a JList component
example:
listProducts ( Product[] listOfProducts )
class Product
holds data for each product
Since PRODUCT represents one product, should I create a "holder" class that has a method called getProductList ?
Example
public class Library {
Product[] productList;
DB databaseConnection;
public getProductList () {
String query = "Select * from Products" );
// now some code to send this SQL to a database querying method
// in another class
// and receive a list of products in the Product array
databasEConnection.queryDB ( query, Product[] );
}
}
Also,
Where should the main method go? Inside it's own class, that will create an UserInterface object to run things?
That class could also start a DB and Library objects, load the list and feed it to the UserInterface class.
Would this work properly as far as Interface / Logic separation ?
Thanks.
[1590 byte] By [
WillTrya] at [2007-10-2 0:40:38]
> Hello
>
> I am trying to sketch out a OO design for this small
> app with a User Interface.If you guys and gals
> could offer some comments to the options
> presented...
>
> This example program will have a UI that will show a
> list of "produtcs". "Product" is a class and all
> "product" objects are saved in an array.
Product should be an individual product. It should not an array of Product objects, if that's what you mean.
That's your business object. Put it in a model package.
> They are loaded from the database.
Then you should have a ProductDAO interface that does CRUD operations for Product.
That's your persistence layer. Put it in a persistence package.
> Then when each product is
> clicked it's detail information will appear on
> another part of the UI.
I'd say you should have a ProductPanel and a ProductDetailPanel in your Swing UI. The first displays all Products; the second displays detailed information.
That's your view layer. Put it in a package view.
> class UserInterface
> draws the Swing stuff
> has a listProducts method that receives an array and
> adds it to a JList component
>
> example:
>
> listProducts ( Product[] listOfProducts )
Why array? Why not java.util.List?
>
> class Product
> holds data for each product
No, just for one product.
>
> Since PRODUCT represents one product, should I
> create a "holder" class that has a method called
> getProductList ?
No.
>
> Example
>
> public class Library {
>
>Product[] productList;
>DB databaseConnection;
>
>public getProductList () {
>String query = "Select * from Products" );
> // now some code to send this SQL to a
> QL to a database querying method
>// in another class
> // and receive a list of products in the
> in the Product array
> databasEConnection.queryDB ( query,
> ( query, Product[] );
>}
>
>
> }
>
> Also,
> Where should the main method go? Inside it's own
> class, that will create an UserInterface object to
> run things?
You need a controller app that knows about all the other layers.
Maybe there's a separate app class that will have main, instantiate the controller, and kick the whole thing off.
> Would this work properly as far as Interface / Logic separation ?
I don't think you're quite there, but you're close.
%
> > This example program will have a UI that will show
> a
> > list of "produtcs". "Product" is a class and all
> > "product" objects are saved in an array.
>
> Product should be an individual product. It should
> not an array of Product objects, if that's what you
> mean.
>
Sorry I didn't meant to say that the Product class would have an array with the list of products. That array is going somewhere else and will have several Products.
> >
> > listProducts ( Product[] listOfProducts )
>
> Why array? Why not java.util.List?
>
That was just an example. Anyway it's possible that the array doesn't grow:
when a new record is inserted the program just reloads the hole record list again from the DB (so a new array is going to the listing function). Still considering - altough this should probably be avoided so the program doesn't spend un-necessary time retrieving the data that it already has).
> >
> > class Product
> > holds data for each product
>
> No, just for one product.
the idea was
Product object = one product
so the programm has a Product object for each product.
The idea of the "Library" class was to have a way to store multiple Product objects (hence that product Library or catalog would store the product array).
>
> >
> You need a controller app that knows about all the
> other layers.
>
> Maybe there's a separate app class that will have
> main, instantiate the controller, and kick the whole
> thing off.
>
Thanks. Will work some more on this thing.
Other comments are welcome.
Hello,
some questions regarding your comments.
>
>
> > They are loaded from the database.
>
> Then you should have a ProductDAO interface that
> does CRUD operations for Product.
>
> That's your persistence layer. Put it in a
> persistence package.
>
SO that ProductDAO (interface) would include stuff like
public void insertProduct ( Product detail );
public Product getProduct ( int code );
public void deleteProduct (int code);
and so on?
And each of those would be implemented in classes like (example) ProductDAODerby (for Derby database) or ProductDAOText ?
public class ProductDAODerby implements ProductDAO {
public void insertProduct ( Product detail ) {
// create sql using product data
String query = "insert into product (title) values ('" + detail.name + "')" ;
execute ( query );
}
}
What about connect and clsoe methods? Should they get inside this ProductDAO interface or in another class - that handles connections and has helper methods for sending SQL to the database?
Thanks.
>
> SO that ProductDAO (interface) would include stuff
> like
>
> public void insertProduct ( Product detail );
> public Product getProduct ( int code );
> public void deleteProduct (int code);
>
> and so on?
>
Well yes and no. yes it will probably mimmic the business interface to some small degree, but it shouldn't be thought of as one to one. in the DAO you will have many private methods that have to manage transactions and reading resultsets into arrays or loading them into classes and whatnot.
For instance, the first thing you do inside insertProduce in the DAO will probably be to check if the datasource is open or not.
> >
> Well yes and no. yes it will probably mimmic the
> business interface to some small degree, but it
> shouldn't be thought of as one to one. in the DAO
> you will have many private methods that have to
> manage transactions and reading resultsets into
> arrays or loading them into classes and whatnot.
>
> For instance, the first thing you do inside
> insertProduce in the DAO will probably be to check if
> the datasource is open or not.
Hello
well , what about having another class that just handles database related stuff - create connection, create sql for select/insert/update with parameters, close connection, and others. The point is having a simpler DAO database object (without code to translate RM to objects) and a more general class that other projects can use.
Example for that new class
public ArrayList getRowList ( int table, int columns );
public Connection ConnectDB ();
public void closeConnection();
Then the ProductDAODatabase would create an instance of that class and use it's methods when needed.
public class ProductDAODatabase {
Database dataSource = new Database();
public ArrayList getProducts () {
return getRowList ( "productlist", 3);
}
}
What do you think?
Thanks
public ArrayList getRowList ( int table, int columns ); That should go as String table, of course.
