User.php

<?php

namespace DesignPatterns;


class User
{
    public $userId;
    public $userName;
    public $email;
    public $telephone;
    public $provinceOfAddress;//省
    public $cityOfAddress;//市
    public $regionOfAddress;//区
    public $detailedAddress;//详细地址
}

//这个类是否满足职责单一呢？
//一种观点，认为user类中包含的都是跟用户相关的信息，属性都是这个业务模型的，满足单一职责
//另一种观点，认为地址信息在user类中占的比重大，可以拆分成userAddress类，
//user类保留除地址信息之外的其他信息，这样职责才单一。

//如果用户的信息还跟物流信息挂钩，那么按照第二种观点拆分的才更加合理。
//从这个例子上可以看出来，评价一个类是否职责单一，
//都是在某些场景下或者未来的某个需求下。我们并没有⼀个⾮常明确的、可以量化的标准，
//可以说，这是件⾮常主观、仁者⻅仁智者⻅智的事情。
//实际上，我们也没必要过于未⾬绸缪，过度设计。
//我们可以先写⼀个粗粒度的类，满⾜业务需求。
//随着业务的发展，如果粗粒度的类越来越庞⼤，代码越来越多，
//这个时候，我们就可以将这个粗粒度的类，拆分成⼏个更细粒度的类。进行所谓的重构。