What can you bring to your Activity with a combination instead of inheritance?

What can you bring to your Activity with a combination instead of inheritance?

• Original link: Composition over inheritance,what It means for your activities
• Original Author: Josh Brown
• Development technology Front www.devtf.cn
• Translator: Chaossss
• Reviewer: mr.simple
• Status: Complete

In fact, we have seen in many Java advanced books that "development should be more inclined to choose combinations rather than inheritance", why we suggest that we prefer rather than replace them completely , because when class A can completely replace another class B (we want B to be a Parent class), we should use inheritance, if a is just and B has some common behavior , it is not supposed to use inheritance (more discussion poke me). However, when I read other people's source code, the abuse of inheritance is too much, how many people created a baseactivity, let all activity inherit it, in the child Activity to implement business logic.

And this is a big problem, the most vivid example is: Joe Newguy joined our group, and realized the shinyfeatureactivity, there will be no rules in the group forced him to have shinyfeatureactivity inherit from Baseactivity, but he did it ... Fortunately, we found this problem in Code Review. In addition, if each activity is inherited from baseactivity, in some cases you may want to inherit other activity (for example: Preferenceactivity, listactivity). Although most of the activity's subclasses have corresponding Fragment instead, some of them do not have corresponding Fragment, and some libraries still need the corresponding activity subclasses.

Some of the more potential problems are that sometimes activities require these behaviors, other activities require other behaviors, and Java does not support multiple inheritance, which means that we have to put all the behavior of the activity with the intersection of behaviors into a separate class. But doing so reduces maintainability and even performance impact.

In fact, we're going to do this. The motivation is simple: code reuse. Indeed, code reuse is important. Most of our public logic needs to be implemented in a certain loop of the Activity life cycle. But Application.activitylifecyclecallbacks is a very painful thing, and may need to register it in the Application.oncreate () method, the most ironic: we try our best to avoid Register it in the Application.oncreate () method ...

This is also the origin of the unbound View Fragment, when countless Android developers think of Fragment as a UI component, in fact Fragment more like a lifecycle component. Why do you say these Fragment are unbound View? Because in the hands of these developers, Fragment's Oncreateview () method has neither been rewritten nor returned NULL. Essentially, Fragment is a component capable of handling or manipulating events, and it does not have a corresponding View on its own.

To differentiate between the Fragment of the unbound view and the view-oriented fragemnt, I named the unbound view fragemnt as * xxhelper*, and the others named xxfragment 。 For example, Analyticshelper represents the Fragment of the relational parsing logic, and Headerfragment displays a title bar. Of course, you can try to do this, you can ignore my advice, I feel full of useful ha ~

Because these unbound View Fragment have no UI components in them, it means that in these Fragment we don't have to think about the Layout-id needed to initialize the layout, or the animations that are needed for the view, so we can develop these Fragment in Factory mode, Improve the ease of use and maneuverability of factory methods. In this regard, they can also complete the operation of adding Fragment itself, I created a Gist to show you how to do, if you are interested, you can click to see Kazakhstan. If you use Android-studio for development, you can add it to the settings File and Code Templates option and then select it in the Kind drop-down option when you create a new class.

Adding Foohelper to its parent class is straightforward, as long as you call Foohelper.attach (this). However, if the corresponding parent class does not implement Foohelper's callback interface, a compilation error occurs, and if the Attach () method is already called, the return value of the method will be the previous Fragment. This Gist contains overloads for Fragment and Activity, and converts them to use supported Fragement and fragmentactivity, where the meaning is very large. And it also contains a simplified version of the Fragmentutils.getparent ()--getparent () method (Details stamp me).

Clearly, the Fragment of Unbound View is much more useful than baseactivity, and they encapsulate the process of requiring a lifecycle callback (or Onactivityresult (), Fragmentmanager). Best of all, we can decompose some of the logic of activity sharing into a single module component, where the activity requires logic and chooses what module to use. If most of your activity requires many of the same modules, then you have no reason not to implement commoncomponentshelper to handle these common logic, and you do not need to put all the shared dependencies of your activity into a single base class.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

What can you bring to your Activity with a combination instead of inheritance?