oop - 糟糕的 OOP 有很多只有 1 或 2 个方法的类

Question

如果你有很多类，其中只有 1 或 2 个方法，这是否是糟糕设计的标志？

我正在尝试学习 OOP 设计并创建了一个小型应用程序(很小)。

它最终得到了很多实现接口(interface)的类，这些接口(interface)只包含 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 是一种以有意义和真实的方式分离逻辑的好方法，但它也可能达到对可维护性产生负面影响的程度，并且在那时它被错误地应用。

想想应用程序的去向。它总是会是一个小应用程序吗？如果是这样，您不需要创建很多非常通用的接口(interface)。尝试将它们结合起来，如果只有一个类实现了接口(interface)，你也许可以完全删除接口(interface)。

如果您预计您的应用程序会大幅增长，那么这些接口(interface)实际上可能会帮助您在 future 维护和添加功能。例如，如果您创建了一个应用程序来管理一个只有汽车 parking 位的 parking 场，如果您预计会增长到不同类型的车辆(例如摩托车只占用一半 parking 位)，您可能希望创建一个通用汽车界面。也就是说，您不应该试图在项目开始时涵盖所有可能的需求变化，并使代码过于抽象。衡量需求变化的风险可以帮助您预测需要抽象哪些代码。

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

最后，小心code smells .