Problems defining classes

**esmeco** · 10-11-2007

Well it makes sense,but how would it be in terms of classes the connection between the vehicles and owners?

**Mario F.** · 10-11-2007

An owner is a data member of a vehicle.

Code:

class Owner { ... }

class Vehicle {
    public:
        Owner GetOwner() { return owner_; }
    private:
        Owner owner_;
}

Who owns the vehicle? call Vehicle::GetOwner() to know.

**matsp** · 10-11-2007

Originally Posted by Mario F.

An owner is a data member of a vehicle.

Code:

class Owner { ... }

class Vehicle {
    public:
        Owner GetOwner() { return owner_; }
    private:
        Owner owner_;
}

Who owns the vehicle? call Vehicle::GetOwner() to know.

Yes, but I still think it should be a pointer so that THE SAME owner can be connected to multiple vehicles, and for example an address update will be affecting ALL vehicles owned by that owner, and not need to be updated multiple times for multiple vehicles [which by the way is not how the UK's DVLA works - if you own two vehicles registered to you as a person, you need to send in both registration documents to change the address].

--
Mats

**esmeco** · 10-11-2007

So,if the owner is referred on the vehicle class (owner owner_

shouldn't the vehicle be referenced in the owner class?

**matsp** · 10-11-2007

You don't necessarily have to keep a reference to the vehicle from the owner - but it helps if you want to find "what vehicles are owned by John Smith". The reverse holds if you want to find "who owns registration ABC123" - then you are best of having a reference in the vehicle to the owner, so that when you locate the vehicle, you don't have to traverse all the owners to find who owns that vehicle.

You could of coruse have a separate table to hold this informaton, where you have a pointer to the owner and a pointer to the vehicle, and neither the vehicle nor the owner contains any links to each other directly [this is sort of a cleaner approach].

--
Mats

**Daved** · 10-11-2007

An object must own all the owners and all the vehicles. The automobile registry is an ok place to do that in this simple setup (ideally something else would own each group and the automobile registry would be restricted to the relationship between the two).

So the autoreg class could have two containers. One that holds vehicles and one that holds owners. These containers should allow fast lookup of their contents. One option is a map. You can have one that maps the owner id to the owner and another that maps the vehicle license to the vehicle.

Once you have the objects contained, then you have to store the relationship between them. This should be a container pairing the keys of each owner/vehicle pair that has a relationship. So you could have a map of owner ids to vehicle licenses. If you need to look up a vehicles owner from its license you could have a map of the vehicles license to the owner id. If you need to lookup in both directions you can have two maps. (There is actually a container from boost that allows you to make both values keys for easy lookups on either in one container if you're interested.)

I don't like the idea of Vehicle containing Owner. What if a vehicle has joint owners? What if you want to have a separate database of information on owners. What if an "owner" doesn't actually own a vehicle? If none of these issues will ever arise, then it might be ok. Otherwise they should be separate.

**esmeco** · 10-12-2007

An object must own all the owners and all the vehicles. The automobile registry is an ok place to do that in this simple setup (ideally something else would own each group and the automobile registry would be restricted to the relationship between the two).

So the autoreg class could have two containers. One that holds vehicles and one that holds owners. These containers should allow fast lookup of their contents. One option is a map. You can have one that maps the owner id to the owner and another that maps the vehicle license to the vehicle.

Once you have the objects contained, then you have to store the relationship between them. This should be a container pairing the keys of each owner/vehicle pair that has a relationship. So you could have a map of owner ids to vehicle licenses. If you need to look up a vehicles owner from its license you could have a map of the vehicles license to the owner id. If you need to lookup in both directions you can have two maps. (There is actually a container from boost that allows you to make both values keys for easy lookups on either in one container if you're interested.)

I don't like the idea of Vehicle containing Owner. What if a vehicle has joint owners? What if you want to have a separate database of information on owners. What if an "owner" doesn't actually own a vehicle? If none of these issues will ever arise, then it might be ok. Otherwise they should be separate.

Could you possibly demonstrate what you said in a few code lines,because I'm a bit confused...

**grumpy** · 10-12-2007

Originally Posted by Daved

An object must own all the owners and all the vehicles.

Why? I own two cars. There is no other object that owns my cars or myself. Hence it is possible to construct a world view in which there is no need for an object to own my cars, other than (objectively) myself.

In general, the relationship between a car and an owner if best described as an association. That might be a many to many association (eg I own more than one car, some cars might be co-owned by several people or organisations).

One way of representing an association between objects is with a pointer. Many to many associations might be represented with an array of pointers, in the definition of each class of object.

**Daved** · 10-12-2007

>> Could you possibly demonstrate what you said in a few code lines,because I'm a bit confused.

Code:

std::map<std::string, Vehicle> vehicles; // map unique license to Vehicle
std::map<long, Owner> owners; // map unique ownerId to Owner

typedef std::multimap<long, std::string> OwnedVehicleMap;
OwnedVehicleMap owned_vehicles;  // map owner to his vehicles

// owner #3 buys new vehicle with license ABC123

// add vehicle
Vehicle new_car("330i", "BMW", "ABC123");
vehicles.insert(std::make_pair("ABC123", new_car));

// add association of vehicle to owner
owned_vehicles.insert(std::make_pair(3, new_car.getlicense()));


// What make/model cars does owner #3 have?
std::pair<OwnedVehicleMap::const_iterator, OwnedVehicleMap::const_iterator> vehicle_range
      = owned_vehicles.equal_range(3);

Owner& the_owner = owners[3];
std::cout << the_owner.getName() << " owns:\n";

while (vehicle_range.first != vehicle_range.second)
{
    std::string license = vehicle_range.first->second;
    Vehicle& current_car = vehicles[license];

    std::cout << current_car.getbrand() << ' ' << current_car.getmodel() << '\n';

    ++vehicle_range.first;
}

It's not the most perfect solution, but the idea is to keep track of the vehicles and owners separately, and then keep track of the associations.

If you have an owner, you can look up the information about the car by getting the license from the association and using the license to find the car. If you wanted to go the other direction, you would want to add another multimap to map vehicles to their owner.

>> Why? I own two cars. There is no other object that owns my cars or myself. Hence it is
>> possible to construct a world view in which there is no need for an object to own my cars,
>> other than (objectively) myself.

In your program, who will manage the lifetime of the vehicles and who will manage the lifetime of the owners? By "own" I meant "manage the lifetime of". I also didn't mean they had to be "owned" by the same thing. So if you want a one-to-many association, then you can have the owner manage the vehicles and something else manage the owner.

**esmeco** · 10-12-2007

But is it possible to do with the vector container instead of the map container the association between the elements?And how does a vector container works?Does it work like an array where you access it like this [i] and in each position we can only store a character (ex: "s") or integer (1111)?

**matsp** · 10-12-2007

A vector is a dynamic array, and it can be defined as you like:

Code:

vector<int> intv;
vector<char *> charv;
vector<owner> ownerv;

You can access the vector just like an array, but you can also use some other functions that are defined here:
http://www.cplusplus.com/reference/stl/vector/

You can't have a vector of owner directly connect with a vector of vehicle, so you still need some way to connect the two together.

--
Mats

**esmeco** · 10-12-2007

Code:

You can't have a vector of owner directly connect with a vector of vehicle, so you still need some way to connect the two together.

And that way to connect could still be maps,or what other options there are?

**matsp** · 10-12-2007

maps would be one of the options. Another option is a vector of a pair of objects (owner and vehicle).

A lot of the decisions here depend on exactly what you are doing with your data and how you plan to organise the data in other respects.

For example, are you planning to keep a register of "previous owners" or just the count of them?

Note that a map is essentially a vector where the "index" is a non-numerical value. So you can for example have a map of vehicles that index on the registration number. Or a vector of owners that index on (for example) a string combination of the first and last name.

--
Mats

**esmeco** · 10-12-2007

I'm planning to just count them...So,would the vector be like this ?:

vector<owner,vehicle> ownerv;

**Daved** · 10-12-2007

There are two distinctly different ways to handle this. One is to have each owner and each vehicle contain the references to the objects it is associated with. So the owner might have a vector<vehicle*> and vehicle might have vector<owner*>. For that to work, you have to make sure some other object controls the lifetimes of the owners and vehicles. You also have to make sure that if you ever delete an owner or vehicle, that you update the associations.

A similar approach would be to have owners contain a vector<string> where the string is the vehicle license. Vechicles could have a vector<long> where the long was the ownerid. This works the same, except you have to lookup the vehicle or owner if you want to access it. It has the benefit of not crashing if you accidentally forget to clean something up- you will just have an invalid id instead of a bad pointer that causes a crash.

The other solution is the one I proposed earlier. Keep the associations in the autoreg class.

>> So,would the vector be like this ?: vector<owner,vehicle> ownerv;
You can use a vector, although it would be more complicated than a map. A vector of pairs would be like this:

Code:

vector<pair<owner, vehicle> > ownerv;

A better solution might be to make a owner/vehicle association class, and store those in the vector if you really wanted to use vector. The problem is that sorting is done automatically in the map, and you have to do extra work if youuse the vector.

No matter what, you have to include code that keeps track of the associations, so that if you remove one it will be changed in other places.