Question

这是一个糟糕的设计标志，你有很多只有1或2种方法的课程吗？

我正在尝试学习OOP设计并创建了一个小应用程序（微小）。

最终有很多类实现只包含1或2个方法的接口。

感觉分离得很好，但是这些类的方法很少，这似乎很糟糕。

我知道每个场景都会有所不同，但从一般的角度来看这是不是很糟糕？

应用程序的一小部分确定喂狗的时间表（我知道跛脚）：

所以我试着在这里实施策略模式：

class DogFeedController
{
    protected $strategy = null;

    public function __construct(iDogFeedStrategy $strategy) {
        $this->strategy = $strategy;
    }

    public function getFeedingSchedule() {
        $morningFeeds = $this->strategy->generateMorningFeeds();
        $eveningFeeds = $this->strategy->generateEveningFeeds();       
    }

}


class GeneralFeedStrategy implements iDogFeedStrategy
{
    public function generateMorningFeeds() {
        //do stuff here
    }

    public function generateEveningFeeds() {
        //do stuff here
    }
}

Answer 1

如果太多，你必须自己衡量。 OOP是一种以有意义和现实的方式分离逻辑的好方法，但它也可以达到对可维护性产生负面影响的程度，并且在这一点上它被错误地应用。

考虑应用程序的去向。它总是会成为一个小应用程序吗？如果是这样，您不需要创建许多非常通用的接口。尝试将它们组合起来，如果只有一个类正在实现该接口，那么您可以完全删除该接口。

如果您预计您的应用程序将在财务上增长，那么接口实际上可能会帮助您在将来维护和添加功能。例如，如果您创建了一个应用程序来管理只有汽车停车位的汽车批次，您可能希望创建一个通用的汽车界面，如果您预计不同类型的车辆增长（例如摩托车只占用一半停车位）。也就是说，你不应该试图在项目开始时覆盖每个可能的需求变化，并使代码过于抽象。衡量需求变化的风险可以帮助您预测需要抽象的代码。

如果您是团队中的软件工程师，请绘制您的设计图并将其展示给您的同事以获取他们的意见。

最后，请注意code smells。

Answer 2

从一般观点来看，太大或相反的类太小都被认为是一种不好的做法，被称为所谓的 Code Smells 。我指的是大类（又名上帝对象）和懒类（又名 Freeloader ）

以下是Wikipedia和Coding Horror的定义：

大班：一个已经变得太大的班级。

大型课程，如长方法，难以阅读，理解和排除故障。班级是否包含太多责任？大班可以重组或分成小班吗？

和

懒惰的课程：一个做得太少的课程。

课程应该减轻他们的体重。每增加一个类都会增加项目的复杂性。如果你的班级不足以支付自己的费用，可以将其折叠或合并到另一个班级吗？

另一方面，面向对象设计的原则称为接口隔离原则，其中规定“客户端不应该被迫依赖于他们不使用的方法”。在您的情况下，具有较少方法的接口实际上符合此原则。

总结以上内容，您的设计非常正确。具有较少方法的接口是好的，因此实现这些接口的类不必实现所有方法以及它们不使用的方法。至于课程，我相信他们最终会变得更大。请记住，实现接口并不意味着您不能拥有比实现的接口中定义的方法更多的方法。也就是说，尝试在那里加入更多逻辑。

有关 SOLID 的更多内容，可以在Wikipedia上找到面向对象的设计原则。

PS。 Code Smells是设计糟糕的症状，SOLID就是治疗方法。

Answer 3

我认为你应该问自己的问题是。这个班级负责的是什么吗？能够识别和分离责任是OOP的基石。例如，您可以拥有一个只有一个创建随机密码的方法的Security类。

我认为（这是我的观点）如果随机密码仅用于寄存器，而不是创建该类的私有方法，我会将该方法分成新的类Security，因为我不认为这是Register类的责任。

此外，由于您的应用程序很小，因此每个类的方法很少是完全正常的。

<小时/> 修改：查看您的代码我可以提出一些建议，但请记住，我无法看到整个图片。

如果还没有，您应该阅读MVC pattern，您的应用程序可能没有视图，但将控制器与模型分离是一种很好的做法。

您的DogFeedController似乎是控制器，GeneralFeedStrategy是模型。我喜欢以他们的名字结束课程的名称。例如，UserController，UserView和UserModel。我认为这使事情变得清晰，但这又是我的看法。

我没有看到iDogFeedStrategy的重点，但是再一次，我没有看到整个图片。接口的基本用法是确保一组类（无论它们有多么不同）具有相同的 API 并封装实现接口的每个类的详细信息。

Answer 4

除了关注点分离之外，OOP的另一个重要方面是阶级凝聚力。班级应该“拉自己的重量”，而不是让许多其他东西称之为“吸气者”并对信息做些什么。如果您想要多态行为，或者您计划将来扩展应用程序，请创建接口。不要仅为了分离而创建接口。如果接口没有被两个或更多子类实现，那么就去掉它们。（您也可以使用接口来应用依赖性反转原则，以打破依赖性循环）

应始终使用OOP中的设计决策来有意识地解决特定问题。否则，保持简单。

Answer 5

喜欢大量具有复杂关系的小对象，只需要很少的大对象和简单的关系，因为这有利于可维护性，并且为将来的变化做好了更多的准备。

你的设计对我来说非常好，更考虑到你现在开始编程而且初学者总是反过来做。

坏OOP有很多只有1或2种方法的类

5 个答案: