当前程序存在的依赖问题（耦合）分析
用JDBC来做例子
在注册驱动的时候 用的new的方式创建了Driver()
但一旦把环境(把pom.xml的依赖删除,没有mysql的jar包)更改
这个操作主要是来模拟一下,如果用new的方实例化我们的对象,如果删除了,也会导致这种效果
那么就程序就会直接报错这时候就不是运行的异常 而是编译都通过不了的错误
这就可以理解为程序的耦合
解决思路1：通过反射来创建对象 而避免了new关键字
这就是以前的写法 它就是通过反射创建驱动 即用一个字符串代替了new
这样在同样没有环境的情况下 它并不会编译不了 （避免了类之间的耦合）
但存在一个问题 这样的作法其实也是存在严重的耦合问题
因为String类型是写死代码了 如果文件更改了 那么就要一个一个修改java写死了的String
解决思路2：通过读取配置文件来获取要拆改那就的对象的全限定类名
即这串字符串 我们可以配置在xml配置文件中 然后读取出来
实际开发中遇到的耦合问题—service层和Dao层
在表现层创建service层
和在service层创建dao层
都使用了new 这时候我们就要用工厂来创建了
那么工厂是什么
工厂就是来创建我们的service对象和dao对象的
根据刚刚的分析 我们需要
1，一个配置文件配置两个对象，并且有唯一的标识可以让我们找到他们—>这个唯一标识就是全限定类名
2，而是通过读取这个配置文件，通过反射方法 来创建对象
1.读取配置文件（配置文件里就配置了全限定类名）
其中在编写工厂时 也看到了一些相关耦合的问题1，new Properties():这里用了new，但是这个是一个配置文件的实例化，是无法降低这个耦合的（耦合只能尽力降低，无法避免）
2，new FileInputStream():如果用这个流的形式来读出配置文件，那么你无法保证你所写的路径是符合所有计算机的(有些计算机的磁盘名称不一样)所有这个路径就很局限，
所以这里我们用到类加载器在我们配置完了这个工厂后，那我们要用工厂获得一个实例–>定义getBean()方法
2.通过反射获得实例化对象这里就用了反射的机制 通过类名返回了一个实例
这就解决了这个耦合问题
单例和多例
单例：如果定义了类变量，那么多次访问同一个单例，会修改这个类变量，即存在线程问题
多例：会生成多个不同的对象，造成浪费
在实际中，我们几乎不会去定义类变量 所以我们只要用单例模型就好了
那么我们之前工厂要修改成单例模型的工厂用于存放各个单例 其中key就是它的名字，value就是这个对象
通过读取配置文件，在调用keys()可以获得配置文件所有的key（即对象的名字）
然后通过这些名字获得全路径类名beanPath，通过全路径类名去找对应的对象在通过反射生成因为在前面的static已经初始化了所有对象 只要直接返回就行了