I dont know if its just my negative thinking about that design-pattern megahype which leads to absolute nonsense behaviour (personal opinion insight), but:
You should not ask yourself "what Design-Pattern could fit for that XYZ type of application i want to code".
This is the absolute wrong way of doing things. Design-Patterns are no lego-blocks which you assign to a program you code. A pattern will naturally evolve in the specific domain.
If you know patterns, it may help you to see what might be a good solution. But in no way you pack some patterns together just for the sake of it.
Patterns for a mmplayer is really a bad question. You might say you need different codecs for the same tasks, wich might evolve in Factory pattern in THAT SPECIFIC DOMAIN. You might want some streaming functionality with some fault tolerance, wich might evolve in a leaky bucket counter.
You might rethink your question. I think it doesnt make sense at all to ask that.
Really, no offense! But i think you are going into the wrong direction in sense of design-decisions. It might be the best to approach it in a different way.
A media player is a whole application. There is no such thing as a "design pattern" for an entire application.
However, some families of softwares (say, video games) almost always share some common architectural properties. But we are at the application architecture level here, not at the design pattern one, which is commonly considered as a code level concept.
I'm afraid there is no reference architecture for a media player kind of application, but yet, you can rely on many different and less specific architectural principles. For example, designing a composite application is quite a general practice. You'll find a lot of dedicated literature about how to create a plugin system that can load module, or codec, etc.
Audacity is a popular sound recorder and audio editor. It is a capable program while still being easy to use. The majority of users are on Windows but the same Audacity source code compiles to run on Linux and Mac too.
发布评论
评论（3）
我不知道这是否只是我对设计模式大肆宣传的负面想法，这会导致绝对无意义的行为（个人观点见解），但是：
您不应该问自己“什么设计模式适合我想要的 XYZ 类型的应用程序”代码”。
这是绝对错误的做事方式。设计模式不是您分配给您编写的程序的乐高积木。模式会在特定领域自然演变。
如果您了解模式，它可能会帮助您了解什么是好的解决方案。但绝对不能只是为了将一些模式组合在一起。
mmplayer 的模式确实是一个糟糕的问题。您可能会说，您需要不同的编解码器来完成相同的任务，这可能会在特定领域中以工厂模式发展。您可能需要一些具有一定容错能力的流功能，这可能会在漏桶计数器中发展。
你可能会重新考虑你的问题。我认为这样问根本没有意义。
真的，无意冒犯！但我认为你在设计决策方面走错了方向。以不同的方式处理它可能是最好的。
I dont know if its just my negative thinking about that design-pattern megahype which leads to absolute nonsense behaviour (personal opinion insight), but:
You should not ask yourself "what Design-Pattern could fit for that XYZ type of application i want to code".
This is the absolute wrong way of doing things. Design-Patterns are no lego-blocks which you assign to a program you code. A pattern will naturally evolve in the specific domain.
If you know patterns, it may help you to see what might be a good solution. But in no way you pack some patterns together just for the sake of it.
Patterns for a mmplayer is really a bad question. You might say you need different codecs for the same tasks, wich might evolve in Factory pattern in THAT SPECIFIC DOMAIN. You might want some streaming functionality with some fault tolerance, wich might evolve in a leaky bucket counter.
You might rethink your question. I think it doesnt make sense at all to ask that.
Really, no offense! But i think you are going into the wrong direction in sense of design-decisions. It might be the best to approach it in a different way.
媒体播放器是一个完整的应用程序。整个应用程序不存在“设计模式”这样的东西。
然而，某些软件系列（例如视频游戏）几乎总是共享一些共同的架构属性。但我们现在处于应用程序架构级别，而不是设计模式级别，设计模式通常被视为代码级别概念。
恐怕没有针对媒体播放器类型的应用程序的参考架构，但是，您可以依赖许多不同且不太具体的架构原则。例如，设计复合应用程序是一种非常普遍的做法。您会发现很多关于如何创建可以加载模块或编解码器等的插件系统的专门文献。
A media player is a whole application. There is no such thing as a "design pattern" for an entire application.
However, some families of softwares (say, video games) almost always share some common architectural properties. But we are at the application architecture level here, not at the design pattern one, which is commonly considered as a code level concept.
I'm afraid there is no reference architecture for a media player kind of application, but yet, you can rely on many different and less specific architectural principles. For example, designing a composite application is quite a general practice. You'll find a lot of dedicated literature about how to create a plugin system that can load module, or codec, etc.
您可以查看 Audacity 架构，并在同一域中看到良好的软件设计：http:// /www.aosabook.org/en/audacity.html
You can take a look at the Audacity architecture and see a good SW design at the same domain: http://www.aosabook.org/en/audacity.html