- 博客(189)
- 收藏
- 关注
RSS订阅原创 000.JAVA BIO编程
JAVA BIO:同步并阻塞（传统阻塞型），服务器实现模式为一个连接分配一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理如果这个连接不做任何事情就会导致比必要的线程开销。因此，当连接数量达到上限时，如果再有用户请求连接，直接会导致资源瓶颈，严重的可能会直接导致服务器崩溃。大多数情况下为了避免上述问题，都采用了线程池模型，也就是创建一个大小固定的线程池，如果有客户请求，就从线程池中获取一个空闲的线程来处理。当客户端处理完操作后，就会释放对线程的占用。
2024-08-27 15:13:52
300
1
原创 设计模式之装饰器模式
动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（消除重复代码 & 减少子类个数）。通过采用组合而非继承的手法， Decorator模式实现了在运行时 动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免 了使用继承带来的“灵活性差”和“多子类衍生问题”。Decorator类在接口上表现为is-a Component的继承关系，即 Decorator类继承了Component类所具有的接口。
2024-05-07 14:57:42
848
原创 设计模式之策略模式
定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序(稳定)而变化（扩展，子类化）。Strategy及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。Strategy模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。如果Strategy对象没有实例变量，那么各个上下文可以共享同一个。
2024-04-29 16:12:21
359
原创 设计模式之模板方法
Template Method模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性）为很多应用程序框架提供了灵活的扩展点，是代码复用方面的基本实现结构。虚函数的多态性：虚函数的多态性可以理解为一种机制，通过该机制，程序在运行时能够基于对象的实际类型来选择调用哪个函数版本，而不是在编译时确定Java中的虚函数允许子类重写（Override）继承自父类的方法，从而实现多态性（polymorphism）
2024-04-29 09:16:51
917
2
原创 设计模式之创建型模式总结
定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法模式使得一个类的实例化延迟（目的：解耦）到子类。提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类使用原型实例指定创建对象的种类，然后通过拷贝这些原型来对象。将一个复杂对象的构建与其表示相分离，使得同样的构建过程（稳定）可以创建不同的表示（变化）值对象模式一种在面向对象编程中常见的设计模式，它主要用于封装一组值，使其可以通过值进行比较来判断两个对象是否是同一个对象。而不是通过引用来判断。
2024-04-25 14:36:38
1294
原创 设计模式之值对象模式
值对象模式一种在面向对象编程中常见的设计模式，它主要用于封装一组值，使其可以通过值进行比较来判断两个对象是否是同一个对象。而不是通过引用来判断。
2024-04-25 14:35:21
272
原创 设计模式之原型设计模式
Prototype 模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些“易变类”拥有“稳定的接口”Prototype 模式对于“如何创建易变类的实体对象”采用“原型克隆”的方法来做，使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象 — 所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方 clonePrototype 模式中的 clone 方法可以利用某些框架中的序列化来实现深拷贝。
2024-04-25 14:26:46
1091
原创 设计模式之分步构建模式
（分步构建模式）是一种创建型设计模式，它是链式建造者模式的进一步扩展，能够按步骤实例化对象通过分离稳定部分和变化部分，分步构建模式提供了一种灵活的方式来构建复杂对象。稳定部分保证了构建过程的稳定性和一致性，而变化部分则允许用户根据具体需求来定制构建过程。这种分离使得代码更加清晰、可维护和可扩展。
2024-04-25 14:05:39
530
2
原创 设计模式之建造者模式
Builder模式主要用于"分布构建一个复杂的对象",在这其中"分步骤"是一个稳定的算法,而复杂对象的各个部分则经常变化。变化点在哪里，封装哪里；Builder模式主要在于应对"复杂对象各个部分"的频繁需求变动。其缺点在于难以应对"分步骤构建算法"的需求变动。
2024-04-25 13:55:55
545
原创 设计模式之依赖注入模式
依赖注入是一种软件设计模式，其中一个或多个依赖项（或服务）被注入或通过引用传递到一个依赖对象（或客户端）中，并成为客户端状态的一部分。该模式将客户的依赖关系的创建与其自身的行为分开，这使程序设计可以松散耦合，并遵循控制反转和单一职责原则。
2024-04-25 11:20:11
1226
1
原创 设计模式之抽象工厂模式
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类如果没有应对"多系列对象构建"的需求的变化，则没有必要使用抽象工厂模式，这时候使用简单工厂完全可以"系列对象"指的是在某一特定系列下的对象之间有相互依赖、或作用的关系。不同系列的对象之间不能相互依赖抽象工厂模式主要在于应对"新系列"的需求变动。其缺点在于难以应对"新对象"的需求变动。
2024-04-25 10:26:40
835
原创 设计模式之转换器模式
转换器模式的目的是提供相应类型之间双向转换的通用方法，允许进行干净的实现，而类型之间无需相互了解。此外，Converter模式引入了双向集合映射，从而将样板代码减少到最少。
2024-04-19 18:10:24
293
原创 06.消除过期的对象引用
当程序员第一次被类似这样的问题困扰的时候，它们往往会过分小心：对于每一个对象的引用，一旦程序不再用到它，就把它清空。其实这样做即没必要，也不是我们所期望的，因为这样做会把程序代码弄得很乱。清空对象引用应该是一种例外，而不是一种规范行为。消除过期引用最好的方法是让包含该引用的变量结束其生命周期。如果你是在最紧凑的作用域范围内定义每一个变量(第57项)，这种情形就会自然而然地发生。那么，何时应该清空引用呢？Stack类的哪方面特性使它易于遭受内存泄漏的影响呢？简而言之，问题在于，
2024-04-02 17:24:04
423
原创 05.避免创建不必要的对象
不要错误地认为本项所介绍的内容暗示着“创建对象的代价非常昂贵，我们就应该尽可能地避免创建对象”。相反，由于小对象的构造器只做很少量的显示工作，所以，小对象的创建和回收动作是非常廉价的，特别是在现代的JVM实现上更是如此。通过创建附加的对象，提升程序的清晰性、简洁性和功能性，这通常是件好事。
2024-04-02 17:23:24
365
原创 04.优先考虑依赖注入来引用资源
总而言之，不要用Singleton和静态工具类来实现依赖一个或多个底层资源的类，且该资源的行为会影响到该类的行为，也不要用这个类来创建这些资源。而应该将这些资源或者工厂传给构造器（或者静态工厂或者构建器），通过它们来创建类，这个实践就被称为依赖注入，它极大提升了类的灵活性、可重用性和可测试性。
2024-04-02 17:22:42
430
原创 03.通过私有构造器强化不可实例化的能力
有时可能我们在开发的过程中需要编写静态方法和静态域的类，这些类不希望被实例化，因为实例化对它没有任何意义。那么我们该如何去做呢？这种类无法子类化，因为所有的构造器必须显式或隐式地调用超类构造器，这种情况下，子类无法访问的超类构造器。我们可以通过私有构造器方法，控制实例化能力，
2024-04-02 17:21:53
331
原创 02.用私有构造器或者枚举类型强化Singleton属性
单元素枚举类型经常成为Singleton最佳方法，注意，如果Singleton必须扩展一个超类，而不是扩展Enum的时候，则不适用适用这个方法（虽然可以声明枚举去实现接口）
2024-04-02 17:20:20
1064
原创 01.遇到多个构造器参数时要考虑使用构建器
Builder模式的客户端代码很容易编写，一步一步就点出来了，更为重要的是易读，Builder模式模拟了具名的可选参数。
2024-04-01 17:33:45
685
原创 00.用静态工厂方法代替构造器
简而言之，静态工厂方法和公有构造器都有用处，我们需要理解它们各自的长处。静态工厂经常更加合适，因此切忌第一反应就是提供公有的构造器，而不先考虑静态工厂。
2024-04-01 16:50:58
154
原创 软件设计重构秘笈31式-30使用多态代替条件判断
使用多态代替条件判断“这个重构在很多时候会出现设计模式中（常见的工厂家族、策略模式等都可以看到它的影子），因为运用它可以省去很多的条件判断，同时也能简化代码、规范类和对象之间的职责。
2024-03-29 13:07:01
309
原创 软件设计重构秘笈30式-29尽快返回
总结：这个重构很重要，它和前面讲的”分解复杂判断“有些类似，我们在做复杂的处理过程时，要经常考虑这个重构，用好了它，会对我们的帮助很大。
2024-03-29 13:06:46
183
原创 软件设计重构秘笈29式-28去除中间人对象
去除中间人对象“很多时候都会很有作用，尤其是在误用设计模式的代码中最容易见到，设计模式中的适配器模式和代理模式等都用中间的类是两者进行关联，这是比较合理的，因为中间类做了很多事情，而对于没有任何作用的中间类应该移除。
2024-03-28 17:02:49
385
原创 软件设计重构秘笈28式-27为布尔方法命名
为布尔方法命名“这个重构在很多时候都不常用，如果用户的参数可枚举，我们一般会枚举它的值，不过使用这种重构也有好处，就是分解开来以后，方法多了，参数少了，代码维护起来方便了一些。
2024-03-28 17:02:18
485
原创 软件设计重构秘笈27式-26去除上帝类
去除上帝类“是我们经常容易造成的，第一是因为简便，看到有一个现成的类，大家都会喜欢把代码往里面写，最后导致越写越大，并且声明功能都有，这样即降低了可读性，也造成了维护的负担。
2024-03-28 17:01:33
383
原创 软件设计重构秘笈26式-25避免双重否定
双重否定“很容易让人产生错误的判断，也很难让人理解你的代码，所以这个重构在我们的代码中是很重要的，尤其是在判断条件很多且业务复杂的时候。
2024-03-28 17:00:42
310
原创 软件设计重构秘笈25式-24引入契约模式
上面的代码中添加了额外的代码来进行验证，虽然看起来代码复杂度增加了，但我认为这是非常值得做的，因为当NullPointerException发生时去追查异常的详细信息真是很令人讨厌的事情。这个重构建议大家经常使用，这会增强整个系统的稳定性和健壮性。
2024-03-28 16:59:33
423
原创 软件设计重构秘笈24式-23分解复杂判断
这个重构很重要，它和后面讲的”尽快返回“有些类似，我们在做复杂的处理过程时，要经常考虑这个重构，用好了它，会对我们的帮助很大。
2024-03-28 16:58:51
360
原创 软件设计重构秘笈23式-22引入参数对象
这种重构很重要，尤其是当一个方法的参数比较多的时候，不管是大中型项目还是小型项目，都会遇到这种场景，所以建议大家多使用这个重构。这种封装的思想在SOA 里面也经常运用到，封装输入Message，封装输出Message，消息来和消息去以及消息间的交互就构成了整个应用体系。
2024-03-28 16:58:10
380
原创 软件设计重构秘笈22式-21分解方法
其实这个重构和我们前面讲的“提取方法”和“提取方法对象”如出一辙，尤其是“提取方法”，所以大家只要知道用这种思想重构就行。
2024-03-28 16:57:32
343
原创 软件设计重构秘笈21式-20合并继承
这篇和上篇其实最主要论述了子类和父类的继承关系以及如何判断什么时候需要使用继承，一般我们都能处理好这些关系，所以相对比较简单。
2024-03-28 16:56:51
375
原创 软件设计重构秘笈19式-18提取工厂类
这个重构经常会在项目中使用，如果要创建的对象是一个，你可以采用简单工厂，但是这种方式还是会存在很多依赖，维护起来也比较不方便。所以推荐使用工厂方法模式，把实例化延迟到子类。如果你要创建一系列的对象，那么就推荐你使用抽象工厂模式，但是要注意不要过度设计，只要能满足不断变化的需求和给以后的维护和重构带来方便即可。
2024-03-28 16:55:27
313
原创 软件设计重构秘笈18式-17使用条件判断代替异常
这个重构在项目代码中也经常用到，因为对于一部分程序员，是很难把握什么时候用try catch ，什么地方该用try catch。记得之前大家还专门讨论过这些，比如如何用好以及在大中型项目中应该把它放在哪一个组件中等。
2024-03-28 16:54:27
270
原创 软件设计重构秘笈17式-16提取父类
这个重构是典型的继承用法，很多程序员都会选择这样做，但是要注意正确的使用，不要造成过度使用了继承，如果过度使用了，请考虑用接口、组合和聚合来实现。
2024-03-28 16:53:24
322
原创 软件设计重构秘笈16式-15封装条件
这个重构在很大程度上能改善代码的可读性，尤其是在一个逻辑很复杂的应用中，把这些条件判断封装成一个有意义的名字，这样很复杂的逻辑也会立刻变得简单起来。
2024-03-28 16:52:43
307
原创 软件设计重构秘笈15式-14移除重复内容
这个重构很简单，绝大多数程序员都会使用这种重构方法，但有时由于习惯、时间、赶进度等原因而忽略它，所以会使得整个系统杂乱无章，到处都是Ctrl+C和Ctrl+V的痕迹。
2024-03-28 16:51:54
182
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人