[mailto:boost-bounces@lists.boost.org] On Behalf Of Tobias Schwinger
simon.sebright@ubs.com wrote:
Tobias wrote:
Maarten Kronenburg wrote:
The class represents the set, and an object of that class represents an element from that set,
Agreed, so far.
whether the set is employees and secretaries, or integers and unsigned integers.
The operations on secretaries are usually a superset of the operations on employees, while the operations on unsigned integers are a subset of the operations on signed integers.
Inheritance is only applicable in the former case. The flaw in the latter scenario is similar to adding operations specific to secretaries, trainees or managers to the interface of 'employee'.
Things like secretary, manager, etc. might better be considered as roles, an employee might have > 1 role.
Sure, if that's what you are trying to model. But what does that have to do with this discussion?
I seem to have joined the thread in the middle, sorry if I am repeating something already said... I guess I am reinforcing what I have been picking up on this thread. I.e. that behaviour of something can be disconnected from what it is (a square is a rectangle in geometry, but the behaviour of a square object does not meet the contract of a rectangle object). In the computer world, inheritance is a very strong relationship, and needs to be considered carefully, taking into account the dynamic nature of the instances. The above separation of employee/role is a bit of a strategy pattern, I think. Maybe it could help the integer issue, such that the various required integer classes could hook up to sets of behaviour, some in common, some not. Traits might be able to contribute too. Anyway, what about the fact that it is not a good idea to have multiple concrete classes in a hierarchy? That would debunk one int class deriving from another. Simon