怎样对这个代码进行解耦？

wyman25 2010-11-26 10:46:15

我现在有一个音乐播放器歌曲选择的需求：
播放器中选择歌曲的方式有三种：1.按本地目录选择 2.按歌星选择 3.按歌曲分类选择 4.按排行榜top50选择 5.新歌top50选择。
因为以后可能有其他选择方式，所以有必要在这里对代码解耦。看上去可以应用策略模式来实现：客户端依赖某个接口IProvideSongs,然后具体的选择方式则实现该接口。
但是遇到一个问题：这些选择方式有些需要传入参数（例如“按本地目录选择”要依赖于用户指定的目录路径，而“按明星选择”则依赖于传入的歌星姓名），有些则不用传入参数（如“排行榜top50选择”和“新歌top50选择”已经指定了top50，而不是top100或者其他，所以不用传入任何参数），而且需要传入参数的选择方式中，参数的性质也不同（例如“按本地目录选择”是传入路径，而“按歌星选择”是传入人名），也就是说客户端还与具体的选择方式有干系。下图是草拟的UML图：

很明显客户端(client)对具体的“选择方式”的依赖又搞得代码耦合到一团了。但具体的“选择方式”有的确需要等待客户端传入一些参数...这样的情况应该怎样设计代码才好？

...全文

339 18 打赏收藏转发到动态举报

写回复

用AI写文章

18 条回复

切换为时间正序

请发表友善的回复…

发表回复

wolftop 2010-11-26

打赏
举报

工厂和代理。将参数的信息再次封装。另外提供个静态方法用于构造参数。总之必须先将参数所需信息和client解耦。再用静态方法Get参数对象

wyman25 2010-11-26

打赏
举报

策略模式和抽象工厂都无所谓，具体哪个模式不要紧，关键是解决客户端（client）对具体选择方式的依赖问题。
如果按理想的情况应该是客户端只依赖IProvideSongs接口，而不用关心具体的“歌曲选择方式”，也就是说client和具体的歌曲选择方式是没有耦合的。但现在因为具体的“歌曲选择方式”所需的参数各有不同，因此需要client具体对待，因此就造成了client又和具体选择方式打上了交道。

xuejiyong0619 2010-11-26

打赏
举报

帮忙顶上去。。

浪子-无悔 2010-11-26

打赏
举报

设计模式的抽象工厂模式难道不能满足楼主的需求吗？

消失的尘芥 2010-11-26

打赏
举报

不要说得这么高深和专业化嘛，其实就是多个条件下可能发生的事件。

指间的风 2010-11-26

打赏
举报

IProvideSongs上加一个传入类型的参数 ,和一个数值参数。

例如类型类型 =1 代表 Top = 数值参数
类型类型 =2 代表明星名称 = 数值参数

porschev 2010-11-26

打赏
举报

占个位。。。

lovehooho 2010-11-26

打赏
举报

我知道降低耦合的方法是使用抽象工厂模式

那个抽象类只需提供接口就是了

wyman25 2010-11-26

打赏
举报

是一个C/S的。操作是这样：比如用户是需要播放他本地某个目录下的mp3文件，则在界面上按“播放本地文件”，就弹出目录选择对话框，确定后就列出这个目录的所有mp3文件。如果他要播放"刘德华"的歌，则点击刘德华的头像，歌曲列表就自动列出刘德华的歌，如果是点击“新歌top50”，列表就自动列出top50新歌...

lovehooho 2010-11-26

打赏
举报

是b/s结构的吗？如何实现数据的传递？

wyman25 2010-11-26

打赏
举报

现在可以看图了

wyman25 2010-11-26

打赏
举报

卧草，看不到图了...

mooniscrazy 2010-11-26

打赏
举报

lz的依赖点放在哪里没有想好，所以才会困惑。
依赖点都是放在工厂。无论哪种接口，最终肯定是从一个工厂的静态方法生产出来。
Factory生产interface。
这个例子比较简单，用静态工厂就可以了。
依赖项，是不同的选择方法，可以把它作为工厂方法的参数。
设计模式是为了应变。那么需要知道的是，将来会怎么变。
这里的变化就是增加新的策略。把这个变化的项，交给工厂来处理就可以了。