Inheritance and base functionality

I'm trying to make a simple MVP framework for my Android work. I'm having to annotate with @CallSuper to ensure children implementing override-able methods don't disturb the base functionality. Does this example look OK or is there a better way to accomplish this?

Edit: I suppose I could make start() and stop() final and then have them call private onStart() and onStop() methods for the children maybe? Nope, private methods are not inherited, so then I have an encapsulation problem

...that's how encapsulation and inheritance work. Not to sound like a complete arsehole (Which I probably do), but if you don't understand how inheritance and encapsulation work, you might need to do a bit more reading first because this is going to get very messy for you.

...that's how encapsulation and inheritance work. Not to sound like a complete arsehole (Which I probably do), but if you don't understand how inheritance and encapsulation work, you might need to do a bit more reading first because this is going to get very messy for you.

And this is one of the basics of OO programming.

Not at all, that's very fair. It looked wrong so I just wanted confirmation I was doing it wrong. I'll go do some reading, OOP is an area I'm very poor on.

(My incorrect thinking was as it was an abstract class they might be)

Yes but I think it's important that @Cursorkeys gets a notification about how terrible he is.

@cursorkeys I'm not so up to date on my Android development but from what I remember of Java, you're more or less on the right track (using implements, no body in abstract methods, etc) but there are actual Java developers in here who will know the right direction for you to take (unlike me)

I did some reading, making the superclass start()/stop() methods final and then having protected onStart()/onStop() methods for the children gives me the functionality and visibility I want. I don't need @CallSuper any more and I think it looks much better.
I will keep reading tutorials until it all sinks in properly!

I did some reading, making the superclass start()/stop() methods final and then having protected onStart()/onStop() methods for the children gives me the functionality and visibility I want. I don't need @CallSuper any more and I think it looks much better.
I will keep reading tutorials until it all sinks in properly!

@cursorkeys Maybe I didn't read carefully enough, but if all you need is to call a parent class's method from the override, why not just use super.method(...)?

That was the problem as I saw it. The child would have to call super., things would break if they didn't. I can enforce that in Android with a @CallSuper annotation so they get a compile-time error if they don't, but it seemed inelegant.

I think this is better because things calling the subclasses can now only see the superclass start() and stop() and the subclass gets it's own onStart() and onStop() to override if it needs to extend anything (and anything other than the subclass can't call those by mistake).

Yes but I think it's important that @Cursorkeys gets a notification about how terrible he is.

ExampleContract.View weakView = mWeakView.get(); was the main reason I was complaining about Java not having type inference. I have a lot of this bit of code in the Presenters and it's a shame you can't write var weakView = mWeakView.get();

Yes but I think it's important that @Cursorkeys gets a notification about how terrible he is.

But yeah, you've got the pattern. You would just integrate a framework, annotate with @Inject and replace calls to new with constructor arguments. Plus you'd get rid of the @NonNull annotations and checks because your injector would fail to initialize if it couldn't resolve a way to make a concrete implementation.

Good idea, I've changed it. It originally was a normal View, then I realized why the lifecycle was getting stuffed up and jammed a WeakReference in there without changing the constructor for some reason.

Of all the OOP cruft that came out of the 90-ies and 2000-s, that's the most useful pattern IMO.

90% of Dependency Injection is just a hacky Java solution to a bad Java architectural problem. (Which, unfortunately, the CLR guys copied.) Proper metaclasses would eliminate or massively reduce most cases where DI is needed.

90% of Dependency Injection is just a hacky Java solution to a bad Java architectural problem. (Which, unfortunately, the CLR guys copied.) Proper metaclasses would eliminate or massively reduce most cases where DI is needed.

No. DI (or IoC in general) is much more useful than some JAVA thing. I am using it in places that have nothing to do with Java or OOP in general.

ExampleContract.View weakView = mWeakView.get(); was the main reason I was complaining about Java not having type inference. I have a lot of this bit of code in the Presenters and it's a shame you can't write var weakView = mWeakView.get();

Why not just use view? Inside that function, weakView is going to be identical to view anyway.

ExampleContract.View weakView = mWeakView.get(); was the main reason I was complaining about Java not having type inference. I have a lot of this bit of code in the Presenters and it's a shame you can't write var weakView = mWeakView.get();

Why not just use view? Inside that function, weakView is going to be identical to view anyway.

Inside that particular function there was no good reason, it was an artefact of originally just having a View and then realising there was a problem and changing the class member variable to a WeakReference and stuffing it in to that constructor.
After @JazzyJosh pointed it out I've refactored that properly.

Yes but I think it's important that @Cursorkeys gets a notification about how terrible he is.

Please do not confuse Dependency Inversion (the principle which was formalized in that time frame) with the specific technique of Dependency Injection (what most tools do).
The former is valuable in the vast majority of cases [nothing is ever 100%], the latter can often be problematic and be much more complex than a simple implementation which achieves the principle.

I get that. IoC and DI are colloquially often treated as synonyms, so I used the term in that manner.

My javascript app is certainly not going to use the same IoC mechanism as an app written in a fully OOP language.

@cartman82 - Pretty sure you "Get it", so I am posting for other readers...

Without DIP [Inversion], a piece of code needs some other resource, it creates it [typically calling "new xxxx(...)" in most languages)..
With DIP, in the same situation the determine of what to create is somewhere (anywhere) outside the class instance needing the resource.

DI [Injection] uses either the constructor parameters or properties to pass the instances....

However replacing the "new X(.....)" with "Something::GiveMeAnX(....)" is a minimal (completely valid) DIP