标签：一点 依赖关系 for img 对象 arraylist col 一对多 任务管理
单例模式：
即一个应用程序中，某个类的实例对象只有一个，你没有办法去new，因为构造器是被private修饰的，一般通过其get方法获取到他们的实例。
懒汉写法（线程不安全）
public class Singleton { private static Singleton singleton; private Singleton() { } public static Singleton getInstance() { if (singleton == null) { singleton = new Singleton(); } return singleton; } }
懒汉式写法（线程安全）
public class Singleton { private static Singleton instance; private Singleton (){} public static synchronized Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } }
饿汉式写法
public class Singleton { private static Singleton instance = new Singleton(); private Singleton (){} public static Singleton getInstance() { return instance; } }
静态内部类
public class Singleton { private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); } private Singleton (){} public static final Singleton getInstance() { return SingletonHolder.INSTANCE; } }
枚举
这种方式是Effective Java作者Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象，可谓是很坚强的壁垒啊，不过，个人认为由于1.5中才加入enum特性，用这种方式写不免让人感觉生疏。
public enum Singleton { INSTANCE; public void whateverMethod() { } }
双重校验锁
public class Singleton { private volatile static Singleton singleton; private Singleton (){} public static Singleton getSingleton() { if (singleton == null) { synchronized (Singleton.class) { if (singleton == null) { singleton = new Singleton(); } } } return singleton; } }
实际应用场景：1.在Spring中创建的Bean实例默认都是单例模式存在的。
2.Windows的Task Manager（任务管理器）就是很典型的单例模式（这个很熟悉吧），想想看，是不是呢，你能打开两个windows task manager吗？ 不信你自己试试看哦~
3. windows的Recycle Bin（回收站）也是典型的单例应用。在整个系统运行过程中，回收站一直维护着仅有的一个实例。
4. 网站的计数器，一般也是采用单例模式实现，否则难以同步。
5. 应用程序的日志应用，一般都何用单例模式实现，这一般是由于共享的日志文件一直处于打开状态，因为只能有一个实例去操作，否则内容不好追加。
观察者模式：
对象间一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
给你举个栗子：假设有三个人，小美（女，22），小王和小李。小美很漂亮，小王和小李是两个程序猿，时刻关注着小美的一举一动。有一天，小美说了一句：“谁来陪我打游戏啊。”这句话被小王和小李听到了，结果乐坏了，蹭蹭蹭，没一会儿，小王就冲到小美家门口了，在这里，小美是被观察者，小王和小李是观察者，被观察者发出一条信息，然后观察者们进行相应的处理，看代码：
public interface Person { //小王和小李通过这个接口可以接收到小美发过来的消息 void getMessage(String s); }
这个接口相当于小王和小李的电话号码，小美发送通知的时候就会拨打getMessage这个电话，拨打电话就是调用接口，看不懂没关系，先往下看
public class LaoWang implements Person { private String name = "小王"; public LaoWang() { } @Override public void getMessage(String s) { System.out.println(name + "接到了小美打过来的电话，电话内容是：" + s); } } public class LaoLi implements Person { private String name = "小李"; public LaoLi() { } @Override public void getMessage(String s) { System.out.println(name + "接到了小美打过来的电话，电话内容是：->" + s); } }
代码很简单，我们再看看小美的代码：
public class XiaoMei { List<Person> list = new ArrayList<Person>(); public XiaoMei(){ } public void addPerson(Person person){ list.add(person); } //遍历list，把自己的通知发送给所有暗恋自己的人 public void notifyPerson() { for(Person person:list){ person.getMessage("你们过来吧，谁先过来谁就能陪我一起玩儿游戏!"); } } }
我们写一个测试类来看一下结果对不对
public class Test { public static void main(String[] args) { XiaoMei xiao_mei = new XiaoMei(); LaoWang lao_wang = new LaoWang(); LaoLi lao_li = new LaoLi(); //小王和小李在小美那里都注册了一下 xiao_mei.addPerson(lao_wang); xiao_mei.addPerson(lao_li); //小美向小王和小李发送通知 xiao_mei.notifyPerson(); } }
实际应用场景：
场景描述：
以购票为核心业务(此模式不限于该业务)，但围绕购票会产生不同的其他逻辑，如：
1、购票后记录文本日志
2、购票后记录数据库日志
3、购票后发送短信
4、购票送抵扣卷、兑换卷、积分
5、其他各类活动等
传统解决方案:
在购票逻辑等类内部增加相关代码，完成各种逻辑。
存在问题：
1、一旦某个业务逻辑发生改变，如购票业务中增加其他业务逻辑，需要修改购票核心文件、甚至购票流程。
2、日积月累后，文件冗长，导致后续维护困难。
存在问题原因主要是程序的"紧密耦合"，使用观察模式将目前的业务逻辑优化成"松耦合"，达到易维护、易修改的目的，
同时也符合面向接口编程的思想。
观察者模式典型实现方式：
1、定义2个接口：观察者（通知）接口、被观察者（主题）接口
2、定义2个类，观察者对象实现观察者接口、主题类实现被观者接口
3、主题类注册自己需要通知的观察者
4、主题类某个业务逻辑发生时通知观察者对象，每个观察者执行自己的业务逻辑。
装饰者模式
对已有的业务逻辑进一步的封装，使其增加额外的功能，如Java中的IO流就使用了装饰者模式，用户在使用的时候，可以任意组装，达到自己想要的效果。 举个栗子，我想吃三明治，首先我需要一根大大的香肠，我喜欢吃奶油，在香肠上面加一点奶油，再放一点蔬菜，最后再用两片面包夹一下，很丰盛的一顿午饭，营养又健康。那我们应该怎么来写代码呢？ 首先，我们需要写一个Food类，让其他所有食物都来继承这个类，看代码：
public class Food { private String food_name; public Food() { } public Food(String food_name) { this.food_name = food_name; } public String make() { return food_name; }; }
代码很简单，我就不解释了，然后我们写几个子类继承它：
//面包类 public class Bread extends Food { private Food basic_food; public Bread(Food basic_food) { this.basic_food = basic_food; } public String make() { return basic_food.make()+"+面包"; } } //奶油类 public class Cream extends Food { private Food basic_food; public Cream(Food basic_food) { this.basic_food = basic_food; } public String make() { return basic_food.make()+"+奶油"; } } //蔬菜类 public class Vegetable extends Food { private Food basic_food; public Vegetable(Food basic_food) { this.basic_food = basic_food; } public String make() { return basic_food.make()+"+蔬菜"; } }
这几个类都是差不多的，构造方法传入一个Food类型的参数，然后在make方法中加入一些自己的逻辑，如果你还是看不懂为什么这么写，不急，你看看我的Test类是怎么写的，一看你就明白了
public class Test { public static void main(String[] args) { Food food = new Bread(new Vegetable(new Cream(new Food("香肠")))); System.out.println(food.make()); } }
看到没有，一层一层封装，我们从里往外看：最里面我new了一个香肠，在香肠的外面我包裹了一层奶油，在奶油的外面我又加了一层蔬菜，最外面我放的是面包，是不是很形象，哈哈~ 这个设计模式简直跟现实生活中一摸一样，看懂了吗？
实际应用场景：
如上述一样，不同的人，选择的搭配不同，对应价格也不相同，若是应用传统方式你会发现这里四种配料就要写十几种实现类了，那如果我们的配料是二十几种或者三十几种呢，那么使用继承这种 方式肯定会使我们的子类爆炸。
通过不同的组合以
Food food = new Bread(new Vegetable(new Cream(new Food("香肠"))));形式更加简化，结构更加清楚的方式展现。
优点：
标签：一点 依赖关系 for img 对象 arraylist col 一对多 任务管理
原文地址：https://www.cnblogs.com/AsaltedFish/p/10642788.html
