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

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是一种以有意义和现实的方式分离逻辑的好方法,但它也可以达到对可维护性产生负面影响的程度,并且在这一点上它被错误地应用.

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

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

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

最后,要小心代码味道.

Answer 2

从一般观点来看,具有太大或相反的类太小都被认为是不好的做法并且被称为所谓的代码嗅觉.这两个我指的是大班(又名神对象)和懒惰类(又名吃白食).

以下是维基百科和编码恐怖片的定义:

大班:一个变得太大的班级.

像长方法这样的大类很难阅读,理解和排除故障.班级是否包含太多责任？大班可以重组或分成小班吗？

和

懒惰的课程:一个做得太少的课程.

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

另一方面,面向对象设计的原则称为接口隔离原则,该原则指出"客户不应该被迫依赖于他们不使用的方法".在您的情况下,具有较少方法的接口实际上符合此原则.

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

有关SOLID的更多信息,面向对象的设计原则可以在维基百科上找到.

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