Re^7: Test::Class modules, skip install

If a user of my module isn't supposed to use the method, then it's private, subject to change without notice. However, my subclasses will probably want to override some subset of these private methods because that's where the meat of the work is happening. Hence, they need to read my code.

Furthermore, inside-out objects don't play well with most other uses, such as shared memory, DBM::Deep or other introspective situations.

Another issue is that your tests may not be valid for subclasses.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re^7: Test::Class modules, skip install

Replies are listed 'Best First'.
Re^8: Test::Class modules, skip install by adrianh (Chancellor) on Jun 08, 2006 at 14:30 UTC
If a user of my module isn't supposed to use the method, then it's private, subject to change without notice. However, my subclasses will probably want to override some subset of these private methods because that's where the meat of the work is happening. I guess we have different definitions of private then. If somebody needs to know about and understand a method to be able to subclass a something successfully then I would want that documented and available to all - rather than buried in the source. When I write OO code I do not want to have to read all the source of my superclasses. To me that's one of the advantages of abstraction and encapsulation :-) Furthermore, inside-out objects don't play well with most other uses, such as shared memory, DBM::Deep or other introspective situations. For me the advantages outweigh the disadvantages (and things like Class::InsideOut deal with most of the latter.) Another issue is that your tests may not be valid for subclasses. True - but I think that would mean: I'm testing something that's not intended to be subclassed - so I don't care. I've made a mistake in the design - since subclasses should be a specialisation of their super class. That's what an isa relationship says to me. I'm not saying that it's always a good idea to install test classes - I just don't think it's always a bad idea either :-)	[reply]

Replies are listed 'Best First'.

Re^8: Test::Class modules, skip install
by adrianh (Chancellor) on Jun 08, 2006 at 14:30 UTC

If a user of my module isn't supposed to use the method, then it's private, subject to change without notice. However, my subclasses will probably want to override some subset of these private methods because that's where the meat of the work is happening.

I guess we have different definitions of private then. If somebody needs to know about and understand a method to be able to subclass a something successfully then I would want that documented and available to all - rather than buried in the source.

When I write OO code I do not want to have to read all the source of my superclasses. To me that's one of the advantages of abstraction and encapsulation :-)

Furthermore, inside-out objects don't play well with most other uses, such as shared memory, DBM::Deep or other introspective situations.

For me the advantages outweigh the disadvantages (and things like Class::InsideOut deal with most of the latter.)

Another issue is that your tests may not be valid for subclasses.

True - but I think that would mean:

I'm testing something that's not intended to be subclassed - so I don't care.
I've made a mistake in the design - since subclasses should be a specialisation of their super class. That's what an isa relationship says to me.

I'm not saying that it's always a good idea to install test classes - I just don't think it's always a bad idea either :-)

[reply]