Obj.Orient. Structure question newbie/intermediate

Im Making a very simple vehicle renting program.
This is probably a simple question even if the text is a bit long.

I have made theese simple classes.
Vehicle, VehicleManager, VehicleForm with (Add/Remove buttons)
Customer, CustomerManager, CustomerForm(Add/Remove buttons)

Agreement, AgreementManager, AgreementForm(with Add/Remove buttons
one ComboBox with Customers and
one ComboBox with vehicles
(and 2 datepickers))
In AgreementManager I have 'private List<Agreement> _Agreements'

A very simple structure but....
I was planning to remove the customer in CustomerForm.
The problem comes up when I want to remove a customer that has an agreement.
This must be inhibited(Show error/informative message and all that) if the customer is found as a customer in the agreementlist witch resides in the AgreementManager class.

How can I look in this list from 'inside' the Customer form.
I cant just make another agreementamng. object, because making a new one will not have the agreements in it.
How should/can I access methods in AgreementManager from CustomerForm?

Alternatively I could have a boolean _HasAgreement in the Customer objekt, to prevent delete. But that seems like a rather primitive solution now that i am learning to use obejct orientation and ObjectLists and working with managers.

thanks
BlindNavigator

How is the Agreement class defined (i.e what are its public properties)?

Quote:

---

Originally Posted by Arjay

How is the Agreement class defined (i.e what are its public properties)?

---

Agreement has at the moment
public Customer Customer
public Vehicle Vehicle
public DateTime StartDate
public DateTime EndDate
The AgreementMangager has the List of Agreements at the moment but I think might I need to put this list somewhere else.

I have given this some more thought and i have come up with sort of ER-diagram to help think about proper object orientation.
The Entity Relations :
One Customer can be in many agreements provided dateperiod does not overlap another agreement.
One Agreement must have only one Customer and One Vehicle
One Vehicle can be in many agreements provided dateperiod does not overlap another agreement.

So perhapps if i have an agreement list in Customer, but i fear this will make it tricky instead when a vehicle ha to be removed from the Vehicle list.

thanks
BlindNavigator

The agreement class seems to have something missing, (like purchase price or lease terms).

Besides that, I would figure out the over all model by first the types of operations (i.e. user stories) you need to do on a given entity.

For example, as a salesman, I need to
list all the available vehicles in inventory (query by make/model).
list all the available customers.
list all the vehicles purchased by a single customer.
enter new vehicles into inventory.
enter new customers into the system.
allow a customer to purchase a vehicle.
allow a customer to lease a vehicle.

As a customer, I need to
find out whether there are any recalls on my vehicle.

Based on the list of user stories, you develop the model and relationships that allow you to perform the various operations to fulfill the user stories.

Rather than having separate manager classes, I would probably have a single 'DealershipManager' class that allows you to perform all the operations.

For example, the DealershipManager may have functionality that allows a salesman to search the inventory, retrieve a customer, or add a new customer.

In addition to what Arjay said, let me just add a few thoughts. Your "manager" classes can do more than just store a list of things - as long as it conceptually makes sense, and as long as the responsibilities of the class are clear (well defined). For example, the AgreementManager can manage the relationship between agreements and customer, and support related operations (such as checking if a customer is associated with an agreement), by providing a simple interface to the outside, thus hiding the complexities under the hood. If you make it so that you always use the AgreementManager when adding/removing/retrieving agreements (as in: myAgreementManager.Add(new Agreement(...)) ), then external code can use its interface to do what it needs to do, without worrying about the relationships between agreements and other objects - since it would all be handled by the manager class.

In the manager itself, you can do more than keep a single list of agreements; you can also store a Dictionary<Customer, List<Agreement>> to that you can use to quickly find agreements associated with the given customer. If you do everything via the manager class, that would provide add, remove, and other methods, then only those methods need to worry about keeping the list and the dictionary in sync.
But, again, it all depends on what exactly your application needs to support; also note that there may be more than one approach to solving these problems.