用于分析、设计或架构的模式
经过多年在不同领域的分析、设计和编程
领域和架构，您可能遇到过一种“模式”或好的
尚未作为模式发布的实践（分析、设计或架构）。
尽管您之前已经做过很多次，但它没有名称。
对 SO 社区的模式感兴趣。
After spending many years of analysis, design and programming in different
domains and architectures, you have maybe come across a "pattern" or good
practice that haven't been published as a pattern (analysis, design or architecture).
Although you have done it many times before, it has no name.
Interested in patterns from the SO-community.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我曾经以为是我自己的，即“我发明的”，原来是20年前“发明”的。 我已经数不清有多少次我在不知不觉中意识到自己正在使用一种已经众所周知的设计模式。
这些都是多年来尝试解决同样问题的结果。 我想除非有人“发现”一个新的问题领域，否则你不太可能看到新的模式。
也许在未来，新的编程范例或技术将有助于发现解决相同老问题的新方法。
The ones I once thought were of my own i.e. 'I invented them', turned out to be 'invented' 20 years ago. I can't count how many times I realized that I was using an already well-known design pattern without knowing it.
Those are the result of many years of trying to resolve the same problems. I guess unless someone 'finds' a new problem domain you aren't likely to see a new pattern.
Maybe in the future, new programming paradigms or technologies will help uncover new ways of resolving the same old problems.
我自己还没有想出任何新模式，但发现新模式的最佳方法是了解所有现有模式。 这是我最喜欢的设计模式网站之一。 101 种设计模式。 特别要注意反模式。
I haven't come up with any new patterns myself but the best way to spot a new pattern is to know all the existing ones. This is one of my favorite design pattern websites. 101 Design Patterns. In particular, pay attention to the anti-patterns.
并不是什么新模式，但我经常使用工厂和策略模式的组合。 这可以防止工厂有 switch 语句，并且您可以使用新的“工厂策略”配置您的工厂。 我不确定这个模式是否有名字。 如果有人能告诉我，我将不胜感激。
我不久前在博客上谈到了这一点：http://www.herrodius.com/blog/136
Not really a new pattern, but I have often used a combination of the factory and strategy pattern. This prevents the factory from having switch statements and you can configure your factory with new "factory strategies". I'm not sure if this pattern has a name. If anyone can tell me, I would appreciate that.
I blogged about this a while ago: http://www.herrodius.com/blog/136
我认为几乎所有东西都被发明了不止一次，但是我一直使用但没有看到其他人使用我认为应该做的那么多的两种模式是：
不可复制的对象 - 大多数对象
问题域（示例：
银行账户、人员、交易）
不应该是可复制的，不像
实现域中的对象
（示例：字符串、数组、整数）。 我
因此利用语言特征
制作这样的业务域对象
不可复制。
拥有对象 - 一个对象，例如
BankAccount 拥有其交易。
当拥有的对象被销毁时，
它管理这些的破坏
拥有的对象。 这个图案好看
很大程度上消除了使用的需要
智能指针。
I think just about everything has been invented more than once, but two patterns that I use all the time but don't see others using as much as I think they should do are:
Uncopyable object - most objects in
the problem domain (examples:
BankAccount, Person, Transaction)
should not be copyable, unlike
objects in the implementation domain
(examples: string, array, integer). I
therefore use language features to
make such business domain objects
uncopyable.
Owning object - an object such as a
BankAccount owns its Transactions.
When the owning object is destroyed,
it manages the destruction of these
owned objects. This pattern pretty
much does away with the need to use
smart pointers.