Stack/Queue Question

[monarch_dodra]

Well, there are cases where private inheritance is mandatory, compared to composition. Keeping in the mindset that private inheritance means "is implemented in terms of":

What if the object you are "implementing in terms of" can be customized by overiding a private virtual function?

What if you want your object to be "implemented in terms of" two different classes, both of which virtually derive from the same base class (the dreaded diamond)?

Now, we could argue that any application that does this might best be purged in fire along with all the hardware it has ever touched, but still. Private inheritance can give you more functionality than can be obtained through composition alone.

Composition is probably easier and safer, but just like the pointer vs reference idiom "References when you can, pointers when you must".

[nuzzle]

Don't get me wrong: I'm not saying C++ is bad or something. I'm just saying that I don't see significant added value in features like protected and private inheritance to warrant their inclusion in the language. I believe C++ programmers could live without them just fine.

Firstly I wanted to point out that you're using a known C++ critisizing pattern.

It goes like this. You're imposing a new meaning (that's not defined by the C++ standard) on a certain construct. Then when C++ doesn't live up to your expectations you declare the construct useless.

My response to this is - lets take C++ at face value. Lets not make it into something it isn't and then blame it for it!

Secondly, the specific case of private inheritance. You're calling on OO here but the whole idea of OO is to separate design from implementation.

And C++ does it nicely. When you're using private inheritance you're in the realms of implementation where C++ grants you the right to do whatever you like including shooting yourself in the foot.

It's as it should be. In C++ the programmer is king. To put it bluntly, without private inheritance C++ would be reduced to just another Java where the programmer is slave. Who wants that? I've just left Java and I don't want it back!

That's why I think you're wrong. But I don't hate you .

[TheGreatCthulhu]

Well, there are cases where private inheritance is mandatory, compared to composition. Keeping in the mindset that private inheritance means "is implemented in terms of":

What if the object you are "implementing in terms of" can be customized by overiding a private virtual function?

What if you want your object to be "implemented in terms of" two different classes, both of which virtually derive from the same base class (the dreaded diamond)?

Now, we could argue that any application that does this might best be purged in fire along with all the hardware it has ever touched, but still. Private inheritance can give you more functionality than can be obtained through composition alone.

Composition is probably easier and safer, but just like the pointer vs reference idiom "References when you can, pointers when you must".

OK, I wouldn't go as far to "purge it all in fire"
The way I see it: the mechanics behind the language construct define the outlines a potential modeling relationship, and then the programmer can skillfully mend that to suit one design or another, provided that it's reasonable to use that particular language construct in that situation. So, private inheritance is either expressed primarily as a twisted form of is-a, or (preferably) primarily as an "implemented in terms of" relationship.

I've been very careful with words here, also taking into consideration things pointed out by nuzzle, and I believe this interpretation is pretty sound.

I've read your post and I've been over what are called valid reasons to use it, as pointed out here - as best as I can assess, my reference has enough credibility, but please point out if anything is off.
So, on one hand it gives you power, on the other, it carries hidden problems, which in turn means that to use it properly within a fairly complex, competitive, change-aware, long term project, a deep understanding of the topic is required, although it doesn't always seem that way. That is, IMO, not the best language design - but, it's easy for us to look back now and say that something could have been done differently.

• The reasons mentioned there are:
  
  • 
    [ << "implemented in terms of" >> ]
  • We need access to a protected member.
  • We need to override a virtual function.
  • We need to construct the used object before, or destroy it after, another base subobject.
  • We need to share a common virtual base class, or override the construction of a virtual base class.
    [<< is-a >> ]
  • We need "controlled polymorphism" LSP IS-A, but in certain code only.
    [<< extras >> ]
  • [I'd add a mixin-based approach to all that...]
  • [And the "diamond" inheritance problem...]

These are all strongly indicative of bad design, on both base class side and derived class side. Furthermore, these show how, no matter how you view the relationship, the same coupling that causes fragile baseclass problem and the like exists here.
In other languages, the resulting design would probably be somewhat more complicated, and although it would seem as extra work at first, it would end up being more soundly structured, and more stable yet flexible.
So, IMO, justification would have to be something more than just this. Like, if there's a significant performance benefit in a performance critical application. Or if the legacy/3rd-party code is nearly impossible to work with in any other way.

Firstly I wanted to point out that you're using a known C++ critisizing pattern.

It goes like this. You're imposing a new meaning (that's not defined by the C++ standard) on a certain construct. Then when C++ doesn't live up to your expectations you declare the construct useless.

Well, I don't think the criticism is entirely unjustified. Otherwise, recommendations to generally avoid protected and private inheritance wouldn't exist, would they? But useless? I didn't say that. I'm just saying that there's probably a better way to do things.

My response to this is - lets take C++ at face value. Lets not make it into something it isn't and then blame it for it!

I'm not putting the blame on C++, it's just that - nothing in this world is perfect. It's a good thing to understand the tools you're using, so that you can use it as best as possible. That's precisely taking the language at face value.
I've done my best to avoid assigning any non-intrinsic qualities to private inheritance (see above), but as I noted before, we disagree on what exactly these intrinsic qualities are in this case.

Secondly, the specific case of private inheritance. You're calling on OO here but the whole idea of OO is to separate design from implementation. And C++ does it nicely. When you're using private inheritance you're in the realms of implementation where C++ grants you the right to do whatever you like including shooting yourself in the foot.

And yet, it is the OO community that criticizes the feature the most .
Note, however, that you're "in the realms of implementation" only if you're very disciplined about your code. People are rarely very disciplined about anything. But, that's one side of the coin. The other, maybe more important, is the potential extra coupling that can be, in majority of cases, avoided, and that leads to fragile base class type of problems, especially in complex projects. OO and systems design are all about managing complexity.

[...] C++ grants you the right to do whatever you like including shooting yourself in the foot.

It's as it should be. In C++ the programmer is king. To put it bluntly, without private inheritance C++ would be reduced to just another Java where the programmer is slave. Who wants that? I've just left Java and I don't want it back!

Oh, yeah, I've seen your rant against Java at the Java forums here ().
Java certainly isn't perfect, and I really can't be the judge of it, but suppose some of the "Java people" have experience in C++ as well... Maybe when they say that you somehow didn't get Java, maybe they have a point. I mean, you really buried it in the mud, so, it's almost hard to believe the situation could really be that bad.
But, I can talk about C# (which "stole" a lot of good ideas from Java, probably from C++ too, and from the overall industry experience i guess). To me, C# is almost like poetry. The programmer is by no means a slave there. But it's not perfect either. On the other hand, I don't really like languages like VB, even if they come in the .NET variant... And I hold C++ at a very highly esteemed 2nd place. BUT, IMO, C++ "kings" have less freedom then they believe. Assembly gives you all the freedom you'd like, but I don't think the programmer is a king there.

That's why I think you're wrong. But I don't hate you .

LOL. For, the record, I don't hate you either .
But, we disagree, and disagreement is a good thing, as long as it's in a form of a discussion. It's a way to bounce ideas and change perspectives, look at the problem area from different angles, and improve understanding, come closer to the truth. That's what, among other things, forums are for.

[nuzzle]

But, we disagree, and disagreement is a good thing,

I've expressed my view and I stop here with a few comments.

First my criticism in the Java forum was pertaining to how Sun mismanaged the Java technology for desktop developments. It was not directed at the Java language per se. Java is a nice OO language.

The reason I brought up Java here is because it leans heavily towards the OO paradigm whereas C++ is paradigm agnostic. C++ doesn't enforce a specific paradigm on you. You can mix and match using different paradigms even in the same project. I like that freedom.

And this is also why I react when people critizise a certain C++ language feature, like private inheritance, on the grounds that it doesn't fit their preferred paradigm. C++ is a potent language and you need knowledge and discipline to write good programs. But it would be a mistake to neuter it by removing constructs that don't fit OO. It's been done. It's called Java.

Thanks for this discussion.

[BigEd781]

The reason I brought up Java here is because it leans heavily towards the OO paradigm whereas C++ is paradigm agnostic. C++ doesn't enforce a specific paradigm on you.

But of course, this is a vestigial remnant of a decision to maintain backward compatibility with C. I am certain that decision led to the massive adoption of C++ that you see today, but that doesn't mean it was a good choice from a language design point of view. C++ is a powerful language, but is also huge, messy, and packed full of features that are of arguable benefit. Anyway...

I've taken the liberty of inviting Arjay and BigEd781 to share their opinions in this discussion; my intention wasn't to involve people who would be "on my side" (I don't know their opinions), but I wanted to have some insight into what someone who is highly competent in both C# and C++ thinks of the matter (having experience with two language design philosophies), in the amount of detail they see fit. I think it's valuable to review things from yet another perspective, and I'm hoping they will find time to write down a few thoughts.

So hi .

Because the language does not impose strict rules regarding what you can and cannot do, we are faced with a problem. Sure, one can use (for example) private inheritance any way they wish, but that doesn't mean it is a good idea, and as responsible developers we often create guidelines for how and when they should be used, if at all.

I don't know what was running through Stroustrup's mind when he envisioned private inheritance, so I can't attest to that. I can however speak to the OP's example, in which his Stack type is certainly implemented "in terms of" an std::list. This "Stack" actually *is* a list, it just looks like a Stack from the outside world because of its public interface.

These language constructs were not added to C++ willy nilly (or hell, maybe they were, it sure seems like it sometimes...). The designer(s) certainly had some notion of how they would be used before standardizing them. These days any competent programmer is forced to create a mental model of C++'s features because there are so darn many of them and so darn many gotchas that it is required to build stable and maintainable C++ applications. This is also why many shops only use a subset of C++ features.

So, I agree with Cthulu here; sure, you can use private inheritance any way you like, but that doesn't mean it's a good idea, and that also doesn't mean that there aren't implicit consequences of using it. In most cases it does mean "implemented in terms of" simply because your type takes over the behavior of the base class.

You can shape it to your will if you like, but you can also stir a boiling pot with a closed umbrella and eat soup with a fork. Certainly it is possible, but it may not be wise to do so, and you are obviously fighting against their intended use.

[nuzzle]

But of course, this is a vestigial remnant of a decision to maintain backward compatibility with C. I am certain that decision led to the massive adoption of C++ that you see today, but that doesn't mean it was a good choice from a language design point of view. C++ is a powerful language, but is also huge, messy, and packed full of features that are of arguable benefit. Anyway...

That's the kind of sweeping criticism I dislike; C++ should be different, unclear how.

1. The paradigm agnostic nature of C++ has nothing to do with the C connection. C represents procedural programing. In addition you have generics, object orientation and increasingly functional programming. They have nothing to do with the C past of C++.

2. The backward compatibility with C was a stroke of genius. What would've been a better choise? Fortran? Cobol? A brand new language? In hindsight, what other existing language would you say C++ should've better been like? Fine, use it!

3. C++ is complex and that's what makes it powerful. It's not messy, it's complicated because it's complex. And where are all the features of arguable benefit? Mention one (that's not a trivial detail)!

[BigEd781]

I agree with all of those points to some degree, but they each comes with its own set of drawbacks.

1. Yep, and they are all an afterthought, though still useful.
2. Yes, a good strategic move and very smart, but that doesn't mean it was a goo decision purely in terms of language design. I think it was the right choice, but still, drawbacks.
3. Yep, but it is messy. When you have, multiple ways of doing the same thing it's messy. Name one feature of arguable benefit that creates more problems than it solves? Ok, multiple inheritance.

I use C++ every day. It's a powerful language and it gets the job done, but it's certainly not my goto language if I can avoid it. It's not elegant, it's a sledge hammer. Great when you need a sledge hammer, but otherwise I'll use something more friendly with a more focused design. Anyway, this wasn't meant to be a "C++ is good/bad" debate, just a comment on private inheritance, why it exists, and how it should be used/thought of. I'm not religious about this stuff, but I think that, in general, private inheritance *does* mean "implemented in terms of".

[laserlight]

I'm not religious about this stuff, but I think that, in general, private inheritance *does* mean "implemented in terms of".

As the person whose retort started this mini-debate, I'd say "quoted for truth". I've read the debate thread cited to me before, but I am not too concerned about it. As I stated in post #5, for the OP, and probably in general, composition "probably (will) be easier for you to think about" than private inheritance. That to me is more important than trying to force a notion of an automatic is-a relationship onto private inheritance and then using that to say that private inheritance should not be used here because it does not model is-a.

[TheGreatCthulhu]

As the person whose retort started this mini-debate, I'd say "quoted for truth". I've read the debate thread cited to me before, but I am not too concerned about it. As I stated in post #5, for the OP, and probably in general, composition "probably (will) be easier for you to think about" than private inheritance. That to me is more important than trying to force a notion of an automatic is-a relationship onto private inheritance and then using that to say that private inheritance should not be used here because it does not model is-a.

Well, this mini-debate sort of stopped being about the OP's question, and somehow turned into a discussion about private inheritance...

However, you, and nuzzle it seems, are completely misinterpreting what my concerns are actually about. Yes, I did say that you can't just declare private inheritance - as a language construct - to be completely paradigm agnostic, because it is simply not possible, but that's me nitpicking for purely academic reasons, that is not the point. Private inheritance may have been designed to provide a higher level support for various implementation strategies, but regardless of how you interpret it (as IITO or is-a), it's provides the same internal mechanisms that inheritance does, and that's the problem.

Why. Well, forget private inheritance, and take public inheritance instead. I've already said that OO is all about managing complexity. Why do you think that industry experience strongly advocates not to overuse or misuse inheritance? Because it has hidden pitfalls, subtle interactions that are hard to spot/track/document that, on the long run, have the potential to create a code maintenance hell, reduce reusability, or simply break the code, all because of extra coupling. I've been yelling semantic fragile baseclass problem (sFBC from now on) throughout this thread. Furthermore, I've been consistent in mentioning not sFBC, but sFBC-class of problems - because sFBC is a subset of this group of inheritance-related problems. It's hard for many people to understand what these are actually about, because they are not about compilation problems, or some obvious errors or exceptions. But, I was hoping that experienced developers could have more insight. These are about subclass-baseclass interactions, often indirect, or not obvious via code itself, whereby changes in one could break some invariants in another, or betray some assumptions, thus breaking the code as a whole (it compiles, but God help us with what it does). How? By the simple act of overriding a method, for example. While not overriding another one that is somehow defendant on that one. And not all of these dependencies are obvious or even documented. Or, in the fashion of sFBC, by providing a new version of a baseclass with a seemingly innocent change, that then breaks the client code that relied on a derived class, by breaking an invariant that the derived class assumed.
This is often related to bad design, as well as to client code relying on some implementation detail, maybe for performance reasons - something not uncommon in C++ world.
To read more about this class of problems, namely a subset related to deriving classes safely, see Ruby & Leavens (2000) - Safely Creating Correct Subclasses without Seeing Superclass Code. It's rather academic, and includes reflections on experimental languages, but it explores the problem.
How then should inheritance be used? To see a gallery of proper uses for inheritance, just open Design Patterns by Go4.

Now, back to private inheritance. The recommendation to avoid it unless you really can't is not there without reason. Regardless of how you interpret it (IITO or is-a, or whatever mix seems suitable), it introduces the same problems the public inheritance does. Because, if you're using private inheritance, you are likely to override something, or access a protected member, maybe even introduce new dependencies that can't be represented in syntax. In short, you're introducing the same kind of coupling. It's just how it works.
And only then, on top of that, the construct itself is a bit weird and is something that OO-aware developers are not readily familiar with.

Also, I've been "accused" that I'm forcing specific semantics at private inheritance, but by insisting on IITO, aren't you guys doing the same?
I'm simply saying that there is more to it than you claim, as explained above - which pretty much makes my views broader than yours...
Interestingly enough, in the thread you mentioned, they sort of reached the conclusion that it's better to look at private inheritance from more than one aspect.

What I argue is that:

1. Lack of protected/private inheritance would force less experienced designers to create better designs, or at least to limit themselves to other type of errors. But, since it's already there,
2. it's one of those things that should be used in exceptional situations, because
3. in complex, long running projects, it can be dangerous. Other than that,
4. although it's advocated not to use it, people, among them novices, do.
5. Speaking of novices, they tend to get lost in all the details and intricacies, while loosing the sight of the bigger picture, namely how to design good code.
6. So... Isn't all that indicative that this is not the best language design?

That's the kind of sweeping criticism I dislike; C++ should be different, unclear how.

I thought this discussion was about understanding all the nuances of protected/private inheritance. On my part, I already said that, despite the claims to the otherwise, C++ programmers would be better off without it, but, since it's already there... Frankly, I'm concerned that you, as C++ developers, aren't too concerned about it.

3. C++ is complex and that's what makes it powerful. It's not messy, it's complicated because it's complex. And where are all the features of arguable benefit? Mention one (that's not a trivial detail)!

Well, I don't see it that way. It's power comes form relatively few, more or less simple, and well thought of concepts; it's complexity comes from the maturation process.

C++ grants you the right to do whatever you like including shooting yourself in the foot

The way I see it, C++ grants you an illusion of absolute power and freedom, because you have to invest too much work and have to constantly be on vigil, just so that you don't shoot yourself in the foot - and all that energy could have been better spent.

I like the right amount of control embedded into the design of a language. On the other hand I recognize that there is a fuzzy line between getting the right power/control ratio on one end, and hand-holding on the other - and the latter I dislike. For example, later versions of C# introduced auto properties. In case an explanation is needed - properties are just syntactic sugar for a pair of get/set methods, and as such have a backing member variable. Auto properties remove the need for an explicit backing member variable, behaving as a public member field themselves. This can be handy for trivial getters/setters, but it allready creates some confusion among novice programers. I don't like them [auto-properties] for that fact alone. The need to understand them for what they are distracts them [novices] from much more important stuff.

Final thoughts... Arjay (the other person I invited) and I exchanged a few thoughts via PM, and although he said that he didn't have "anything significant to add publicly", I myself found a few points of interest in the exchange. Among other things, this is what he said that with regard to code maintenance (which he deems very important):
"I think what comes up in practice most is tightly coupled code. Although I code mostly in C# now, I see folks tightly coupling C++ code. [...] The larger the projects the more necessary it is to keep things loosely coupled."

Also:
"Many times in larger projects, I find that inheritance makes everything a pain to work with."

I claim that this coupling is exactly what creates the problems, and I argued that private inheritance (no matter how you view it or define it) has a great potential to create the same kind of coupling.

In closing, I found this interview with Bjarne Stroustrup, a part of which, I think, describes his sentiments about this sort of things. When asked about some potential issues with private inheritance (check the link for details), Stroustrup replied:

Fundamentally, I consider these these issues purely academic and of no interest to practical programming.

Well, that's a rather old-school opinion. Maybe that statement could hold once, but in tomorrow's world, software and software systems are only going to get more and more complex, and interconnected, so I believe that these "purely academic" issues are going to become more and more likely to pop up in the realm of the practical.

Boy, that was a long post.
My intention was to keep it short, but it somehow slipped out of control.

[superbonzo]

as nuzzle said, you are too biased towards an OO-centric view of C++; more specifically, you're reasoning as like inheritance were used in C++ only as a OO-like construction; consider the Sutter's link in post #18: it treats the problem of whether it is better implementing a class by composing with or privately inheriting by another class, where both classes are allowed to change/evolve indipendently. The solution of the problem ( avoiding inheritance in favor of composition ) obviously comes from coupling minimization.
But once you drop the assumption of indipendent evolution of the two classes the conclusion does not hold anymore. Of course, when inheritance models an OO relationship that assumption always holds ( or it's safe to assume so ), but C++ allows non-OO paradigms where that assumption ceases to hold in general.

For example, take a look at the VC++ STL implementation, or (most of) boost source code: (public-private-protected) inheritance is used extensively as a means of organzing class implementations without any devilish side effect on their public interfaces; of course, (nearly) no polymorphic behavior is involved here, we're speaking mainly of generic programming, not OO. Base classes are simply hidden behind some weak incapsulation mechanism ( like a "details" namespace, a standardized interface, etc ... ) and are not allowed changing indipendently with respect to their "implemented on terms of" classes; they're just implementation details, choosen to maximize readibility/mantainability/performance or whatever reason they felt important to do so. For example, it's simply a matter of two mouse clicks to realize that VC++ "std::vector" publicly inherits from "_Vector_val" that in turn publicly inherits from "_Container_base", etc.. nonetheless I've never heard of any insane/novice programmer exploiting those relationships in their code; conversely, those "_Vector_val", "_Container_base", etc.. are simple 2-4 members classes each with its own responsability serving as a simple and effective way of separating the vector implementation in logically distinct but intrinsically coupled parts. No sane-minded mantainer will ever try to modify one of them without knowing their mutual relationships, in the same way no mantainer will ever try to modify a private class member ignoring the overall class implementation.

The point is that the use of inheritance in C++ goes beyond its corresponding OO concept, especially considering the multiparadigmatic nature of C++; therefore, depriving C++ of non-public inheritance ( and other non-OO-friendly language features ) would essentially make C++ an OO language only, or "just another Java", using nuzzle's words

of course, you might say that most C++ programmers actually use only a small subset of C++, essentially its OO part. Now, I don't know if this is true or not, as I've never read of any statistics on the subject, but in any case even those programmers indirectly use the full C++ features set through libraries like STL, boost and others extensively exploiting its non-OO features, where there are plenty of things "that OO-aware developers are not readily familiar with"

BTW, regarding sFBC-like issues, I've always been surprised of how people gets surprised by these kind of problems ... it seems like there have been a time when developers thought that inheritance were a fool-proof way of adding behavior to a class, only to realize all of a sudden that it was not the case ...

I mean, why considering a "subtle interaction" or a "hidden pitfall" something as obvious as the observation that programmers making unsjustified assumptions on their/others code are programmers writing bad software ? of course, these problems can manifest themselves in hard to spot ways, but this happens nearly everytime you don't follow rules in C++ ... and I'm not saying this is not an issue, I'm saying that this has not specifically to do with inheritance, being a characteristic trait of the language that of being vulnerable to unproper design and/or usage.

[laserlight]

Because, if you're using private inheritance, you are likely to override something, or access a protected member, maybe even introduce new dependencies that can't be represented in syntax.

I cannot say I use private inheritance all that often, but in cases where I recall seeing it used, the private base class was not designed to be a public base class: you cannot override something or access a protected member because there are no virtual member functions and all members are either public or private.

In this I echo superbonzo's assertion that, from my point of view, "you are too biased towards an OO-centric view of C++; more specifically, you're reasoning as like inheritance were used in C++ only as a OO-like construction".

Also, I've been "accused" that I'm forcing specific semantics at private inheritance, but by insisting on IITO, aren't you guys doing the same?
I'm simply saying that there is more to it than you claim, as explained above - which pretty much makes my views broader than yours...

Actually, I insisted that private inheritance does not imply is-a and agreed that, in general, private inheritance does mean IITO

[nuzzle]

I agree with all of those points to some degree, but they each comes with its own set of drawbacks.

1. Yep, and they are all an afterthought, though still useful.
2. Yes, a good strategic move and very smart, but that doesn't mean it was a goo decision purely in terms of language design. I think it was the right choice, but still, drawbacks.
3. Yep, but it is messy. When you have, multiple ways of doing the same thing it's messy. Name one feature of arguable benefit that creates more problems than it solves? Ok, multiple inheritance.

If you want a discussion to stay focused then don't make sweeping controversial statements about other topics.

After your reply I know you're way out for sure:

1. The changes to C++ after its initial release can hardly be considered an afterthought as you claim. It's natural for languages to evolve. The alternative spells stagnation.

2. You claim the C connection was a bad design choise but what exactly would've been better? Some other language that existed at the time? Which? A brand new design? Which?

3. So you feel many ways of doing the same thing is bad? Like if there's a while-statement there shouldn't be a for-statement? What's so bad about choise? You claimed C++ is "packed full of features that are of arguable benefit" and when called for an example the worst you could come up with is multiple inheritance. Well, how bad can it be? It's a cornerstone of OO and both Java and C# have it (although in a milder form).

I use C++ every day. It's a powerful language and it gets the job done, but it's certainly not my goto language if I can avoid it. It's not elegant, it's a sledge hammer. Great when you need a sledge hammer, but otherwise I'll use something more friendly with a more focused design.

More sweeping statements and hand waiving. In your view what's the better language and why?

I'm not religious about this stuff, but I think that, in general, private inheritance *does* mean "implemented in terms of".

Sure, and if you read my posts you'll find that I'm not necessarily opposing that view (from an OO modeling perspective).

[nuzzle]

I thought this discussion was about understanding all the nuances of protected/private inheritance.

Yes it's about inheritance. The statements you're referring to were replies to BigEd781 and his sweeping statements about C++. I think he's totally wrong and I didn't want to let it pass unchallenged.

Even if you view inheritance from a strict OO perspective (which you really cannot because C++ is multi-paradigmic) there's no particular reason to avoid private inheritance. It can be used to your advantage without any problems at all as long as it's used for implementation convenience only (read code sharing) and as long as the public overall design is done by the book, namely that

- base classes are abstract interfaces, and
- derived classes abide with the Liskov substitution principle.

Tight coupling and brittleness are design issues, not language issues. You can have them in C++ programs but also in Java or C#. They're not resolved by banning language constructs. They're resolved by proper usage of the constructs at your disposal.