How strictly should I observe "has a" and "is a" models?

Question

0.00/5 (No votes)

See more:

I have two different transaction classes that both have the same data and I thought I'd do something about the common code for serialization.

It seems like the easiest way to do it would be to create a common base class for both (which would be intermediary since they both already have base classes). That way all I'd have to do is change the constructors and I wouldn't have to change anything that already uses the common variables. Everything would magically work. But I wonder if modifying the constructors could have management issues in the future.

If I embedded a class that had the commonality, I believe I'd have to change all of the places that access the variables. It seems a little more cumbersome. Maybe I'm wrong.

Let's say the data was a m_Circle and a m_Parent that owned the shape. For a CAddCircleTransaction and a CRemoveCircleTransaction, it sounds a little better to say "has a circle" than "is a circle" but it's not entirely clear.

I feel silly, like I've been programming way too long to asking such basic question but I can't decide. Last time I used inheritance for a similar thing and it worked so smoothly. This time I seem to leaning towards embedding but the ease of inheritance is making me hesitate. Can I just choose or is one way better?

Posted 25-Jan-11 0:31am

Brian Bennett

Updated 25-Jan-11 0:35am

v2

Add a Solution

3 solutions

Solution 3

You said it in the beginning, both objects have the same data. They are owner's of the data, and as a result they HAVE this data, but they are not that data.

If transactionData is the data used commonly between the two, I'd write a class called transactionData, then another abstract class called transactionOperator.

Implement the most base common functionality (i.e, it has transactionData, the accessors, the most simple of operations) and then, for example, write a pure virtual function ::addTransaction().

Then in inherited versions of the class, you can implement the different ways they want to handle the transaction.

Just my two cents based on the info given.

And no, there isn't a rule that says one way or the other is a better answer.

Look up composition vs inheritence. They both have their pluses and minuses.

Posted 26-Jan-11 10:49am

Harrison H

Updated 26-Jan-11 10:51am

v2

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Cedric Moonen · Accepted Answer · 2011-01-25T01:05:00

I'm not sure I fully understand your problem but in my opinion, if you are working with different kind of transactions, I would almost certainly make them all inherit from a common abstract base class. In case you have transactions which are, like in your example, similar in some way, I would add an additional class in the hierarchy (so, you would have CTransaction then CCircleTransaction inheriting from it and then CAddCircleTransaction and CRemoveCircleTransaction both inheriting from CCircleTransaction).
You were a bit wrong in your sentence about "has a circle" and "is a circle" since you do not inherit from the circle class but from the CCircleTransaction. And a CAddCircleTransaction is indeed also a CCircleTransaction.

Maybe I didn't clearly understand your question, so if that's the case please try to rephrase it.

Eugen Podsypalnikov · Accepted Answer · 2011-01-25T01:07:00

Solution 2

It could be a possible begin :) :

class CShape : public CObject
{
..
};

class CCircle : public CShape
{
..
};

class CTransaction : public CObject
{
..
};

template <typename T>
class CShapeTransaction : public CTransaction
{
  T* m_ptShape;
..
public:
..
  T* GetShape() { return m_ptShape; }
..
};

class CAddCircleTrasaction : public CShapeTransaction<CCircle>
{
..
};

class CRemoveCircleTrasaction : public CShapeTransaction<CCircle>
{
..
};

Posted 25-Jan-11 1:07am

Eugen Podsypalnikov

Updated 25-Jan-11 1:31am

v3

Comments

Harrison H 26-Jan-11 16:41pm

Why do you use a template parameter when the pointer can just be of type shape?

Eugen Podsypalnikov 26-Jan-11 17:33pm

Yes, it can :)
I was just attracted to the same "ready" type of the member and its get function... :)

How strictly should I observe "has a" and "is a" models?

3 solutions

Solution 1

Solution 2

Solution 3

Add your solution here

Preview 0

How strictly should I observe "has a" and "is a" models?

3 solutions

Solution 1

Solution 2

Solution 3

Add your solution here

Preview 0

Existing Members

...or Join us