java 23种设计模式，一般情况下，常用的有哪些啊？
工厂模式， 工厂方法模式，单例模式， 外观（Facade）模式， 观察者（Observer）模式，桥接（Bridge）模式都是比较常用的，不同的项目有不同的设计方向，可以参考的设计模式也不尽相同，没有定数，只是上面这几个模式用的比较多一些。
java开发中都用到了那些设计模式?用在什么场合？
设计模式很多，但总的来讲分为4大类，creationalpatterns，通常是隐藏对象的new进程，通过专门的类来具现对象。
structuralpatterns，根据类的层次关系和接口来设计。
behavioralpatterns根据对象间的通讯来设计J2EEpatterns.重视于表现层设计每类都有很多种。JAVA战狼班
有人说设计模式是为了弥补Java语言的缺陷，你觉得是这样吗？
看你从哪个层面来看待设计模式！
语言层面
如果你从语言层面来看设计模式，那么这个说法可以说是对的。有部分设计模式是弥补了Java语言上的不足，最明显的就是单例模式。
在Java中本身没有提供单例对象的创建，需要通过单例模式来实现，什么饿汉式，懒汉式，多线程下还要关注DCL，volatile关键字等等，衍生了很多的面试题。
而在现代语言中，很多都提供了创建单例对象的语法，比如Scala,Kotlin的object关键字。
代码设计层面
如果从代码设计层面来看，设计模式提供了一套可复用的代码结构，来解决特定问题。比如，当需要动态化某些可选部分时，可以使用策略模式。当需要一组操作来顺序操作某个对象时，可以使用职责链模式。
架构层面
从架构层面来看，设计模式对组件关系进行了解耦。
假设我们要实现一个文件服务器，有一个UploadService来进行上传操作，可以调用ConvertService对文件进行转换。UploadService属于核心模块「上传模块」，而ConvertService属于非核心模块「转换模块」。
如果UploadService直接去调用ConvertService来执行转换，那么核心模块就依赖了非核心模块。如下图：
非核心模块是相对不稳定的，核心模块是相对稳定的。核心模块依赖了非核心模块会导致核心模块也不稳定。所以可以使用策略模式来解耦：
看箭头的方向，现在转换模块依赖于上传模块，转换模块的变化不会影响上传模块。依赖方向改变了，这就是传说中的「依赖倒置」！
作为一名专注于科技领域的程序员，我来回答一下你的这个问题。
我引用Steve Yegge在《程序员的呐喊》中关于设计模式的一段评论：
设计模式提供了23个漂亮的盒子，帮你整理你的衣柜，外加一系列扩展机制，好让你自己定义新盒子。对我们这些衣柜像狗窝一样，几乎没有盒子、袋子、隔板或者抽屉的人来说，设计模式真是大救星。我们只要改建一下屋子，把衣柜扩大4倍，眨眼之间它们就能变得和百货商店的货架一样干净了。
。。。
然而，设计模式本身不是特性。工厂不是特性，委托、代理、桥接也都不是，它们只是提供了漂亮的盒子，以松散的方式来转载特性。但是别忘了，盒子、袋子和隔板自己也是要占用空间的。设计模式也不例外。
变大是Java中无法回避的东西。Java就像是俄罗斯方块，不过积木和积木之间的空隙都填不满，结果只能越堆越高。
虽然《设计模式》的写作是对广大程序员的一记响亮的耳光——假设这个世界上只有C++和Java程序员。
Java语言虽然使用率高，但是其本身是有一定的缺陷的，就是啰啰嗦嗦。
有时候真的觉得Java是一个啰啰嗦嗦的女朋友。一个简单的功能，就比如hello world，她也要整出一大坨代码才能在控制台中输出这十个广大程序员熟悉的字符。
然而，设计模式在编程思想层面提供了一定的编程方式，就比如六大基本原则，以及诸如工厂模式、观察者模式、装饰模式等等。
这些设计模式虽然并不能够降低微观的代码量，但可以减少大量相似功能编写的重复，这就能够实现DRY原则，毕竟，重复是导致bug的一大原因。
最后，没有任何一种程序语言是完美无瑕的。
你可以说，php是世界上最好的程序语言。当然，如果你只会php，那么我会很同情的看着你，就像都德的《最后一课》中那位老师告诉我们法语是世界上最美的语言。
语言接触的多了，才能横向比较各个语言的优点和缺点，在哪些应用场景适用，哪些有欠缺。你可以说脚本语言的灵活以及在调用外部应用上的开发快速，也可以说静态语言的稳重、安全。
设计模式也一样，它不是设计来弥补某种语言的缺陷与不足，而是跳开特定的开发语言，在更高层次上去探讨应用程序的构建，以使得年轻的程序员们有一条快速构建应用程序的参考路径和设计范例。
当然，任何的模式都是可以打破，也是用来打破的。就像数据库设计中的范式，在特定场景需要通过反范式进行设计和规划。
加油吧，编程设计，在人工智能的奇点到来之前，还有相当长的路要走。
谢谢。
还没有评论，来说两句吧...