Darling912的博客

如果不熟悉 Java 语言，你可能会觉得，i1 和 i2 值都是 56，i3 和 i4 值都是 129，i1。创建 Integer 对象的时候，如果要创建的 Integer 对象的值在 -128 到 127 之间，会。会创建一个全新的对象，也就是说，i3 和 i4 指向不同的 Integer 对象，所以 i3==i4。不过，String 类的享元模式的设计，跟 Integer 类稍微有些不同。是指向不同的 Integer 对象，所以通过“==”来判定是否相同的时候，会返回 false。

（这个地方当我们使用了序列化进行加锁的相关的操作的时候，这个时候就违背了我们在使用Java中的并发编程的优良的相关的特点，这样就会是个我们处理相关的应用的速度极大的减慢）这样的话当我们去面对着大量的请求的时候，这个加锁之后，我们所形成的相关的请求就会分解开来，这些请求也会去排成一队，分别的去进行相关的处理。始化好了，所以，instance 实例的创建过程是线程安全的。从名字中我们也可以看。事实上，恶汉式的写法在工作中反而应该被提倡，面试中不问，只是应为他简单。懒汉式相对于饿汉式的优势是支持延迟加载，具体。

1. 创建型模式（Creational Patterns）：这类模式主要关注对象的创建过程。多个logger实例，在多个线程中，同时操作同一个文件，就可能产生相互覆盖的问题。这样的话我们就可以把这个原本我们所要输出的相关的信息方法这个我们所制定的文件当中。当然，加锁是一定能解决共享资源冲突问题的，我们只要放大锁的范围从【this】到。一个对象（或者实例），那这个类就是一个单例类，这种设计模式就叫作单例设计模。线程同时往并发队列里写日志，一个单独的线程负责将并发队列中的数据写入到日志。

始化好了，所以，instance 实例的创建过程是线程安全的。事实上，恶汉式的写法在工作中反而应该被提倡，面试中不问，只是应为他简单。多人觉得饿汉式不能支持懒加载，即使不使用也会浪费资源，一方面是内存资源，一。有饿汉式，对应地，就有懒汉式。以上的写法本质上是有问题，当面对大量并发请求时，其实是无法保证其单例的特点。饿汉式不支持延迟加载，懒汉式有性能问题，不支持高并发。会再进入到加锁逻辑中了。所以，这种实现方式解决了懒汉式并发度低的问题。的，很有可能会有超过一个线程同时执行了new Singleton();

1. 创建型模式（Creational Patterns）：这类模式主要关注对象的创建过程。3. 行为型模式（Behavioral Patterns）：这类模式主要关注对象之间的通信。logger实例，在多个线程中，同时操作同一个文件，就可能产生相互覆盖的问题。Logger实例也就失去了意义，如果工程要求我们所有的日志输出到同一个日志文件。事实上这样加锁毫无卵用，方法级别的锁可以保证new出来的同一个实例多线程下可。事实上这样加锁毫无卵用，方法级别的锁可以保证new出来的同一个实例多线程下可。

它的核心思想是：一个对象应该。Demeter，LoD）是一种有助于降低类之间耦合度的原则，但过度地应用迪米特法则。为了遵循 "不该有直接依赖关系的类之间，不要有依赖"原则，我们可以引入抽象来解。这种实现符合 "有依赖关系的类之间，尽量只依赖必要的接口" 原则，降低了类与类。每个模块只和自己的朋友“说话”（talk），不和陌生人“说话”（talk）。"不该有直接依赖关系的类之间，不要有依赖"这个原则强调的是降低类与类之间的耦。"有依赖关系的类之间，尽量只依赖必要的接口"这个原则强调的是，当一个类需要依。

由于代码长度的过短，实现的相关的功能过于简单，使得我们没有感觉到dry的简单性，但是当我们所实现的功能真的变的强大的时候，这样的调用方法真的很减少很多我们敲代码的数量，这样的会使得我们的代码变得简单的很多。在这个例子里面我们就去调用这个相关的函数，把这个原本应该去输出两遍的这个输出的相关的函数，保证我们去调用我们实现的这个方法就会使得我们的代码调用的变得更加简练和美观。是符合某些原则的，在其他场景下就是不符合的，我们学习了dry原则，不能狭隘的。然而，并不是所有看起来相似的代码都违反了 DRY 原则。

而且我们应该去调用原本在Java之中的相关的库，这样也会去减少我们在编写程序的时候，减少程序出现相关的bug的可能。其中，KISS 原则比较经典，耳熟能详，我们就从kiss原则入手。的条件语句代替 if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的。3. 注释和文档：为复杂的代码逻辑编写清晰、详细的注释和文档，解释代码的作用。的时候，同事对你的代码有很多疑问，那就说明你的代码有可能不够“简单”，需要优。在编写代码时，应避免使用复杂的逻辑、算法和技术，尽量保持代码简洁明了。

这个地方例如在我们的tomcat中，我们到高层模块的tomcat并不会直接去依赖于我们在模块所引入的相关的jar包。在这个例子中，我们将高层模块 AudioPlayer 和低层模块 MP3Decoder 解耦，使。Tomcat 就是高层模块，我们编写的 Web 应用程序代码就是低层模块。何实现了servlet规范的应用程序，同时我们编写的servlet实现（web）工程也可以。按照之前的划分原则，现在，我们可以在订单处理模块中依赖 PaymentService 接口，而不是具体的实。用于计算形状的面积。

不相关的接口，一类是 update()，一类是 output() 和 outputInPlainText()。上，KafkaConfig 只需要实现 update() 接口，并不需要实现 output() 相关的接口。同理，MysqlConfig 只需要实现 output() 相关接口，并需要实现 update() 接口。同理，SimpleHttpServer 只依赖跟查看信息相关的 Viewer。口，而是设计一个大而全的 Config 接口，让 RedisConfig、KafkaConfig、

LSP原则就是告诉我们对于当我们要去实现相关的方法的时候，我们不仅要去仅关注于当前方法的实现，我们还去关注对于这个方法相关的有关联的的方法，以及对于这个方法中的可以去继承的子类方法和相关调用进行继承的父类的方法。其实上这样的方法也是可以的，只是说不推荐，我们有时候也会去抛出一些相应的异常，这样的话也会产生相应的作用。这里我们把这个对mysql数据库的相关的操作进行分类的实现，这样更加保证了我们的代码的可读性和复用性。当我们在类中实现一个相应的控制类的时候，我们就可以去直接在这个类中进行一个方法继承。

这样的话对我们在实现了相关的功能之后对于后期进行相关的维护的时候，是十分的不方便的之后我们在后期进行相关的功能的进行相应的添加的时候，这个时候对于我们这个类中所实现的相关的方法就变的越来越庞大，使得我们这个代码的可读性和可修改性变得十分的糟糕。在开发实现相关的代码的过程中，我们可以去使用这个ArrayList去实现我们的相关的功能，但是为什么我编写代码的习惯却是使用。其实这样的代码把相关的实现功能做成了一个个的相关的接口，这样就会使得我们的方法在街口调用之后进行这个生成和重写，更加灵活。

在这个类中所形成的相关的方法之间的关联度上，两者之间的关系是十分的密切的时候，是可以去放置在这个同一个类中的，当我们，去根据业务之间的相关的关系和实现的时候，我们发现两个的关系是拆分起来进行相关的方法的实现是更加的方便的时候，我们就可以去对这个类中的方法去分解开来，还有前面所述的命名方法。这个原则不仅适用于类的设计，还可以扩展到其他设计方面。在我们初次学习面向对象的时候，这个代码是在我们眼中感觉十分的正确的，而且这段代码的开发是十分的方便的，使用idea上的相关的生成器就可以去简化我们开发的相关的时间的。

导的code-review后直接将我的代码推翻，来来回回，不停修改，知道“领导他”满意。严，很多程序员都是“由着性子写代码”，属于管理，降低了对代码的审核要求。候，这并不是坏事，有些“交差性”的项目，这样做确实很快，很舒服。之前，初入职场，很简单的一个功能，花了好久才写完，但是令我崩溃的是，经过领。项目是一个认真的、需要迭代的项目，这样做简直就是给自己挖坑，所谓的【屎山】我痛定思痛，决定只要我负责的项目，一定要严格规范，合理设计，然而完成这些，好的代码应遵循相应的编程规范，包括命名规范、代码格式规范等。