使用Fragments时避免重复代码的最佳方法

我有一个应用程序准备好并在Google Play商店中运行,现在我正在实施碎片。

所以,我已经有一个类A扩展B的一些方法,现在我有类C扩展FragmentActivity,所以现在我需要使用相同的方法,在类A,但在这里,因为我扩展FragmentActivity我不能使用类B ,所以这里有重复的方法是相同的类A,但我需要重用的方法。

以下示例显示了我的情况:

例如:

目前的实施

class A extends B{ one(); two(); } 

整合碎片之后,

例如:

 class C extends FragmentActivity{ one();// same methods as in class A two();// same methods as in class A } 

1)在这种情况下重用这些方法的最好方法是什么?

2)我的思维方式就像创build一个类,使方法静态并重用A和C类中的方法,但是我的方法很好,我可以使方法成为静态方法,这是一个很好的方法?

3)我想到了“战略模式”的另一种方法

 Eg: class A extends ApiClass { private ClassContainingDupMethod strategy; } class N extends AnotherApiClass { private ClassContainingDupMethod strategy; public methodCallingDupMethod(){ strategy.dupMethod(); } } class ClassContainingDupMethod{ public dupMethod(){;} } 

“战略模式”。 一个好的方法? 因为我需要在这两个类中创build普通类的对象。

任何build议,将不胜感激。

Solutions Collecting From Web of "使用Fragments时避免重复代码的最佳方法"

它比你描述的更简单。 所有你需要做的就是这样创buildD:

 public class D{ one(); two(); } 

更改A级以使用D级

  public Class A{ public D dLogic; } 

和C类一样

 public Class C extends FragmentActivity{ public D dLogic; } 

这是一个非常基本的面向对象程序devise,它叫做组合 。

我怀疑你有一些实用的方法,只是把它们放在一个类Utils ,使它们成为静态的,并从任何你想要的地方调用它们。 我的应用程序中有许多实用程序类,如WifiUtilsLogUtilsNumberUtils等等。

如果要强制使用相同的API,则可以尝试向A类和C类添加接口,同时将A的实例保留为C一个字段。 C将充当A的包装类。

A类:

 class A extends B implements CommonApi { public void one() { ... } public boolean two() { ... } } 

C类:

 class C extends FragmentActivity implements CommonApi { private A a; public void one() { a.one(); } public boolean two() { return a.two(); } } 

你应该从Babibu所说的 – 简单的构图开始。

当你掌握这个还有其他的技术。 例如dependency injection看起来像可以在这里使用的东西。 简单的情况下会是这样的。 定义接口B而不是类B.在C初始化期间将接口B作为parameter passing,将其作为内部variablesb并调用b.one()和b.two()。 您将不得不创build一个对象A,它在C作用域之外实现B,并在作业C初始化期间将其传入。 优点:C不需要知道如何创buildA,您可以稍后将其更改为AA或AAA,并且只要AA和AAA实现B,就不会再触碰您的活动。您不必重新testingC.

如果你在这两个片段中都有相同的方法,为什么不使用BaseFragment类(反过来扩展FragmentActivity),并且在那里使用所有常用的方法。 然后你可以在你想要的任何类中扩展这个BaseFragment类。 这样,无论您在BaseFragment中获得什么方法,都可以在不重新定义的情况下使用。

策略模式或“包装”是最好的select。 我认为JuanSánchez的解决scheme比Babibu的解决scheme更好。 在Babibu的代码中,类A不应该依赖于D.依赖于接口更好。 在你的代码中,如果类A包含一些属性或类C不需要的一些动作,你可以像下面那样重构你的代码。 否则胡安的解决scheme就够了。 我为这种情况绘制了一个UML图像,但是我没有足够的声望来发布它:-(代码是这样的:

 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 } } 

尽可能地去除遗传。 你不需要它。 类inheritance几乎总是一个坏主意,特别是如果你期待在你的实现中有很多未来的变化。 唯一真正有必要的时候是devise不好的框架需要扩展一些基类。

在阅读Gamma等人的旧devise模式时,记住它们是为C ++和Pascal为主的OO语言编写的。 Java仍处于起步阶段,并引入了这两种语言都没有的新颖性(接口)。 所以,你应该在思想上取代扩展与实现的很多用途,你会得到更好的代码。

基本上保持连贯性高,耦合度低是面向对象devise中的一个好主意。 类inheritance很容易导致高度耦合的类的连贯性低(在一个类中有许多不相关的function)。 原因是基类最终具有所有子类所不需要的function,或者仅与某些子类相关的代码path。 另外,随着你的devise的发展,你会结束很多相互inheritance的类,这些类非常紧密地联系在一起。 我个人讨厌不得不处理具有多级inheritance的代码。 这很难阅读,inheritance的语义也使testing更加痛苦。 我从来没有使用扩展接口以外,我从九十年代中期以来一直在做Java。

@ Babibu的build议使用组成和委派是一个更好的select,因为这个原因。 它导致更紧密的类更紧密的耦合。 维护更容易,更容易重构,更易于testing等