Design Question

[mark reyes]

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.

 public interface Transaction {
	public void execute();
}   

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

 public class RequestBladeTrans implements Transaction{
	public void execute() {	
	}
}   

EditBladeTrans like below.

  public class EditBladeTrans implements Transaction{
	public void execute() {
	}
}  

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.

   public interface CommonTransaction {
	public void requestTrans();
	public int editTrans();
	public int deleteTrans();
	public void openInventory();
} 

and then have each Transaction implement the interface method

  public class BladeTransaction implements CommonTransaction{
	public int deleteTrans() {
		return 0;
	}
	public int editTrans() {
		return 0;
	}
	public void openInventory() {
	}
	public void requestTrans() {
	}
}  

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

[David Newton]

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]

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)

 public class RequestBladeTrans implements Transaction{
	private double thickness;
	private double length;
	private double size;
	
	public RequestBladeTrans(double thickness, double length, double size){
		this.thickness = thickness;
		this.length = length;
		this.size = size;
	}
	
	public void execute() {
		//validation logic here
		
		TransactionDB db = TransactionDB();
		//insert data to DB Trans
		db.insertTrans(thickness, length, size);
	}
	
	public static void main(String[] args) {
		double thickness =0;
		double length = 0;
		double size = 0;
		
		//set the value from maybe a GUI Source??
		
		RequestBladeTrans bladeRequest = new RequestBladeTrans(thickness, length, size);
		bladeRequest.execute();
	}
}   

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]

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]

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]

any idea please??

[Sebastian Oliver]

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:

  
class SparepartBorrowing {

borrow(SparepartBorrower, SparepartLender) {
SparepartLender.checkSparepartLending(this);
SparepartBorrower.checkSparepartBorrowing(this);

SparepartLender.lend(this);
SparepartBorrower.takeBorrowed(this);
}

}

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]

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.