PHP-OOP扩展了两个类？

我是OOP的初学者，现在我正在尝试编写一些PHP类来连接FTP服务器

class ftpConnect {
  private $server;
  private $user;
  private $password;

  private $connection_id;
  private $connection_correct = false;

  public function __construct($server, $user = "anonymous", $password = "anonymous@mail.com") {

    $this->server   = $server;
    $this->user     = $user;
    $this->password = $password;

    $this->connection_id      = ftp_connect($this->server);
    $this->connection_correct = ftp_login($this->connection_id, $this->user, $this->password);

    if ( (!$this->connection_id) || (!$this->connection_correct) ){
        echo "Error! Couldn't connect to $this->server";
        var_dump($this->connection_id);
        var_dump($this->connection_correct);
        return false;
    } else {
        echo "Successfully connected to $this->server, user: $this->user";
        $this->connection_correct = true;
        return true;
    }
  }
}

我认为目前这个班的人数微不足道

主要的问题是我在理解OOP思想方面有一些问题

我想在每次代码运行时添加发送电子邮件。我已经下载并扩展了我的课程：

class ftpConnect extends PHPMailer {...}

我已经添加了一些变量和方法，所有的工作都如预期的那样

我想：为什么不在数据库中添加存储所有内容的功能呢。每次用户运行上述代码时，都应该在数据库中存储适当的信息

我可以编辑我的

ftpConnect类

，添加连接到构造函数的数据库，以及一些其他方法来更新表。但是数据库连接和所有这些东西将来都可以被其他类使用，所以它肯定应该在单独的类中实现。 但是我的“main”

ftpConnect类已经扩展了一个类，不能再扩展一个

我不知道如何解决这个问题。也许我的
ftpConnect类
太复杂了，我应该把它分成几个小类？
非常感谢您的帮助。
这可能是一个组合而不是继承的问题
看到这个了吗
只需在类中使用mailer对象，DB也是如此，而不是扩展它们中的任何一个

class my_class
{
    private $mailer;

    public function __constructor()
    {
         $this->mailer = new Mailer();
    }
}

首先，我认为你们班上有一个设计缺陷。你的构造器正在工作。在适当的OOP中，构造函数不应该这样做。构造函数应该只设置属性，并且应该有一个单独的方法
connect（）

第二个
ftpConnect
永远不能扩展
PHPMailer
。它们是两个完全不同的东西。阅读有关的信息，这是的一部分

如果类需要处理数据库或发送邮件，则需要将这些实例注入到类中，而不是扩展它们。这将被调用，这将使以后进行单元测试变得容易，因为您可以轻松地使用模拟邮件器类或模拟数据库类

如果您想发送邮件、访问数据库并使用FTP，则至少需要3个不同的（分开的）类（可能需要更多的类来为数据库等进行映射）。基本上每个班级都应该有一个职责，而且只有一个职责。这就是所谓的

有关一些一般参考资料，请参见：




您正在创建所谓的God对象，它是一个单独的对象，负责一大块（或整个）应用程序。那不好。每个对象都应该有一个单一的责任，就是这样。要邮寄吗？有一个不同的对象。要保存到数据库吗？有一个不同的对象。您可以通过构造函数或方法相互传递引用来连接它们。这叫做依赖注入。查一查。独立的专业对象很好，就像我们不希望大学教授教授所有大学科目一样。这是一个好的开始，但使用@PeeHaa建议的依赖注入可能是一个更好的主意。