单例模式的七种写法
写前须知
单例模式，顾名思义是一种在程序运行过程中只会产生一个对象实例的设计模式。因此设计之前，我们需要知道最基本的条件：

1.构造函数私有化

2.实例引用私有化

3.获取实例公有化。
单例模式可以分为懒汉单例模式和饿汉单例模式。就像这形象的名字描述的那样

1.懒汉单例模式只会在我们需要的时候才回去创建对象实例

2.饿汉单例模式则在程序启动时就创建好了对象实例
然后就开始我们的单例模式设计吧！
一、线程不安全的懒汉单例模式
应用场景：单线程
public class Singleton_1 {
    private static Singleton_1 instance;
    //构造方法私有化
    private Singleton_1(){
        //执行几次就创建了多少实例
        System.out.println("Singleton_1");
    }
	//调用此方法才会创建对象实例
    public static Singleton_1 getInstance(){
        if (instance==null){
            instance = new Singleton_1();
        }
        return instance;
    }
}

测试一下
class TestSingleton_1{
    public static void main(String[] args) {
        Singleton_1.getInstance();
        Singleton_1.getInstance();
        Singleton_1.getInstance();
//        for (int i=0;i<100;i++){
//            new Thread(){
//                @Override
//                public void run() {
//                    Singleton_1.getInstance();
//                }
//            }.start();
//        }
    }
}

结果如下：



很明显只创建了一个实例。

好奇的童鞋们可以自己测试一下注释部分的多线程情况下会发生什么
二、线程安全的懒汉单例模式
应用场景：大对象，用的少，并发量不能太大
public class Singleton_02 {
    private static Singleton_02 instance;
    private Singleton_02(){
        System.out.println("Singleton_2");
    }
    //线程安全但是性能降低
    public static synchronized Singleton_02 getInstance(){
        if (instance==null)
            instance = new Singleton_02();
        return instance;
    }
}

并发量太大的话可能会造成性能问题。

测试一下：
class TestSingleton_2{
    public static void main(String[] args) {
        for (int i=0;i<1000;i++){
            new Thread(){
                @Override
                public void run() {
                    Singleton_02.getInstance();
                }
            }.start();
        }
    }
}

结果如图：


三、双重验证的懒汉单例模式
应用场景：大对象，稀少用，并发量不能太大
public class Singleton_3 {
    //注意这里用volatile修饰
    private static volatile Singleton_3 instance;

    private Singleton_3(){
        System.out.println("Singleton_3");
    }

    public static Singleton_3 getInstance(){
    	//双重验证
        if (instance==null){
            synchronized (Singleton_3.class){
                if (instance==null)
                    instance=new Singleton_3();
            }
        }
        return instance;
    }
}

1.在并发条件下，最先到达外层 if 判断语句的线程进入语句体后（这里可能有多个线程进入外层 if 语句，因此才会有第二层 if 语句）获得锁，第一个获得锁的线程明显判定 instance==null ，因此进入第二层 if 语句然后创建对象实例赋值给instance。

2.后面的线程（无论是在第一层 if 语句，还是已经进入外层 if 语句）都会判断intance是否为null（此时明显不为null），因此节省了大量时间在获得锁，释放锁的过程（并发不高的条件下，毕竟一拥而入外层 if 语句的线程并不多），相对第二种设计方式，性能较大提升。
相信大家读到这也能理解为什么instance要用volatile修饰了——为了保证它的可见性
测试一下：
class TestSingleton_3{
    public static void main(String[] args) {
        for (int i=0;i<1000;i++){
            new Thread(){
                @Override
                public void run() {
                    Singleton_3.getInstance();
                }
            }.start();
        }
    }
}


四、饿汉单例模式
应用场景：小对象，频繁用,高并发
public class Singleton_4 {
    //对象在类加载时初始化
    private static Singleton_4 instance = new Singleton_4();
    private Singleton_4(){
        System.out.println("Singleton_4");
    }

    public static Singleton_4 getInstance(){
        return instance;
    }
}

对象实例用static修饰，在类加载时就已经初始化，因此被称为饿汉单例。
测试：
class TestSingleton_4{
    public static void main(String[] args) {
        for (int i=0;i<1000;i++) {
            new Thread() {
                @Override
                public void run() {
                    Singleton_4.getInstance();
                }
            }.start();
        }
    }
}


五、基于内部类实现的单例模式
应用场景：大对象，频繁用，高并发
public class Singleton_5 {
	//内部类
    static class Inner{
        private final static Singleton_5 instance = new Singleton_5();
    }
    private Singleton_5(){
        System.out.println("Singleton_5");
    }

    public static Singleton_5 getInstance(){
        return Inner.instance;
    }
}

内部类只会在使用时加载，不使用不加载，因此可以很好的实现单例模式
测试：
class TestSingleton_5{
    public static void main(String[] args) {
        for (int i=0;i<1000;i++) {
            new Thread() {
                @Override
                public void run() {
                    Singleton_5.getInstance();
                }
            }.start();
        }
    }
}


六、枚举实现单例模式
public enum Singleton_6 {
    INSTANCE;//一个实例（类加载时创建）
    private C c;
    private Singleton_6(){qi
        c = new C();
    }
    public C getInstance(){
        return c;
    }
}

class C{
    public C(){
        System.out.println("C-Singleton_6");
    }
}

测试：
class TestSingleton_6{
    public static void main(String[] args) {
        for (int i=0;i<1000;i++){
            new Thread(){
                @Override
                public void run() {
                    Singleton_6.INSTANCE.getInstance();
                }
            }.start();
        }
    }
}


七、使用“池”实现单例模式
class A{public A(){System.out.println("A");}}
class B{public B(){System.out.println("B");}}

public class Singleton_7 {//思考spring的单例设计
    public static Map<String,Object> map = new HashMap<>();
    static {
        map.put("A",new A());
        map.put("B",new B());
    }
    public static Object get(String key){
        return map.get(key);
    }
}

测试：
class TestSingleton_7{
    public static void main(String[] args) {
        for (int i=0;i<1000;i++) {
            new Thread() {
                @Override
                public void run() {
                    Singleton_7.get("A");
                    Singleton_7.get("B");
                }
            }.start();
        }
    }
}

结果如下：


结束语
好好学习，天天向上！Fighting小伙汁们！！！

普通的工程师堆砌代码，优秀的工程师优雅代码，卓越的工程师简化代码。如何写出优雅整洁易懂的代码是一门学问，也是软件工程实践里重要的一环。笔者推荐三本经典的书籍《代码整洁之道 》、《编写可读代码的艺术》、《重构:改善既有代码的设计》，下文重点将从注释、命名、方法、异常、单元测试等多个方面总结了一些代码整洁最佳实践，大部分是笔者总结于以上三本书中的精华，也有部分是笔者工程实践的总结。篇幅有限，本文将总结性给出一些实践建议，后续会有文章来给出一些代码整洁之道的事例。

一、注释

不要给不好的名字加注释，一个好的名字比好的注释更重要；

不要“拐杖注释”，好代码 > 坏代码 + 好注释；

在文件/类级别使用全局注释来解释所有部分如何工作；

一定要给常量加注释；

团队统一定义标记：

TODO  待处理的问题；

FIXME  已知有问题的代码；

HACK 不得不采用的粗糙的解决方案；

在注释中用精心挑选的输入输出例子进行说明；

注释应该声明代码的高层次意图，而非明显的细节；

不要在代码中加入代码的著作信息，git可以干的事情不要交给代码；

源代码中的html注释是一种厌物, 增加阅读难度；

注释一定要描述离它最近的代码；

注释一定要与代码对应；

公共api需要添加注释，其它代码谨慎使用注释；

典型的烂注释：

不恰当的信息；

废弃的注释；

冗余注释；

糟糕的注释；

注释掉的代码；

唯一真正好的注释是你想办法不去写的注释：

不要有循规式注释，比如setter/getter注释；

不要添加日志式注释，比如修改时间等信息（git可以做的事情）；

注释一定是表达代码之外的东西，代码可以包含的内容，注释中一定不要出现；

如果有必要注释，请注释意图（why），而不要去注释实现（how)，大家都会看代码；

适当添加警示注释；

二、命名

尽可能使用标准命名方法，比如设计模式，通用学术名词等；

命名要找更有表现力的词：

使用更专业的词，比如不用get而使用fetch或者download；

避免空泛的名字，像tmp；

使用具体的名字来细致的描述事物；

给变量名带上重要的细节，比如加上单位ms等；

为作用域大的名字采用更长的名字，作用域小的使用短名字；

变量类型为布尔值表达加上is，has，can，should这样的词会更明确；

变量名称长短应该与其作用域对应；

别害怕长名称，长而具有描述性的名称比短而令人费解的名称好；

函数名称应该说明副作用，名称应该表达函数，变量或类的一切信息，请不要掩盖副作用，比如CreateAndReturnXXX；

三、方法

函数不应该有100行那么长，20行封顶最好：

if else while等控制语句其中代码块应该只有一行，也就是一个函数调用语句；

函数的锁进层次不应该多于两层；

一个函数只做一件事，一个函数不应该能抽象出另外一个函数；

某个公共函数调用的私有函数紧随其后；

最理想的参数是零参数，最长不要超过三个入参，尽量不要输出参数：

如果函数传入三个及以上参数最好将其抽象为类；

标识参数十分丑陋，向函数传入布尔值用于区分不同业务的做法很丑陋，应该拆分为多个函数；

别返回null值，抛出异常或者返回特殊对象，尽量避免NPE；

别传入null值；

四、异常与错误

抽离try catch包含的代码块，其中代码块抽象为一个函数；

抛出的每个异常，都应当提供足够的环境说明，已便判断错误的来源与处所；

不要将系统错误归咎于偶然事件；

五、并发

分离并发相关代码与其它代码；

严格限制对可能被共享的数据的访问；

避免使用一个共享对象的多个同步方法；

保持同步区域微小，尽可能少设计临界区；

六、单元测试

不要怕单元测试的方法名字太长或者繁琐，测试函数的名称就像注释；

不要追求太高的测试覆盖率，测试代码前面90%通常比后面10%花的时间少；

使用最简单的并且能够完整运用代码的测试输入；；

给测试函数取一个完整性的描述性名字，比如  Test _；

测试代码与生产代码一样重要；

如果测试代码不能保证整洁，你就会很快失去他们；

每个测试一个断言，单个测试中断言数量应该最小化也就是一个断言；

FIRST原则：

快速 Fast；

独立 Independent  测试应该相互独立；

可重复 Repeatable  测试应当在任何环境中重复通过；

自足验证 Self-Validating   测试应该有布尔值输出；

及时  Timely   最好的方式是TDD；

七、代码结构

代码行长度控制在100-120个字符；

可能用大多数为200行，最长500行的单个文件构造出色的系统；

关系密切的代码应该相互靠近：

变量声明应该靠近其使用位置；

若某个函数调用了另外一个，应该把他们放在一起，而且调用者应该放在被调用者上面；

自上向下展示函数调用依赖顺序；

应该把解释条件意图的函数抽离出来，尽可能将条件表达为肯定形式；

不要继承常量，比如接口中定义常量，不要使用继承欺骗编程语言的作用范围规则；

模块不应了解它所操作对象的内部情况；

DTO（Data Transfer Objects）是一个只有公共变量没有函数的类；

对象暴露行为，隐藏数据；

不要使用“尤达表示法” 如 if(null == obj)，现代编译器对if(obj = null)这样的代码会给出警告；

一般情况使用if else，简单语句使用三目运算符；

通常来讲提早返回可以减少嵌套并让代码整洁；

八、设计

类应该足够短小：

类应该满足单一权责原则（SRP），类和模块只有一个修改理由；

类应该只有少量的实体变量；

类应该遵循依赖倒置原则 DIP（Dependency Inversion Principle），类应该依赖于抽象而不是依赖于具体细节；

类中的方法越少越好，函数知道的变量越少越好，类拥有的实体变量越少越好；

通过减少变量的数量和让他们尽量“轻量级”来让代码更有可读性：

减少变量；

缩小变量的作用域；

只写一次的变量更好，如常量；

最好读的代码就是没有代码：

从项目中消除不必要的功能，不要过度设计；

从新考虑需求，解决版本最简单的问题，只要能完成工作就行；

经常性地通读标准库的整个API，保持对他们的熟悉程度；

简单设计：

运行所有测试；

不可重复；

表达了程序员的意图；

尽可能减少类和方法的数量；

以上规则按重要程度排列；

无论是设计系统或者单独模块，别忘了使用大概可工作的最简单方案；

整洁的代码只提供一种而非多种做一件事的途径，他只有尽量少的依赖。明确定义并提供尽量少的API；

减少重复代码，提高表达力，提早构建，简单抽象；

九、小结

本文从注释、命名、方法，单元测试，并发等视角简单给出了一些最佳实践，下文我们会展开来从每个方面介绍更多的实践事例。相信每一个优秀的工程师都有一颗追求卓越代码的心，在代码整洁工程实践上你有哪些好的建议？数百人协作开发的代码如何保证代码整洁一致性？欢迎大家来讨论。

————————————————

版权声明：本文为CSDN博主「光辉岁月gds」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/gdsgdh308227363/article/details/85985533

一、简介
JavaBean 是一种JAVA语言写成的可重用组件。为写成JavaBean，类必须是具体的和公共的，并且具有无参数的构造器。JavaBean 通过提供符合一致性设计模式的公共方法将内部域暴露成员属性，set和get方法获取。众所周知，属性名称符合这种模式，其他Java 类可以通过自省机制(反射机制)发现和操作这些JavaBean 的属性。
javabean是遵循特定写法的java类，它通常具有如下特点：
这个Java类必须具有一个无参的构造函数
属性必须私有化。
私有化的属性必须通过public类型的方法暴露给其它程序，并且方法的命名也必须遵守一定的命名规范。
二、组成
(1) 属性(properties)
JavaBean提供了高层次的属性概念，属性在JavaBean中不只是传统的面向对象的概念里的属性，它同时还得到了属性读取和属性写入的API的支持。属性值可以通过调用适当的bean方法进行。比如，可能bean有一个名字属性，这个属性的值可能需要调用String getName()方法读取，而写入属性值可能要需要调用void setName(String str)的方法。
每个JavaBean属性通常都应该遵循简单的方法命名规则，这样应用程序构造器工具和最终用户才能找到JavaBean提供的属性，然后查询或修改属性值，对bean进行操作。JavaBean还可以对属性值的改变作出及时的反应。比如一个显示当前时间的JavaBean，如果改变时钟的时区属性，则时钟会立即重画，显示当前指定时区的时间。
(2) 方法(method)
JavaBean中的方法就是通常的Java方法，它可以从其他组件或在脚本环境中调用。默认情况下，所有bean的公有方法都可以被外部调用，但bean一般只会引出其公有方法的一个子集。
由于JavaBean本身是Java对象，调用这个对象的方法是与其交互作用的唯一途径。JavaBean严格遵守面向对象的类设计逻辑，不让外部世界访问其任何字段(没有public字段)。这样，方法调用是接触Bean的唯一途径。
但是和普通类不同的是，对有些Bean来说，采用调用实例方法的低级机制并不是操作和使用Bean的主要途径。公开Bean方法在Bean操作中降为辅助地位，因为两个高级Bean特性--属性和事件是与Bean交互作用的更好方式。
因此Bean可以提供要让客户使用的public方法，但应当认识到，Bean设计人员希望看到绝大部分Bean的功能反映在属性和事件中，而不是在人工调用和各个方法中。
(3) 事件(event)
Bean与其他软件组件交流信息的主要方式是发送和接受事件。我们可以将bean的事件支持功能看作是集成电路中的输入输出引脚：工程师将引脚连接在一起组成系统，让组件进行通讯。有些引脚用于输入，有些引脚用于输出，相当于事件模型中的发送事件和接收事件。
事件为JavaBean组件提供了一种发送通知给其他组件的方法。在AWT事件模型中，一个事件源可以注册事件监听器对象。当事件源检测到发生了某种事件时，它将调用事件监听器对象中的一个适当的事件处理方法来处理这个事件。
三、在JSP中使用JavaBean
JSP技术提供了三个关于JavaBean组件的动作元素，即JSP标签，它们分别为：
标签：用于在JSP页面中查找或实例化一个JavaBean组件。
标签：用于在JSP页面中设置一个JavaBean组件的属性。
标签：用于在JSP页面中获取一个JavaBean组件的属性。

Cusomer表

名字

电话

邮箱

注册时间

ORM框架写法：


商品订单：

名字价格：

种类：

描述：

创建时间：



 

买家和产品是一对多的关系

订单表的外键是顾客表