Hi Petr,

Thanks for your comments!

- to ensure that a user will pass some object to the function and not just a NULL pointer (public interface)
- to ensure that a user won’t delete returned object (well, he can do this anyway by using & operator, but then it’s obvious that he knows what’s he doing)
- when I want to handle exceptions using dynamic_cast<> rather than test the return value
- basicly I use them over pointers whenever it’s possible (less error prone)

I generally prefer references too. The last point is kind of consequence of the first two.

- when it’s possible that a user will pass a NULL pointer instead of an object (public interface)

Maybe for such cases we could pass in a Null Object and then assert pointer != 0 in the function.

- when the returned object should be deleted by an user (passing ownership) - I prefer “smart pointers”, though

I agree that smart pointers should be used when passing ownership. If we do that consistently we would not have to wonder whether we should delete a returned pointer or not.

59 - Should we use CalitkoMocks to test value objects? Value Objects are just
60 data and should not have behavior which we could write expectations for?

I think that state-based testing is more appropriate there - as you’ve written, I’d use mocks when we need to test behavior (for example to test network communication) and classic unit tests elsewhere.

OK, that we don’t need CALITKO_TESTABLE for Packet and none of the PacketBase.

61 - Should we agree on a convention where reference objects are passed
62 around using pointers and value objects are passed around using
63 references?

As I’ve written, from my point of view it depens on the situation, so I’d prefer to let programmers to decide which variant they should use. But I think that it’s a good idea to unite it between related modules!

I was actually referring to the quote from http://c2.com/cgi/wiki?ValueObjectHypotheses:

“- In C++ I use pointers for my ReferenceObjects, whereas I use values for my ValueObjects. So equality just works out the way I want. I get == by state for values and == by identity for reference objects. I don’t need to define == for reference objects. Copying also just works out the way I want. I get copying of state for values and copying of pointers for reference objects. I don’t use inheritance for value objects, so the dreaded copy by slicing “problem” doesn’t ever hit me. I don’t allow copying of reference objects (I remove access to the copy constructor and assignment operator.) — AmitPatel”

And that does make sense in my opinion. The point of not using inheritance for value objects is an interesting one but I don’t quite see how we could achieve this with out packets. The class Packet wrapping around PacketBase objects seems like an interesting solution so the question is should we treat PacketBase derived objects as (kind of) Value Object or as Reference Objects?

Regards,

Peter