wood burning stoves*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Need advice regarding app structure 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 "Need advice regarding app structure" Watch "Need advice regarding app structure" New topic
Author

Need advice regarding app structure

shaf maff
Ranch Hand

Joined: Sep 07, 2008
Posts: 180
Hi Guys

I am working on a email webapp. Please take a look at the code below followed by explanation/question:

Email DTO:
Above is an email class which holds the usual email content. Since this is a special mailing service they will be charged for the email. So I will need extra vars such as amount of recipients, price per recipient, total cost and so on. This is where I am alittle lost. Should I include all these vars into the email class or should I create another class called transaction and place all these vars into that along with the email ID?




.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61092
    
  66

As this has nothing to do with Servlets, or even web apps, I've moved it to a more appropriate location.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
M Kothawade
Greenhorn

Joined: Dec 29, 2008
Posts: 9
I think - creating a Transaction class makes sense which would have all the variables (like cost per recipient etc.) as static and it will also have static methods which will have email object as input and cost as output. Email class can have a variable to store the total cost. email object will invoke the static method of Transaction just before sending the email.
I am thinking Transaction class as a utility here. In future, Transaction class might a subclass of an interface to use a strategy pattern.
Please correct if this design is not correct.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
The Email class should contain variables (fields) that represent data specific to the "email."

A data field for number of recipients seems like it is specific to an "email", so it can go in the Email class.

The data fields for "price per recipient" and "total cost" seem to be specific to the special mailing service and should not be placed in the Email class.

The special mailing service class would have references to the Email object and whatever pricing data object. It can use these to create and process a "transaction."

Aside, in this scenario there is no need to make anything "static." Think objects, not classes.

If the special mailing service will handle hundreds or thousands of "transactions", then it is wrong to think of a "transaction" class as a utility class/object.
shaf maff
Ranch Hand

Joined: Sep 07, 2008
Posts: 180
Thanks for the replies guys, some excellent suggestions. So I would throw the pricing/total calculations into a Price class and just invoke that object to do all the calculations. Now, I want to create another object called 'Credit'. This will allow the user to topup his account with new credit. It speicifies the method of payment, amount of money, transaction date etc. Do you think its a good idea of me integrating the pricing and credit classes into one since both deal with money ? I don't think its a good idea but I like to see what you guys think.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
PricingManager might be a better class name, if it contains business logic to handle calculations. A PricingManager object will handle all things related to pricing and calculating what something costs.

Whatever you come up should be based on business requirements. And these requirements should be based on business rules.

If there are significant amount of business rules related to "credit", then creating a CreditBusinessRule class may make sense.

If there are significant amount of business rules related to "pricing", then creating a PricingRules class may make sense.

The business logic for these two potential classes should not be mixed into a single class.

shaf maff
Ranch Hand

Joined: Sep 07, 2008
Posts: 180
Thanks James.
Well, as for naming, Im using DAO patterns so I want to follow through on the naming for the sake of keeping my files in order. I am alittle confused on what to name it since it will be providing calculations to the MailDAO class but it also has its own Price DTO which it will manipulate to return the pricing/name/id etc to any other class that requests it. So atm its carrying out pricing calculation and returning all available offers. I could create another class called PriceDAO to manipulate the Price DTO and call it from the pricing manager. What do you think ?

The mail pricing also has a start/end date. This allows for us to step up special offers over a set period of time. There is one problem, if a customer purchases a mail, it will display the pricing/offer name on the email, but once the date has expired then it should still be viewable in to emails of the customer who took advantage of that offer but not visible to any new emails the customer makes. My solution to this would be to include an extra variable in the method, if set true then it will return the expired offer. What do you think ?
 
Don't get me started about those stupid light bulbs.
 
subject: Need advice regarding app structure