定义类之间的正确关联关系

时间:2012-03-02 13:52:51

标签: php uml associations class-design aggregation

在我正在开发的模块中,我尝试将需求建模为具有正确关系的类图。

要求:

  1. 该模块将连接到一组ftp服务器并下载一些文件。
  2. 模块将解析每个文件以生成一组发票。
  3. 所以我创建了4个类File,Ftp&分析器。现在我想我应该让File类能够download()parse()本身。

    class File{    
     private   $supplier;
     private   $status;
     private   $fileName;
     private   $fileId;
    
        function __construct($supplier){
            $this->supplier=$supplier;
        }
    
       function downloadFile(){
           $ftp= new Ftp($this->supplier);
           $this->fileName=$ftp->download();
       }    
    
      function parseFile(){
          $parser= new Parser($this); // The parse needs the fileName in addition to the supplier info to parse the file correctly.
          $parser->parse();
      }
    
      function saveFileInfoToDB(){
      //Save file Info to db.
      }
    
    }
    

    因此,每当我需要下载文件时,我都会执行以下操作:

     class ServiceInvoker{
    
     function downloadFilesFromFtpServers(){
         foreach($suppliers as $supplier){
    
        /*$supplier here is an object containing all data needed to download a file 
        from that certain supplier filled from the database 
        (i.e. ftpUsername, ftpPassword, ftpHost, SupplierName, supplierFileType).*/
    
         try{
         $file= new File($supplier);
         $file->downloadFile() 
         $file->saveFileInfoToDB(); 
          }catch(Exception $e){
           //log error
           }
    
       }
      }
    
    }
    

    您可以清楚地看到,要下载文件,我必须在不同的对象中进行多个下载调用。

    我认为问题主要是因为我认为File类应该能够自行下载,因此我在File类本身中实例化了一个Ftp对象。

    当我尝试解析文件时会发生同样的情况,因为我需要将$this传递给解析来获取文件的信息。

    我认为Ftp类应该直接在ServiceInvoker中传递给Supplier的对象,并且如果进程成功下载该文件,则返回File对象。

    现在我应该如何正确识别Ftp Parser和File之间的关系? File应该包含解析器对象还是解析器本身应该包含File对象并直接从服务调用者调用?我可以清楚地将Parser和File类之间的关系标识为Association。 Ftp和文件类之间相同但谁应该包含谁?

1 个答案:

答案 0 :(得分:1)

在我看来,你应该重新考虑文件的责任。可以下载文件,但它不是文件的责任。

我的意思是类File应概述文件的属性和职责。下载文件的责任应该放在DownloadManager或somehing中。

在[SOLID design principle中可以找到一些指导应用程序的重要指南,该原则的起源可以在Uncle Bob

的论文中找到。

它为您提供了五条指导原则,为您提供一种松散耦合,易于维护和重复使用的设计。有关此主题的资源很多。