Derive & Destroy Encapsulation, or Violate DRY?

Question

I have two C++ classes: Sequence, which is just like std::vector, and File, which is a Sequence of strings that represents a file on the machine.

Deriving File from Sequence is a no-brainer. Its behavior is exactly the same, but with the added functionality of reading and writing files. The File-specific functionality is implemented easily, without the need for Sequence's data members to be marked as protected. Instead, they can be private, and File can use Sequence's public interface. Happy times all around.

I want to make an Array class that internally manages dynamically-allocated memory. An Array object cannot be resized; the size is specified in the constructor.*

Here's where things get arguable.

Concept-wise, it makes sense to derive Sequence from Array. Just as a File is a Sequence with the added functionality of reading and writing files, Sequence is an Array with the added functionality of resizing on-demand.

But there's a key difference: The resizing functions require direct access to the memory Array is managing. In other words, the previously-private members must now be protected.

Using protected members instead of private ones destroys encapsulation. The link between Array and Sequence is the only one that requires it; other classes in the works can just use their parents' public interfaces. In this sense, it's a bad idea to derive.

You could argue that people who want arrays can just use Sequence and ignore the resizing functionality. But then again, you could just use File and ignore the read/write functionality. It would be like buying a laptop but never moving it from your desk. It simply doesn't make sense.

What's the best move: To derive, and potentially destroy encapsulation; to make Array a completely free-standing class, and have to pointlessly re-implement a lot of functionality; or to forget about Array completely and just make people use Sequence?

*Note that this is a project for fun and education, so the practicality of having a non-resizable dynamically-allocated array is beside the point.

Answer 1

You might consider slicing the problem in a slightly different direction. Instead of inheritance, perhaps this problem could be solved with a template -- specifically, a policy template that manages a buffer for a collection. You'd have (at least) two implementations of that: one for fixed allocation, the other for automatically resizing.

That wouldn't break encapsulation at all, and nearly the only overlap I can see between the two would be that the initial allocation is probably about the same whether fixed or variable. Given how trivial that is, I doubt it's worth spending much time or effort on trying to factor it out. In theory it could be, but at least in a typical case we're talking about one line of code, and a pretty simple one at that.

Going back to the inheritance question for a moment, it comes down to this: this is very much like the standard circle vs. oval situation, where there's enough similarity for one to seem like the other, but ultimately neither satisfies the LSP -- you can't treat either one as the other safely, so (at least public) inheritance isn't suitable. Private inheritance doesn't require following LSP, but is generally only useful when/if you need/want to override a base class' virtual function, which seems unlikely here as well.