为什么C/C++团队较少用设计模式说话，而Java团队却乐此不疲

Question

为什么C/C++开发人员很少明确用设计模式的思想交流，而Java开发人员非常重视用设计模式的“官话”进行交流？这是近期有人问我的问题。

一些激进的观点是C不适合做大的工程，只能捣鼓小程序，所以遇不到复杂的设计场景。这显然是片面的。在C中，同样会遇到涉及类似生产者、消费者吞吐、线程追随、轮询等等场景。只是较少看到C项目文档中出现“基于代理模式模式实现了数据缓冲器向A模块的功能传递”的论述。

其实不光是C，强大一点的C++也类似。开发者在面试时，也很少被专门问到设计模式的问题。C开发者在交流时不喜欢用设计模式的官话，而会用具体语境来交流，比如：“信号量sWatermark在水位达标瞬间被激活，触发UDP队列处理。线程Dealer会处理1/4水位以上的所有数据。”。

反倒是Java开发人员会非常重视用设计模式的官话来交流，比如“这个类库采用了适配器模式解决与你们平台的兼容性问题”。我觉得这是一种良好的习惯，使得双方很快就能理解问题的全貌。设计模式是对程序员经验的总结，进行归纳后形成的方法论。使用这种方法论指导开发工作，能够迅速帮助程序员成长。

谁知道这是为啥子呢？

Answer 1

我感觉你的理解是片面的。
首先，C 是面向过程的程序设计，语言的本身就注定了无法想C++、Java 那样通过灵活的对象来进行各种引用，到后面我们也可以看到C 中struct 也慢慢的偏向了C++ 风格，在struct 中添加一些函数指针，方便struct 的指针变量进行引用，这些在kernel 中尤为明显。
另外，所谓的设计模式设计针对的是面向对象的一种程序设计，四人组的设计模式其实是基于C++ 开发，不知道我看的书是不是盗版，里面是实例大多数都是C++ 实例。
用原文的话：

The design patterns in this book are
descriptions of communicating objects and classes that are customized to solve
a general design problem in a particular context.

e. The standard way to inherit an interface
in C++ is to inherit publicly from a class that has (pure) virtual member functions.
Pure interface inheritance can be approximated in C++ by inheriting publicly from
pure abstract classes. Pure implementation or class inheritance can be
approximated with private inheritance.

那，之所以说你片面，其实我的理解是，当我们在进入C++ 开发之前，都会花费大量的时间在设计上面，流程的设计、功能的设计、代码设计、测试模块的设计等等，只有搞定了这些前提，才是我们开发人员动笔的时刻。而这期间的代码、框架绝对离不开设计模式，好的设计模式会为后期的测试、维护等留下很多的可能的buffer。
所以，无论是C++、Java 对于设计MVC 相关的、或面向对象相关的，在开发过程中都离不开设计模式。。。
此上，只代表个人的鄙见，也希望路过的大佬一起来探讨~~~但勿喷，心理防线差~~~