How Do I Avoid using Running Totals in My Code?

I am learning programing and software design and Java in school right now. The class that is getting me mixed up is Software Design. We are using Word to run simple VB code to do simple programs. My instructor says I am losing cohesion by using running totals. I am having a hard time thinking of a way to avoid them. Here is an example of some pseudocode I am talking about (the modules are called form a driver module that is not shown):

CaluculateDiscountPrice module
    DiscountPrice = (FloorPrice * (1 – DiscountRate))
End module

CalculateDeliveryPrice module
    If DeliveryFee = “Yes” Then
        DeliveryPrice = DiscountPrice + 20  
    ElseIf DeliveryFee = “No” Then
        DeliveryPrice = DiscountPrice
    End If
End module

CalculateT开发者_如何学PythonradeInCredit module
    If TradeInCredit = “Yes” Then
        CreditedPrice = DeliveryPrice – 5
    ElseIf TradeInCredit = “No” Then
        CreditedPrice = DeliveryPrice
    End If
End module

CaluculateCostOfBed module
    CostOfBed = CreditedPrice
End module

Basically DiscountPrice is used to join the first two modules and then DeliveryPrice the second two. Supposedly, the last module may not even need to be there is I fixed this problem. Any help to the beginner?

When I look at your example, what jumps out at me is a problem with coupling between modules. (If you haven't already studied that concept, you probably soon will.) However, too much coupling and too little cohesion often go together, so hopefully I can still give you a helpful answer. (Oversimplified but adequate-for-here definitions: Cohesive modules do one focused thing instead of several unrelated things, and Coupled modules depend on one another to do whatever it is they do. We usually want modules to have strong cohesion internally but weak coupling to other modules.)

I infer from your pseudocode that you want to calculate the price of a bed like so:

* start with the floor price
* discount it
* add in a delivery fee
* subtract a trade-in credit
* the result is the cost of the bed

When you express it like that, you might notice that those operations are (or can be) pretty independent of each other. For example, the delivery fee doesn't really depend on the discounted price, just on whether or not a delivery fee is to be charged.

Now, the way you've structured your design, your 'DeliveryPrice' variable is really an "as delivered" price that does depend on the discounted price. This is the kind of thing we want to get rid of. We can say that your modules are too tightly coupled because they depend on each other in ways that are not really required to solve the problem. We can say that they lack cohesion because they are really doing more than one thing - i.e. the delivery price module is adding the delivery fee to the discounted price instead of just calculating the delivery fee.

It's hard to see with toy examples, but this matters as designs get more complex. With just a few lines of pseudocode, it seems perfectly natural to have a "running total" threaded between them. But what if the delivery fee depends on a complex calculation involving the distance to the customer's house, the weight of the purchase, and the day of the week? Now, having it also involve whatever the discounted price would get really confusing.

So, with all that in mind, consider this alternate design:

CalculateDeliveryFee module                                  
    If DeliveryFeeCharged = “Yes” Then                                  
        DeliveryFee = 20                                    
    End If                                  
End module                                  

CalculateTradeInCredit module                                  
    If TradeInCreditApplied = “Yes” Then                                  
        TradeInCredit = 5                                  
    End If                                  
End module                                  

CaluculateCostOfBed module 
    DiscountPrice = (FloorPrice * (1 – DiscountRate))  
    AsDeliveredPrice = DiscountPrice + DeliveryFee   
    WithTradeInPrice = AsDeliveredPrice - TradeInCredit                             
    CostOfBed = WithTradeInPrice 
End module                                  

Now, coupling is reduced - the delivery and trade-in modules don't know anything at all about bed prices. This also improves their cohesion, since they are doing something more focused - calculating fees, not summing prices and fees. The actual price calculation does depend on the other modules, but that's inherent in the problem. And the calculation is cohesive - the "one thing" it's doing is calculating the price of the bed!