Reputation: 6128
I have an app ready and running in the Google Play store, now i am implementing fragments.
so,i already have a class A which extends B with some methods, now i have class which C extends FragmentActivity, so now i need use the same methods as in class A but here since i am extending FragmentActivity i cannot make use of class B, so here there are duplicate methods which are same as class A but i need to reuse the methods.
This below example shows my situation:
Eg:
Current implementation
class A extends B{
one();
two();
}
After integrating fragments,
Eg:
class C extends FragmentActivity{
one();// same methods as in class A
two();// same methods as in class A
}
1) What is the best way to re-use the methods in this case and how?
2) I have approach in my mind like creating a class and make the methods as static and re-use the methods in both A and C class, but is my approach good and can i make the methods as static and is it a good approach ?
3) Another approach that i have thought of "Strategy Pattern".
Eg:
class A extends ApiClass {
private ClassContainingDupMethod strategy;
}
class N extends AnotherApiClass {
private ClassContainingDupMethod strategy;
public methodCallingDupMethod(){
strategy.dupMethod();
}
}
class ClassContainingDupMethod{
public dupMethod(){;}
}
Is the "Strategy Pattern". a good approach ? as i need to create object of common class in both the classes.
Any suggestions on this would be appreciated.
Upvotes: 10
Views: 2800
Reputation: 8284
Get rid of inheritance as much as you can. You don't need it. Class inheritance is almost always a bad idea, especially if you expect lots of future changes in your implementation. The only time it is really necessary is when a poorly designed framework requires you to extend some base class.
When reading the old design patterns from Gamma et al., bear in mind that they were written for a world where C++ and Pascal were the dominant OO languages. Java was still in its infancy and introduced a novelty (interfaces) that neither of those languages had. So, you should mentally replace a lot of the uses of extends with implements and you'll end up with better code.
Basically, keeping coherence high, and coupling low is a good idea in object oriented design. Class inheritance can easily lead to highly coupled classes with low coherence (lots of unrelated functionality in one class). The reason is that the base class ends up having functionality that is not needed by all sub classes, or code paths that are only relevant for some. Additionally, as your design evolves, you end with lots of classes that inherit from each other and are very tightly coupled. I personally hate having to deal with code with multiple levels of inheritance. It's hard to read and the semantics of inheritance make testing more painful as well. I never use extends other than for interfaces and I've been doing Java since the mid nineties.
@Babibu's suggestion of using composition and delegation is a much better alternative for this reason. It leads to more coherent classes that are much less tightly coupled. Easier to maintain, easier to recompose, easier to test, etc.
Upvotes: 2
Reputation: 1
Strategy Pattern or 'wrapper' is the best choice. And I think Juan Sánchez's solution is better than Babibu's one. As in Babibu's code, class A should not be dependent on D. Be dependent on an interface is better. In your code, if class A contains some attributes or some actions that class C doesn't need, you can refactor your code like below. Otherwise Juan's solution is enough. I've drawn an UML image for this situation, but I've no enough reputation to post it:-( Code is like this:
interface IAction
{
public void actionA();
}
class A extends B implements IAction
{
private IAction action;
public void actionA() {
action.actionA();
}
}
class C extends FragmentActivity implements IAction
{
private IAction action;
public void actionA() {
action.actionA();
}
}
class D implements IAction
{
public void actionA() {
// put implementation here
}
}
Upvotes: 0
Reputation: 1111
If you've got same methods in both fragments, why don't you use a BaseFragment class (which in turn extends FragmentActivity) and have all your common methods there. Then you can just extend this BaseFragment class in any class you wish to. This way, whatever methods you've got in BaseFragment can be just utilized without re-defining.
Upvotes: 1
Reputation: 139
You should start with what Babibu said - simple composition.
When you master this there are other technics too. For instance dependency injection looks like something that could be used here. Simple case would go something like this. Define interface B instead of a class B. Pass interface B as a parameter during initialization of C, have it as internal variable b and call b.one() and b.two(). You will have to create an object A that implements B outside of C scope and pass it in during activity C initialization. Advantage: C doesn't need to know how to create A, you can change it later to AA or AAA and never touch your activity again as long as AA and AAA implement B. You don't have to retest C.
Upvotes: 1
Reputation: 990
If you want to force the same API, you can try adding an interface to both A
and C
classes, while keeping an instance of A
as a field of C
. C
will act as a wrapper class of A
.
Class A
:
class A extends B implements CommonApi {
public void one() {
...
}
public boolean two() {
...
}
}
Class C
:
class C extends FragmentActivity implements CommonApi {
private A a;
public void one() {
a.one();
}
public boolean two() {
return a.two();
}
}
Upvotes: 3
Reputation: 17284
I suspect you have some utility methods, just put them inside a class Utils
, make them static and call them from wherever you want. I have lot of utility classes in my application like WifiUtils
, LogUtils
, NumberUtils
and so on.
Upvotes: 3
Reputation: 32221
Its more simple than you describe. All you need to do is create D like this:
public class D{
one();
two();
}
Change class A to use class D.
public Class A{
public D dLogic;
}
Same with class C.
public Class C extends FragmentActivity{
public D dLogic;
}
This is some thing very basic in object-oriented programming it call composition.
Upvotes: 15