Re: sale.submit() or submitter.submit(sale)

On 27 jan, 17:24, greatlor...@xxxxxxxxxxx wrote:

1. If the sale object has a submit operation, the hierarchy is this:
Sale class -----> base class
... OTCSale
... WebSale
... PhoneSale ---------------> 3 sale classes that derive from base
Sale one.

The base Sale class will have a submit operation which is overriden in
each child sale class.
Thus, OTCSale.Submit(), WebSale.Submit(), etc.

2. If there is a separate Submitter class, then in addition to the
hierarchy in case 1(except submit operation), I need to have an
overloaded Submit operation in that class.
Thus, Submitter.Submit(OTCSale), Submitter.Submit(WebSale), etc.

I'm suspecting that the submitter is not the object you want to use
but it will give you an idea, you can create the following table:

Submitter/Sale | PhoneSale | WebSale | OTCSale |
---------------------------------------------------------------------------
Submitter | submit() | submit() | submit()
---------------------------------------------------------------------------

With this table you can decide the following, example 1:

PhoneSale:
submit(Submitter submitter)
WebSale:
submit(Submitter submitter)
OTCSale
submit(Submitter submitter)

Or the other way around (example 2)

Submitter:
submit(PhoneSale phoneSale)
submit(WebSale webSale)
submit(OTCSale otcSale)

In the first example it is easy if you want to add an extra sale, you
create a class for the new sale and implement the submit method. In
the second example it is harder to add a new sale. You will need to
add a method to submit the sale to every implementation of the
submitter. In your case if the submitter is the only one, it doesn't
make a real difference. But making such a table can help you decide
how the implement the objects.

HTH,
N.






.