However in certain cases, you need to change what Step2() is, but not break up the process. You don't want outside callers to access Step2() directly, but you need a way to allow a subclass to define it's own Step2() while keeping the overall process intact.
So you would make those three methods protected (and, depending on language, virtual) and override as needed in a subclass.
That's the use case I've used protected for.
Also, I may want to do things internally inside my package/module/library that I want to be able to internally override, but not make it part of my API in case I want to change it later.
"protected" would allow you to modify a member of a class when you inherit from it, whether it is in the same module or not.
using "internal" or "public" with a comment saying "please only use this when you subclass" the class is not as neat and tidy.
Honest question: Why would you ever want to use multiple inheritance? It seems like an awful design pattern.
I mean, in C++, you basically just end up with a more confusing equivalent to Java interfaces.
You can also do a layering-up type thing, where you have a base class that implements particular functionality, and inheriting from particular classes surfaces it or restricts it in particular ways.
You may find yourself having a set of UIViewControllers that implement overlapping subsets of the features that your app provides (i.e. one controller has features A and B, another has features B and C, a third has features C and A).
One method of solving this is to create helper modules that implement the features A, B, and C. In your controllers, you can then set up the appropriate subset of helper modules. There are a few problems with this: 1) there's still boilerplate code; 2) the implementation can be subtle (make sure to retain the reference to all your helper classes!).
This can be elegantly solved with Objective-C categories (by creating a category for each feature) or, I imagine, what multiple inheritance would look like in Swift. Instead of boilerplate helper module initialization and subtle implementation, your ABUIViewController could inherit from abstract AUIViewController and BUIViewController base classes to get both features for free in virtual methods.
[1]: http://srcreigh.github.io/blog/posts/modular-uiviewcontrolle...
You basically want to add public methods addEventListener(), removeEventListener() and a protected fireEvent() method. In Java you have no problem inheriting the interface for these methods. However you want to manually re-implement the damn implementation in each class that vends interface. I can't remember how many times I wrote these...
In C++ with multiple inheritance you can inherit both the interface and implementation, and you're done. It is one step further than Java interfaces.
These days, I don't use that so much and I would not miss multiple inheritance. I prefer to implement the design pattern observer through signals (boost::signal in C++, custom classes in JavaScript/TypeScript). C# delegates provide a good solution for this problem too.
I have not touched Java since 1.4, so maybe there is a more elegant way to solve this now...
Better to make protocols fast.
[0] http://blog.human-friendly.com/swift-access-controls-are-lik...
In the saner practice, however, you want to develop subsystems where the classes that are the part of the subsystem cooperate to the common goal, not protect themselves from their peers (some "OO" C++ language lawyers are certainly already offended by my claim). Even if some class is in charge for something, it's easier when more classes can at least see some pieces of the data without making a lot of getters and setters "just because."
http://docs.oracle.com/javase/tutorial/java/javaOO/accesscon...
My impression is that people often simply don't know exactly what the default modifier does, whereas they're more confident in the behaviour of public and private.
But if you're interested in ACLs in OpenStack Swift, http://swift.openstack.org/overview_auth.html is a good place to start.
(all tongue in cheek)
Yes, it is unfinished. I'd rather have Apple do what it's doing -- i.e., releasing Swift as a beta and changing things with feedback -- than do the opposite, which would be keeping it closed until it was super polished as they felt it internally.
I hate seeing this "damned if you do, damned if you don't" scenario all the time.
(1) Pre-release for feedback, get complained at for it not being finished.
(2) Polish and release later on, get complained at for not opening it up earlier for public feedback and testing.
Apple has clearly stated that it's pre-release, that it's not set in stone yet, and that they're open to feedback (which they have been).
Despite being backed by Google, regardless of how finished or unfinished Go was upon release, there was no impending pressure that you would someday more or less be forced to rewrite all your existing code in it. Thus the early adopter pros and cons were pretty clear.
This is not the case with Swift. At least if you take Apple at face value, Swift is the future of the ecosystem, which creates kind of a confusing landscape. Whether or not you should be writing your new app in Swift is a hard question. Whether you should just stand in the sidelines and not bother until Swift is more settled is a hard question. Swift is simultaneously in early adopter phase and industry requirement. As such, it is more than a little strange (arguably bordering on irresponsible) to make such a huge announcement when most of your own framework teams had never even seen or tried the language. I don't think there would have been any harm in getting internal feedback from your primary consumers before drawing a line in the sand to the general public.
