我们假设我们有一个分析应用程序(AppX),它允许导入和导出分析文件。我们希望在其中构建一些功能,以允许在企业协作平台中共享这些文件,但是我们使用两个不同的平台,比如Jive和Workplace。
虽然这有点主观,但是我想看看这个模型是否符合OO概念的惯例?
1 - 我们在interface CollaborationService
中定义了必须实现的方法才能实现完整功能。
2 - 我们有abstract class DefaultCollaborationService implements CollaborationService
对某些操作有一些默认实现。
3 - 我们有一个class WorkplaceCollaborationService extends DefaultCollaborationService
和一个class JiveCollaborationService extends DefaultCollaborationService
,每个都有自己的方法,它们会覆盖默认抽象类中的方法。
或..
这样做会更好:
2 - abstract class DefaultCollaborationService
- 注意,没有指向界面的链接,因此我们不必实施所有内容
3 - class WorkplaceCollaborationService implements CollaborationService extends DefaultCollaborationService
和class JiveCollaborationService implements CollaborationService extends DefaultCollaborationService
或..
所有这些都不对,你可以建议一个更好的方法吗?
答案 0 :(得分:1)
这是"自以为是"的边缘,所以让我们关注事实:
选项1(使用抽象基础上的接口)类应该是首选的:此类的整个目的是为接口方法的某些提供实现。您可以看到,当界面发生变化时,可能希望编译器告诉您必须查看基类中的实现。
请记住:您不必实施所有方法 - 您仍然可以保留那些无法在此级别实施的abstract
。
除此之外,你的方法似乎是合理的。
答案 1 :(得分:1)
让我们看一下整个模式,了解所需的实现和提供的服务。
class Use1 extends Base
@Override protected onA(X x) { }
@Override protected onB(X x) { }
class Use2 extends Base
@Override protected onA(X x) { }
@Override protected onB(X x) { }
abstract class Base implements Api
abstract protected onA(X x); // Requirement
abstract protected onB(X x);
public final a () { onA(x); } // Service
public final b () { onB(x); }
interface Api
public final a ();
public final b ();
第一种方法最适合这种情况。但是现在抽象类和接口的默认方法各不相同。
答案 2 :(得分:0)
如果您正在寻找面向对象的解决方案,那通常会关注您的业务领域的“事物”。我对这两个提出的解决方案的主要问题是,它几乎没有反映出你在第一段中描述的问题。
那么,让我们看一下您的问题域包含的内容:分析文件, Jive , Workplace ,并提及“ Platform “作为后两者的抽象。这些是第一段中提到的“事物”。
好的,那么我们需要照顾的“责任”(业务职能)是什么?你提到“分享”,所以让我们继续吧。
让我们把所有这些放在一起:
public interface AnalyticFile {
void shareTo(Platform platform);
}
public interface Platform {
void share(byte[] data); // Whatever data is necessary
}
public final class Jive implements Platform {
...
}
public final class Workplace implements Platform {
...
}
对于您提出的实际问题: