2

我很困惑应该在类中包含什么类型的方法以及应该在服务类中编写什么类型的方法？

这是我的场景：

我正在编写一个音乐商店应用程序，我的模型设计如下

 public class Album
{
    private string title;

    public string Title
    {
        get { return title; }
        set { title = value; }
    }

    private double price;

    public double Price
    {
        get { return price; }
        set { price = value; }
    }

    private List<Music> musicFiles;

    public List<Music> MusicFiles
    {
        get { return musicFiles; }
        set { musicFiles = value; }
    }


}

public class Music
{
    private string title;

    public string Title
    {
        get { return title; }
        set { title = value; }
    }

    private string duration;

    public string Duration
    {
        get { return duration; }
        set { duration = value; }
    }

}

用户可以进行这样的操作：

  1. 下载整张专辑或一些特定的音乐文件；
  2. 删除本地文件；
  3. 将专辑添加到收藏列表；
  4. 从收藏列表中删除专辑。

我应该将诸如 Dwonload 之类的方法放在模型中还是另一个服务类中？如果我把它们放在模型中，模型应该引用其他一些类。我目前的解决方案是：

解决方案1：创建IDownload/IFavorite接口，让模型实现，方法包含在模型中；

解决方案2：创建一个抽象类，包含下载操作和收藏操作相关的所有属性；让模型从抽象类继承；创建 DownloadService 类和 FavoriteService 类来实现操作的细节，传递如下参数：

AbstractClass obj1 = new MusicFile();
AbstractClass obj2 = nwe Album();

哪种解决方案是明智的，还是有其他解决方案？

谢谢！

4

2 回答 2

1

还可以更好地调用您的音乐神器下载，因此您可以更改或添加新的神器，而无需更改下载调用者界面。这是我对问题的理解。

请考虑这是伪代码，并使用正确的语法编写您自己的 java 代码。

//Client call

DownloadStore  store  = new DownloadStore(myMusicfile)

store.download();

DownloadStore  store  = new DownloadStore(myAlbum)

store.download();


//your download store
DownloadStore {

IMusicArtifact artifact;

DownloadStore(IMusicArtifact  artifact){
  this.artifact=artifact;
}

public downlod(){

//write common coding for any artifact...

//artifact specific implemenation is called here
artifact.download();

}

}


//your interface class
IMusicArtifact {

download();

}


//your concrete class
Muscifile implements IMusicArtifact {


download(){
// Music file related downloaind stuff
}

}


//your concrete class
Album implements IMusicArtifact {

download(){
// Album related downloaind stuff
}


}
于 2014-02-24T10:08:56.697 回答
0

我认为最干净的解决方案是一个专门的服务类，例如“Downloader”。如果 Download 是一个经常使用的操作，您可以在音乐文件类或其基类中引入一个外观，以提高代码的可理解性。

您的问题是将下载方法放在接口中还是放在抽象基类中的答案取决于您认为如何使用这些操作。例如，如果您访问下载操作主要是作为一种能力，例如您想下载很多东西并且并不真正关心这些项目是什么，那么界面是最佳选择。这样做的原因是接口不会限制您的继承层次结构，而抽象基类可以。

如果您可以跨多个文件共享操作的实现，那么抽象基类是很好的。因此，如果下载专辑与下载音乐文件的代码相同，则具有共享实现的抽象类更合适。

通常，您根据对象执行某些操作的能力来使用对象，并且这些操作的实现确实是共享的。在这种情况下，最好的方法是使用一个接口和一个包含共享代码的单独抽象基类。这样，您可以同时使用接口和抽象基类的优点。如果您查看 BCL，例如在 ADO.NET 中，很多概念都是以这种方式实现的。

于 2014-02-24T09:40:45.463 回答