RE: [Rails-devel] Certificate ownership

[Erik V. <eri...@hc...>]

> > 2. Each tradeable object would implement an interface Tradeable.
> > This would apply to Certificates and PrivateCompanies.
> > PublicCompanies are not themselves Tradeable, but hold an array
> > of Tradeable Certificates. 
> > Minor companies like those in 1835 will have one 100% Certificate
> > (to avoid the need for a subclass MinorCompany extends PublicCompany
> > implements Tradeable).
> > 
> 
> Hmmm... I see the distinction you're trying to make, but I'm not
> completely certain this is necessary to do it. There doesn't 
> seem to be
> any attributes specific to a Tradable that require an interface.
> 
> I think this may just need to be a logical distinction and not
> necessarily something defined in code except as a coding practice.

My main reason for the introduction of Tradeable is that it allows the
tradeables 
to be collected in one Collection (point 3); this is a debatable point
indeed.
A less important reason is that they have buying and selling as common
operations 
(also see point 3).
 
> > 3. Each entity that can hold Tradeables (certificates and 
> private companies)
> > 
> > has a Portfolio containing some collection of Tradeables. 
> > This applies to Player, PublicCompany and the Bank
> > (the Bank would have two Portfolios: IPO and Pool).
> > Portfolio could be a separate class, perhaps a subclass of some
> > Collection type (ArrayList or HashMap). 
> > Or it would contain such a Collection type. Not sure what's better.
> > 
> 
> I don't think it's a good idea to have one repository for both private
> companies and stock certificates. There is significantly more 
> operations
> performed on stock certificates than there is on private companies. 
> 
> I think these should remain separate.

The operations we are talking about here are selling and buying,
not payout (see my answer to point 4), although even that has some
commonality....

Both Privates and Certificates can be bought and sold (e.g. in 1825 private
companies 
can be sold to the bank pool; in 1841 Concessions -this game's equivalent
of privates- as well as Certificates may even be bought directly from other
players, 
although some house rules forbid that). 

So I don't see much difference between Certificates and PrivateCompanies 
from the ownership/trading point of view, which is all I'm talking about
here.

> > 4. Each entity that has a Portfolio implements an interface Owner,
> > so that each Tradeable can have an attribute defining its Owner.
> > 
> 
> I think this is confusing the relationship between the objects. Owners
> should have a collection that stores their Tradables. We don't need to
> duplicate that specification by assigning an owner attribute to the
> tradable as well.
> 
> Is there any use case where this would not be true?
> 

When paying out a dividend.
How else would you find the owner of each certificate of one company? 
By scanning all potential owners?
I think the payout will be much simpler my way, i.e. if a Certificate
knows its Owner.

I tend to use two-way references indeed, as I already have
done in the case of PublicCompany <-> StockSpace.
There some operations are best done from the PublicCompany side
(finding a company's share price), and other operations are
best done from the StockSpace side (drawing the markers).

IMO the same is true in the certificate <-> owner relationship:
trading is an operation by an Owner towards a Certificate/PrivateCompany, 
but payout is an operation of a Company's Certificate towards its Owner.

> > 5. Maybe we will also need a separate interface Trader, 
> > to define methods that an actively trading Owner must have
> > (sell, buy). This assumes that the Bank does not need such
> > methods (it does not initiate sell/buy actions). 
> > If it does, Owner and Trader will converge into one interface.
> 
> The only thing that can be sold is stock certificates, and 
> it's only to
> the bank. Everything else must be bought. It may be pedantic, but I
> think it's important to make the distinction because buying 
> is a generic
> action, and selling is a singular special case. I think this 
> helps guide
> us to where we need to implement the logic and how.
> 
> I'm not certain another interface is the right answer.
> 

In this case I'm not sure either. We'll see.

BTW, selling _can_ be implemented on this low level as buying by the Bank.
That might simplify the code, but perhaps it would confuse some people.
I have no firm opinion on this matter yet.

Please note, that I am always talking about the Model,
and in fact mostly about the Data Objects "below" the Model.
This is all low-level stuff.

Erik.