这种写法的劣势在哪，是不是个人习惯

控制反转，内部服务由外部提供，降低耦合

挺好啊，没啥劣势吧

哪天admin login的时候需要用到 FileLog 并且user login要保持DatabaseLog

补充一下，是跟这种写法比较，他俩是不是一样的 :sweat_smile:

class User 
{
    protected $log;

    public function __construct(Log $log)
    {
        $this->log = $log;   
    }

    public function login()
    {
       public function login(Log $log) {
          echo "登录成功";
            $this->log->write();
       }   
    }
}

$user = new User(new DatabaseLog());
$user->login();

很常规的写法

基于接口，而非实现编程

劣势就是要写的代码更多了...

码农的人习惯问题，对服务器来说没什么特别的，都是0/1在跑。 :joy:

接口编程的坏处

1. IDE代码跳转不方便， 需要去看依赖找实现类
2. 容易过度设计，让本来清晰的逻辑复杂化

从长远的角度考虑，后期比较没有bug

@cvoid 复杂的项目基于接口反而更清晰，更灵活吧

之后如果想用另一种方式记录日志，可以很方便地切换。

我觉得是一样，注入的时机不同而已

方便切换实现方式吧

基于接口的开发 这种比较适合于 后期会换不同实现方式或者直接替换的 需求，主流程不变 而需要改变的仅仅是具体的实现方式而已！ 优势就是 替换具体的实现类 简单方便 ，缺点就是代码量上去了 容易过度设计！

@Nines 我自己认为抽象的优势在于无限横向扩展，相同情况不同实现。 但是我自己在写业务的时候发现需求逻辑多变情况一直在变化，抽象反而在肘制自己。

在某些功能需求十分明确的情况下代码会比直接实现清晰很多 类似支付登录分享之类。

这是我目前的理解，抽象不是万金油，只是有适用场景。

@cvoid 确实更依赖与现实需求，经常变动的业务层不适合，那些 支付，oss，短信之类的可以