This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I am working on a email webapp. Please take a look at the code below followed by explanation/question:
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?
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.
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.
Joined: Sep 07, 2008
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.
Joined: Apr 16, 2008
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.
Joined: Sep 07, 2008
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 ?