Design Patterns

仔细想了想。。没必要重复造轮子。 每天复习啥了就直接CTRL CV了 https://gitee.com/SnailClimb/JavaGuide/blob/master/docs/system-design/framework/spring/Spring-Design-Patterns.md# 控制反转(IoC)和依赖注入(DI) IoC(Inversion of Control,控制翻转) 是Spring 中一个非常非常重要的概念，它不是什么技术，而是一种解耦的设计思想。它的主要目的是借助于“第三方”(Spring 中的 IOC 容器) 实现具有依赖关系的对象之间的解耦(IOC容易管理对象，你只管使用即可)，从而降低代码之间的耦合度。 IOC 是一个原则，而不是一个模式，以下模式（但不限于）实现了IoC原则。 Spring IOC 容器就像是一个工厂一样，当我们需要创建一个对象的时候，只需要配置好配置文件/注解即可，完全不用考虑对象是如何被创建出来的。 IOC 容器负责创建对象，将对象连接在一起，配置这些对象，并从创建中处理这些对象的整个生命周期，直到它们被完全销毁。 在实际项目中一个 Service 类如果有几百甚至上千个类作为它的底层，我们需要实例化这个 Service，你可能要每次都要搞清这个 Service 所有底层类的构造函数，这可能会把人逼疯。如果利用 IOC 的话

原文地址： http://mrpeak.cn/blog/tcp-flow-control00/ TCP/IP 系列之 TCP 流控与拥塞控制（一） TCP 流控（flow control）与拥塞控制（congestion control），是我个人认为每个 iOS 工程师都应该熟悉的，价值含量极高的知识点。明白了三次握手，但是不了解流控和拥塞控制背后的设计原理，是不能够在简历上写「精通 tcp/ip」的。 Flow control 和 congestion control 的学习价值高，而且学习过程也会很有趣。掌握整个过程的意义，远超过学习 TCP 协议本身。 不少工程师在工作三五年之后，会尝试提升代码抽象和设计的能力，有些会刻意去读一些架构或者设计方面的书、文章，早些年的时候，流行研究 GOF 的 Design Patterns。这是一个方向，但我个人觉得，更高效可行的方法是研究经典的计算机问题。经典问题里所包含的设计思路，模块划分方式，架构处理等等，都凝结了无数前辈的智慧，理清楚整个流程，再扒一扒设计的细节，抽象的能力会自然而然的随之提升，这是内功心法方面的积累，比记住几个设计模式如何使用，意义要大的多。 TCP 流控和拥塞控制就是这样一个经典的计算机问题。流控机制和拥塞控制机制，也是学习 TCP 协议栈的精华所在。这两个机制又各自包含一系列其他设计，比如 sliding

Java书籍是程序员学习提升技能的重要学习渠道，通过书籍Java程序员可以学习当前流行、重要的相关技能。经典的书经受时间的考验，随着岁月的流逝变得越来越重要，让我们不断的学习和进步。 为了帮助大家更轻松的学好java开发，给大家分享一套java开发学习资料，小编推荐一个学java开发技术的学习裙；三七四三二零二八二，无论你是大牛还是小白，是想转行还是想入行都可以来了解一起进步一起学习！裙内有开发工具，很多干货和技术资料分享！ 接下来我们一起来看下学习Java的好书有哪些？ 1、《Head First Java》 《Head First Java》对于新手的程序员来说是很有效的。《Head First Java》涵盖类，对象，线程，集合和语言功能的基本Java编程知识，如泛型，枚举，变量参数或自动装箱，还有一些关于Swing，网络和Java IO的高级部分，这使它们成为Java初学者的完整包。如果你从头开始，这应该是你看的一本Java书。 2、《Head First Design Patterns》 关于继承和组合的，通过引入问题然后解决方案来促进改进实践。还包含有用的项目符号，练习和内存映射，可帮助快速了解设计模式。如果想学习核心Java设计模式和面向对象的设计原则，这是应该查看的一本Java书。 3、《Effective Java》 对于精通Java编程或经验丰富的程序员来说，

目录 设计模式——单例模式 1. 模式简介 2. 实例1-窗口的单例模式 3. 实例2-读取配置文件(懒汉式) 4. 重构实例2-对创建实例操作加锁 5. 重构实例2-饿汉式 6. 重构实例2-静态内部类 7. 单例模式的扩展-有上限的多例模式 8. 总结分析 9. 参考及源码 shanzm-2020年4月8日 22:37:28 1. 模式简介 单例模式（Singleton Pattern） ：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。 实现单例模式的方法：私有化构造函数，添加一个静态的字段保存类的唯一实例，并提供一个访问该实例的静态方法GetInstance() 单例模式分为两种：“懒汉式单例模式”和“饿汉式单例模式”。 懒汉式单例模式 ：第一次调用创建对象的方法GetInstance()时创建类的单例对象 饿汉式单例模式 ：类加载的时候创建单例对象 单例模式UML如下： 2. 实例1-窗口的单例模式 2.1 背景说明 示例源于《大话设计模式》，示例中完整源代码 下载 创建一个WinForm项目，其中有一个 FromParent 窗口，该窗口作为其他的子窗口的容器 在 FromParent 窗口中有一个菜单栏，其中有一个ToolBox按钮，点击该按钮创建一个 FromToolBox 子窗口 现在要求 FromToolBox 子窗口一次只能创建一个。

当然我们在平时的使用过程过程中，都是使用redis来做分布式缓存，而且一般在业务逻辑中，接口这种命中率比较低，而且还要考虑缓存淘汰算法的选取，所以一般应用不多。但是spring既然有这么个功能，我们就来看看，这里参照前辈的 Spring5-Design-Patterns 来写这篇博客。 这里需要使用@EnableCaching注解来开启缓存，然后之类还需要一个缓存管理器，这里使用ConcurrentMapCacheManager，这个实现后续再看。 这里再使用@CachePut("accountCache")来标记这个缓存，但是我看这里面的注解选项，好像没有缓存时间，然后我们就可以使用啦 输出： 可供选择的有这些，简单介绍三种： value (也可使用 cacheNames) : 可看做命名空间，表示存到哪个缓存里了。 key : 表示命名空间下缓存唯一key,使用Spring Expression Language(简称SpEL,详见参考文献[5])生成。 condition : 表示在哪种情况下才缓存结果(对应的还有unless,哪种情况不缓存),同样使用SpEL 这里主要使用的有三个注解： @Cacheable 主要针对方法配置。能够依据方法的请求參数对其结果进行缓存 @CachePut 主要针对方法配置，能够依据方法的请求參数对其结果进行缓存，和 @Cacheable

已关闭 。 这个问题是基于意见的。 它当前不接受答案。 了解更多 。 想改善这个问题吗？ 更新问题，以便通过 编辑此帖子 以事实和引用的形式回答。 去年 关闭。 我正在设计一个简单的基于Web的应用程序。 我是这个基于Web的领域的新手，我需要您提供有关设计模式的建议，例如如何在Servlet之间分配职责，创建新Servlet的条件等。 实际上，我主页上的实体很少，而与每个实体相对应，我们几乎没有添加，编辑和删除等选项。 早些时候，我为每个选项使用一个Servlet，例如Servlet1用于添加实体1，Servlet2用于编辑实体1，依此类推，这样我们最终拥有大量的Servlet。 现在，我们正在更改设计。 我的问题是，如何正确选择如何选择servlet的责任。 每个实体是否应该有一个Servlet，它将处理所有选项并将请求转发到服务层。 还是应该为整个页面设置一个servlet，它将处理整个页面请求，然后将其转发到相应的服务层？ 同样，请求对象是否应该转发到服务层。 #1楼 我使用了 struts 框架，发现它相当容易学习。 使用struts框架时，网站的每个页面都会包含以下项目。 1）每次刷新HTML页面时，都会调用使用的操作。 该操作应在首次加载页面时填充表单中的数据，并处理Web UI与业务层之间的交互。 如果使用jsp页面修改可变的Java对象

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 很久以前我读过一篇文章（我相信一篇博客文章），它让我在命名对象的“正确”轨道上：非常谨慎地命名程序中的东西。 例如，如果我的应用程序是（作为一个典型的业务应用程序）处理的用户，公司和地址，我有一个 User ，一个 Company 和一个 Address 域类-也许某处 UserManager ，一个 CompanyManager 和 AddressManager 会弹出一个手柄那些事。 所以，你可以告诉那些 UserManager ， CompanyManager 和 AddressManager 吗？ 不，因为Manager是一个非常通用的术语，适用于您可以对域对象执行的任何操作。 我读过的文章建议使用非常具体的名称。 如果它是一个C ++应用程序，并且 UserManager 的工作是从堆中分配和释放用户，那么它将不会管理用户，而是保护他们的出生和死亡。 嗯，也许我们可以称之为 UserShepherd 。 或者， UserManager 的工作可能是检查每个User对象的数据并以加密方式对数据进行签名。 然后我们有一个 UserRecordsClerk 。 现在这个想法一直困扰着我，我尝试应用它。 并且发现这个简单的想法非常难。 我可以描述这些类的功能和（只要我不进入快速和脏的编码）我写的类只做 一