wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Design Question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Design Question" Watch "Design Question" New topic
Author

Design Question

Mark Reyes
Ranch Hand

Joined: Jul 09, 2007
Posts: 426
Hi All,

I want to ask some advice on how to go about with my design of my system.

I am creating a SpareParts Management System that includes transactions related to borrowing
and returning spareparts by a borrowee to the custodian.

Each spareparts has different property. Say a Blade part has thickness, length, size etc.
A screw part has boring_height, headsize etc. Other parts has different properties.

Now, user can perform several similar operation. Say RequestTrans, EditTrans, DeleteTrans
and OpenInventory.

I am thinking of doing a command pattern here.



Say, I create a specific class for RequestBladeTrans like below.



EditBladeTrans like below.


etc. etc. Per each parts I create a class.

Now I am a bit unsure about my design because I think I will end up with so many classes.

I am thinking of a second option, say I create an interface below.



and then have each Transaction implement the interface method



Can you comment on what I have tought so far? Is option 1 better or option 2 or both of them are not..

Sean Clark ---> I love this place!!!
Me ------> I definitely love this place!!!
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Are the transactions themselves dependent on the part being transacted? Or is it a matter of needing different part information for each transaction?

Without really knowing anything about your requirements, I'm not convinced the transactions themselves are part-specific, only that the data needed for the *contents* of the transaction are different.

I could be way off-base, though.
Mark Reyes
Ranch Hand

Joined: Jul 09, 2007
Posts: 426
Hi David,

I think I am getting something from what you are particularly saying.

Are the transactions themselves dependent on the part being transacted? Or is it a matter of needing different part information for each transaction?


I am thinking of below code snippet. (I did not test this, I just type it in)



Right now, there are just some finite number of parts being transacted. Each parts has specific attribute that the user has specified.

So each transaction refers only to specific parts or content. They need to be inserted to DB, can be edited, or deleted.
Since each parts has different attributes, I have decided to represent each parts into one specific table. In each row, I just added
a status flag that represent if the transaction has been serve by the custodian.

Please tell me if you need any more info.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Yeah, I guess I'm still of the opinion that there's a separation between the transaction itself, and the data needed for the transaction.

We might be using the word "transaction" in different senses; I'm using it in the traditional sense of "an atomic interaction with the database", which isn't data-specific.
Mark Reyes
Ranch Hand

Joined: Jul 09, 2007
Posts: 426
Hi,


Yeah, I guess I'm still of the opinion that there's a separation between the transaction itself, and the data needed for the transaction.


can you expand more on what you mean by this? I would like to hear more about your thoughts please.

We might be using the word "transaction" in different senses; I'm using it in the traditional sense of "an atomic interaction with the database", which isn't data-specific.


Allow me please to explain more about this transaction that I am talking about and how I arrived in my initial set of classes.

Here is how the process is happening in chronological order:

1. The borrower approach the custodian place to borrow a part or tool.
2. At the custodian's place, there are different sets of Request form.
One for the Blade Parts, one for the Screw Parts, one for the Clamp Parts etc.
Each specific request form contains entries specific only to the requested parts.
Say the Blade Request Form has entry for Blade Thickness, Length , Size and other Blade specific properties.
This is the same also for the other request form

The borrower needs to get the correct request form for the parts that he wants to borrow.

3. After getting the right request form, he/she should fill it up and then submit to the
custodian

4. Upon receipt of the custodian, the custodian checks the request form. If everything is correct, he/she will tag the request form as SERVE and file it. Hands down the Parts/Tools to the borrower.

5. Now, If the custodian sees that something is wrong with the request form. He/She will return
it to the borrower for editing.

Basically, I am not thinking of the Database Transaction yet as I am still at the modelling stage.

Also, I started out with Behavior of the system first so I created an abstraction regarding the transaction class.

Please criticize my design and I would not be offended if somebody may say that my design sucks. I am more than willing to hear your comments.
Mark Reyes
Ranch Hand

Joined: Jul 09, 2007
Posts: 426
any idea please??
Sebastian Oliver
Greenhorn

Joined: Nov 19, 2008
Posts: 4
Hi Mark,

First you have to determine the roles the objects will play. So for the borrowing context we have a Borrower, a Lender, and the items being borrowed. Somehow we have to name a Sparepart giving a more specific name according to the context that it's playing in, that's a Sparepart available for being borrowed.
You can start from here:



where SparepartBorrower and SparepartLender are interfaces so differente plugged in implementations can determine borrowing feasibility. You will have the CustodianSparepartLender implementing the SparepartLender interface and applying its own lending policies.
Somehow you need to first get the specific SparePart and bind it to the Role SparepartBorrowing (shoot a better name than that! in order to run the borrowing use case.
You can get the Sparepart instance through some SparepartSpec object specifying part size, etc.

SparePart = SparepartRepository.get(SparepartSpec);
SparepartBorrowing = DomainRoles.bind(Sparepart).as(SparepartBorrowing);
Borrower...
Lender...
SparepartBorrowing.borrow(Borrower, Lender);

Mark Reyes
Ranch Hand

Joined: Jul 09, 2007
Posts: 426
Hi Sebatian,

Thanks for taking a second look at my post.

Can I ask about this.

First you have to determine the roles the objects will play. So for the borrowing context we have a Borrower, a Lender, and the items being borrowed



I would like to know more about how to determine the roles of the classes that I am making.

In my initial design, I started out with the behavior of the system so I was'nt able to determine yet that I need a Borrower and a Lender Class.
But I would like to know more about your thoughts.

Somehow, I got some idea on the SparePartSpec class.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Design Question
 
Similar Threads
Domain Model First or Use Case
Clarification wanted: Extending Threads vs. Implementing Runnable
NX: URLy Bird 1.3.1 Connection Factory Design
What is dependency injection?
Factory Patter and Abstract Factory Pattern