你好！

这是个很好的问题，很多人都问过我。网站中确实包含了书中的所有模式。我原本可以在本书发布后减少免费内容，但是我特意决定不这样做。我希望这不会显得是自我夸耀，但并非所有人都有能力购买本书，而我不希望他们因此无法获得这些知识。

与此同时，除了我对你为本项目做出支持表示真挚感谢之外，购买本书后你还将获得一些实际的功能。

额外内容（深入设计模式）：

• 本书包含介绍面向对象程序设计和统一建模语言（UML）主要术语的章节。其重点关注对象是初学者，但从我的个人经验来讲，即便是经验丰富的编程老手也能从花时间来复习这些内容中获益。

• 本书重点讲解了模式所遵循的 8 个设计原则（包括 SOLID）。这部分和上述术语部分大约占本书 60 页（全书共 406 页）左右的篇幅。

• 本书还包括大量 C#、C++、Go、Java、PHP、Python、Ruby、Rust、Swift 和 Typescript 的代码示例，你可以用 IDE 来打开、编译和试用它们。

以下是电子书版本相对于网站的优势：

• 离线访问。你可将电子书下载到手机或平板电脑中，这样即使在没有互联网连接时（比如在度假小屋、海滩、地铁和飞机上时）也能随时阅读。

• 阅读进度记录。大部分电子阅读设备和应用都能记录你的阅读进度，让你能从上次离开的位置继续阅读。如果你利用工作休息或通勤的零碎时间进行学习的话，这会很有帮助。当在网站上阅读时，你必须自己记住读到了哪里。

• 夜间模式。当前绝大多数电子阅读设备和应用都提供夜间模式（亮色文字和深色背景），这让你能非常方便地在床上进行阅读。为了优化本书在深色背景上的显示效果，我可是花了不少精力（夜间风格，特别是图像和图表的边框）。


我想你或许还有一些关于重构课程的问题。它不是一本电子书，你需要在浏览器中进行学习。以下是该课程的额外内容列表：

额外内容（深入重构）

• 实际示例。每种重构技巧的扩展示例。每个示例都会逐步演示如何清理“丑陋”的代码。

• 完成证书。你可在简历中包含证书来提升简历的含金量。

其他优势：

• 课程是简单的线性结构，可保存你的学习进度。这种学习方式比在网站上到处“晃悠”要更能发挥你的专注力。

• 购买了课程的用户可以随时在论坛上向我提出任何关于课程资料的问题。

• 最后，你用真金实银支持自己学习的事实将激励你完成课程。人们通常不会认真对待免费的东西，从而无限期地推迟学习。

无论如何，我希望这些解答能对你有所帮助。如果你有进一步的问题，请随时告诉我，我非常高兴能够为你提供帮助。

祝一切顺利，
亚历山大·什韦茨

Hi!

Thanks, I think this all looks like good old guard clauses:
https://refactoring.guru/es/replace-nested-conditional-with-guard-clauses

Hi!

Thank you for letting me know! It's a shame that the author did such a blatant steal. I'll pass it on to my Chinese lawyers, we'll see what we can do. Thank you!

Дякую за пропозицію! Додам в TODO.

Hi!

Yes, it should work just fine. I'm not sure what the problem might be.

Yurii, the patterns are certainly not part of the math domain—sadly, none of their definitions or features are set in stone, 100% provable, etc. The patterns weren't created from scratch; rather they have been discovered. The original GoF authors over the course of their careers observed 100 codebases with similar code, and they got the idea that in these 100 codebases programmers were driven by the same problem and produced more or less the same code. So, they thought maybe it would save time for any future programmer if we name such a problem and such a solution to this problem "an Adapter". In reality, of those 100 codebases, 90 may have been straightforward adapters, and the other 10 might have been something in between Adapter or Bridge. So now, you can pick and choose what pattern suits your needs, but if there's none, you can simply implement something on your own without using any pattern or create some sort of hybrid of multiple patterns and that would be totally okay. It would be just slightly harder to implement and explain to anyone else.

Hi Yurii!

They look similar to you because you think of them only in terms of implementation. They both are based on the composition principle, so they do look really close if you strip all the context and rename the classes to A, B, C. In fact, if you do the same with Strategy and some others, it'll also look pretty similar.

However, this is not the right way to think of them. A pattern defines not just some piece of code, but also an underlying problem. You don't recommend using Bridge when someone struggles with converting XML to JSON. Similarly, you don't recommend using Adapter, when people are about to write an abstraction layer over operating systems. The ability to communicate a complex idea using one name is an integral part of having these patterns.

There are other aspects as well, such as potential future vectors in which the classes can evolve in different patterns. When using Adapter, you usually assume that the thing that you adapt from isn't going to change much (hell, you might not have control over that code at all). However, the abstraction part of Bridge may be very actively developed.

Hope this helps!

Hi!

Suppose you have a Bridge hierarchy like this:

Abstraction: BasicFileSystem → VersionControlFileSystem

Implementations: Fat, NTFS, APFS

One of the abstractions (VersionControlFileSystem) can only work with a specific implementation (NTFS, APFS).

Instead of requiring client to know about this implication when instantiating Abstractions & Implementations, you could provide abstract factory to create necessary classes (and maybe even handle errors when non-existent pairs are requested). Below is a pseudocode:

interface FileSystemFactory {
    createBasicFileSystem() → BasicFileSystem
    createVersionControlFileSystem() → VersionControlFileSystem
}

class WindowsFileSystemFactory {
    createBasicFileSystem() → BasicFileSystem + Fat
    createVersionControlFileSystem() → VersionControlFileSystem + NTFS
}

class macOsFileSystemFactory {
    createBasicFileSystem() → BasicFileSystem + Fat
    createVersionControlFileSystem() → VersionControlFileSystem + APFS
}