学习打卡 IOC理论推导

        看完IOC相关资料，怕过了几天忘了，记录下

        写一段简单的业务通常需要：
            1. UserDao接口； 2.UserDaoImpl实现类；
            3.UserService接口； 4.UserServiceImpl实现类；

        先前我们会去这么写：

public interface UserDao {
    void getUser();
}

public class UserDaoImpl implements UserDao {
    public void getUser(){
        System.out.println("默认获取用户的数据");
    }
}

public interface UserService {
    void getUser();
}

public class UserServiceImpl implements UserService {
    private UserDao userDao = new UserDaoImpl();
    public void getUser(){
		userDao.getUser();
	}
}

public class MyTest {
    public static void main(String[] args) {
        UserService userService = new UserServiceImpl();
        userService.getUser();
    }
}

        一组没啥毛病的代码，将会使用Dao层的方法；

        而现在，如果增加了一个和mysql有关的需求，该怎么做呢？
        很简单，在Dao层里加入一个UserDaoMySqlImpl类：

public class UserMysqlImpl implements UserDao {
    public void getUser() {
        System.out.println("Mysql获取用户");
    }
}

        想让客户使用到这个类，则必须要去业务实现层改代码：

public class UserServiceImpl implements UserService {
    private UserDao userDao = new UserDaoMysqlImpl();
    public void getUser(){
		userDao.getUser();
	}
}

        改动以后确实可以实现mysql相关的需求了，但若此刻客户又有新的需求了，则我们又要改动一次业务层的代码；在代码量，需求量指数增长的后期，这样死板的写法显然不是最优解。
        即 程序适应不了 用户需求的变更。
        按照模块化接口思想，我们可以改动业务实现类的代码，不把程序给写死：

public class UserServiceImpl implements UserService {
    private UserDao;
	//利用set进行动态实现值的注入
	public void setUserDao(){
		this.userDao = userDao;
	}
    public void getUser(){
		userDao.getUser();
	}
}

        如此，程序便不用再控制对象，用户有什么需求，在主类中自行调用方法添加即可，例：

public class MyTest {
    public static void main(String[] args) {
        UserService userService = new UserServiceImpl();
        //客户要使用数据库有关的层
        userService.setUserDao(new UserMysqlImpl());
        userService.getUser();
    }
}

        在之前的业务中，用户的需求可能会影响我们原来的代码，我们需要根据用户的需求修改原代码；如果程序代码量十分大，修改一次的成本代价十分昂贵；
        而使用一个Set接口实现，已经发生了革命性的变化 – 程序不再具有主动性，而是变成了被动接受的对象，程序员不用再去管理对象的创建；系统的耦合性大大降低，可以更加专注在业务实现上；

        这就是 IOC的原型。

PS：看到一句话挺有道理的，顺道拿过来做个记录：
        IOC（控制反转）是一种通过描述（XML或注解）并通过第三方去生产或获取特定对象的方式。在Spring中实现控制反转的是ioC容器，其实现方法是依赖注入（DI）

        所以IOC和DI明显不能混为一谈嘛…