Java 开发思考总结（一）

亦凉 2023-07-17 06:08 8阅读 0赞

1、Java是一个笨重的垃圾语言吗？

> 一个语言很笨重，不是研发者要故意让这个语言变得很笨重，现在语言这么多，如果没有它自己的优势，是很难存活的。
> 
> 在只了解了一些JS、Python之类的动态语言之后，就盲目的下结论是不正确的。
> 
> Java 笨重是有笨重的原因的，这是因为Java通常是用来做企业级的项目，或者说是复杂的大项目。

2、为什么在企业中不会优先选择使用动态语言去做大项目

> 不是说动态语言不能写大项目，但是动态语言在写大项目的时候，会有很多问题，并且写出来的代码很难维护。
> 
> 但是Java或者C\#这类编译形语言编写项目，写的时候比较麻烦（比如Java强制使用类的思想去表达），主要是为了维护方便
> 
> 多数情况下，开发者考虑的都是如何快速的将代码写完，这个想法其实是不正确的，因为对于软件工程来讲，写出项目来并不是软件工程要解决的主要问题
> 
> 软件工程主要解决的问题是迭代、维护。

3、开发过程中的方法论

> 开发中的软件工程、软件方法论，其实主要解决的就是项目的维护和迭代，而不是简单的把一个项目开发出来就完事了
> 
> 如果编程只是为了把项目写出来，那么项目一点都不难
> 
> 关键是对于自己来讲，不追求一些软件工程上面的方法论，软件的编程水平是没办法提升的。因为你永远都是在追求把代码写出来而已。

4、一个程序员好，到底好在什么地方

> 一个好的程序员，除了综合素质（每一个程序员都要去追求的或者说是特质），追求可维护的代码
> 
> 如果不是，那么学习Java只是在浪费时间而已

5、糟糕的代码

> 糟糕的代码并非指的是代码写的很丑，有些动态语言写的代码也很漂亮很美
> 
> 这里的糟糕指的是，不可维护。也就是你自己都很难去更改自己写的代码
> 
> 并不是说Python、JS就无法写出可维护的代码，只不过要真正写的好的可维护的代码，很难
> 
> 虽然说Java、C\#笨重，但也正是因为它们的强制性，因此不需要太好的基本功也不需要太过于了解软件上的方法论，只需要按照语言的特质，就能写出很好的可维护的代码
> 
> 很多观点是，写出简短的代码就是好的代码，但真的是这样吗？这个不见得
> 
> 什么是好的代码？通俗来讲就是，不啰嗦，自描述性的代码（看这个代码不需要过多的注释就能理解清楚代码的意思）
> 
> 还有一个最重要的，也是各种各样软件工程里探讨的：可维护性
> 
> 所有软件的复杂性，其实都是为了写出可维护的代码

6、SpringBooot 为什么会有这么多复杂的概念

> SpringBoot 中应用了大量的设计模式，本身SpringBoot中融合许多的框架，比如SpringFrameWork，SpringFrameWok中又有IOC和AOP，还有各种各样的MVC、JMS等模块
> 
> 面试其实问的并不深，比如 Spring 容器中bean的加载过程，但了解这个过程需要看源码吗？显然不需要
> 
> SpringBoot把一个对象加入IOC容器之前，有一个重要的点就是，BeanDefination也即Bean的定义

7、怎么样才能叫好维护或者说怎么样可以称之为可维护的代码？

> 软件工程里面必要重要的几个原则：
> 
> 1.  开闭原则（最重要的，可维护代码的基础）
> 2.  里氏替换原则
> 3.  迪米特法则
> 
> 多数原则其实都是为了实现开闭原则，比如IOC、DI
> 
> OCP：open、close、principle
> 
> 软件、函数、类这几者都应该对扩展是开放的，而对修改是封闭的。
> 
> eg：避免修改原有代码带来bug的最好方法就是新增一个类/业务模块，使用新增来代替原来的类。当然不是时候新增的模块不会有bug，只是相比修改原来复杂的代码出现bug的概率更小一些。

8、如果要实现开闭原则，有一个最基准的原则

> 必须面向抽象编程，只有做到这一点，才能逐步地实现开闭原则。
> 
> 很多时候，Java之所以复杂，就是它本身就是为面向抽象而设计的语言，所以在Java中有了interface、Abstract等概念

9、再具体一点，如果要做到面向抽象编程，在Java里有几个非常重要的语法知识，可以帮助实现抽象面向编程

> Interface、Abstract 
> 
> 只有有了接口和抽象类的概念，经常谈到的面向对象的三大特性其中之一就是多态性，才能得到很好地支持
> 
> 做不到面向抽象编程，开闭原则是实现不了的

10、为什么实现开闭原则就必须面向抽象编程

创建一个类 Demo

public class Demo {
    
        public String print(){
            return "This is a class : Demo";
        }
    
    }

创建一个类 Demo2

public class Demo2 {
        public String print(){
            return "This is a class : Demo2";
        }
    }

创建主类

public class Main {
    
        public static void main(String[] args) {
            Demo demo = new Demo();
    
            System.out.println(demo.print());
    
    
        }
    }

> 假如没有Demo2这个类，后续根据业务增加的Demo2
> 
> 要输出 Demo2 的东西，直接在Demo中改即可。但这种方法是最糟糕的方案，直接修改了业务类。
> 
> 既然是开闭原则，那么直接新增一个Demo2，而不动Demo的实现，这样看起来像是实现了开闭原则
> 
> 但问题是Main类也需要实例化一个Demo2，这时候就不符合开闭原则了
> 
> 复杂的业务场景中都是类与类之间的相互作用

> Main 中依赖的 A 是一个具体的类，而不是一个抽象，这个 A 太过于具体，一旦发生变化，和 A 相关的所有代码都需要更改
> 
> 不管new 的是什么类，总是能给到一个方法以调用，这就可以了

11、面向抽象的常见手段：interface、工厂模式与 IOC、DI

>  *  最开始需要的是 interface 去面向抽象编程，但interface 无法完全解决问题，这是第一阶段
>  *  第二阶段就是设计模式中的工厂模式/方法，使用工厂创建方法，从而消除具体的对象
>  *  第三阶段也即出现了 IOC/DI 
> 
> 无论是interface、工厂、IOC，目的是什么？表面上看是要面向抽象编程，但是面向抽象编程好处是什么？它们的真实目的是什么？
> 
> 面向抽象只是表面上的意义，也即不能依赖一个具体的类，而是要依赖抽象。它们真正的目的是为了编写可维护的代码，实现众多目的中最重要的 OCP 原则，即开闭原则

12、模拟一个 LOL 小实例

>  *  LOL 从面世到如今已经有 140多个英雄，也即每年平均增加 10 多个
>  *  除了英雄之外，每个版本的地图、道具、技能、平衡性、可选英雄等都有频繁更新
> 
> 一个是可选英雄的不断增加，从而扩充英雄池；另一个是开局时必须选择一个英雄

第一版：

第一个英雄：FirstHeroDiana

public class FirstHeroDiana {
    
        public void q(){
            System.out.println("Diana 释放了 Q 技能");
        }
    
        public void w(){
            System.out.println("Diana 释放了 W 技能");
        }
    
        public void e(){
            System.out.println("Diana 释放了 E 技能");
        }
    
        public void r(){
            System.out.println("Diana 释放了 R 技能");
        }
    
    
    }

选择了英雄后，释放技能

Main

public class Main {
    
    
        public static void main(String[] args) {
            String name = Main.getPlayerInput();
            //选择英雄之后，释放一个技能
            if(Objects.equals("Diana", name)){
                FirstHeroDiana diana = new FirstHeroDiana();
                diana.r();
            }
    
    
        }
    
    
        private static String getPlayerInput(){
            System.out.println("Enter a hero‘s name: ");
    
            Scanner scanner = new Scanner(System.in);
            String name = scanner.nextLine();
    
            return name;
        }
    
    
    }

===============================================================================================

第二版，随着版本迭代，需要添加更多英雄，用户可以选择的英雄要多了

第二个英雄：Irelia

public class SecondHeroTrelia {
    
        public void q(){
            System.out.println("Trelia 释放了 Q 技能");
        }
    
        public void w(){
            System.out.println("Trelia 释放了 W 技能");
        }
    
        public void e(){
            System.out.println("Trelia 释放了 E 技能");
        }
    
        public void r(){
            System.out.println("Trelia 释放了 R 技能");
        }
    
    
    }

第三个英雄：ThirdHeroCamille

public class ThirdHeroCamille {
    
        public void q(){
            System.out.println("Camille 释放了 Q 技能");
        }
    
        public void w(){
            System.out.println("Camille 释放了 W 技能");
        }
    
        public void e(){
            System.out.println("Camille 释放了 E 技能");
        }
    
        public void r(){
            System.out.println("Camille 释放了 R 技能");
        }
    
    
    }

第二版的   Main

public class Main {
    
    
        public static void main(String[] args) {
            String name = Main.getPlayerInput();
            //选择英雄之后，释放一个技能
            switch (name){
                case "Diana":
                    FirstHeroDiana diana = new FirstHeroDiana();
                    diana.r();
    
                    break;
                case "Irelia":
                    SecondHeroIrelia irelia = new SecondHeroIrelia();
                    irelia.q();
    
                    break;
                case "Camille":
                    ThirdHeroCamille camille = new ThirdHeroCamille();
                    camille.e();
    
                    break;
            }
    
    
        }
    
    
        private static String getPlayerInput(){
            System.out.println("Enter a hero‘s name: ");
    
            Scanner scanner = new Scanner(System.in);
            String name = scanner.nextLine();
    
            return name;
        }
    
    
    }

===============================================================================================

> 以上存在的问题是，每次新增英雄都要修改 Main 中的代码，添加新的分支，无法满足开闭原则，但这种也是最为习惯的代码写法

第三版：使用Interface的抽象风格

新增 interface，让所有的 Hero 类都实现 interface

ISKill

public interface ISkill {
    
        public void q();
    
        public void w();
    
        public void e();
    
        public void r();
    
    
    
    
    }

第一个英雄：FirstHeroDiana

public class FirstHeroDiana implements ISkill {
    
        @Override
        public void q() {
            System.out.println("Camille 释放了 Q 技能");
        }
    
        @Override
        public void w() {
            System.out.println("Camille 释放了 W 技能");
        }
    
        @Override
        public void e() {
            System.out.println("Camille 释放了 E 技能");
        }
    
        @Override
        public void r() {
            System.out.println("Camille 释放了 R 技能");
        }
    }

第二个英雄：SecondHeroIrelia

public class SecondHeroIrelia  implements ISkill{
    
        @Override
        public void q() {
            System.out.println("Camille 释放了 Q 技能");
        }
    
        @Override
        public void w() {
            System.out.println("Camille 释放了 W 技能");
        }
    
        @Override
        public void e() {
            System.out.println("Camille 释放了 E 技能");
        }
    
        @Override
        public void r() {
            System.out.println("Camille 释放了 R 技能");
        }
    }

第三个英雄：ThirdHeroCamille

public class ThirdHeroCamille implements ISkill{
    
    
        @Override
        public void q() {
            System.out.println("Camille 释放了 Q 技能");
        }
    
        @Override
        public void w() {
            System.out.println("Camille 释放了 W 技能");
        }
    
        @Override
        public void e() {
            System.out.println("Camille 释放了 E 技能");
        }
    
        @Override
        public void r() {
            System.out.println("Camille 释放了 R 技能");
        }
    }

第三版的   Main

public class Main {
    
    
        public static void main(String[] args) {
            String name = getPlayerInput();
    
            ISkill iSkill = null;
    
            switch (name){
                case "FirstHeroDiana":
                    iSkill = new FirstHeroDiana();
                    break;
    
                case "SecondHeroIrelia":
                    iSkill = new SecondHeroIrelia();
                    break;
    
                case "ThirdHeroCamille":
                    iSkill = new ThirdHeroCamille();
                    break;
    
            }
    
            try {
                iSkill.r();
            }catch (Exception e){
                e.printStackTrace();
            }
    
    
        }
    
    
        private static String getPlayerInput(){
            System.out.println("Enter a hero‘s name: ");
    
            Scanner scanner = new Scanner(System.in);
            String name = scanner.nextLine();
    
            return name;
        }
    
    
    }

===============================================================================================

第四版，原来的Main中存在switch，第三版中还是存在switch，虽然实现了 interface 统一方法调用，但无法统一实例化

> 第三版 比 第二版看起来差别不大，因为第三版既没有把switch 干掉，也没有解决开闭原则的问题，如果有第四个英雄出现，还是得在switch中增加一个条件分之，依然是改动了主体代码，没有解决根本问题
> 
> 如果只用一个 interface 就能实现开闭原则，那还要IOC 和DI这些有什么用呢？

> **单纯的 interface 在某种程度上可以统一方法的调用，但不能统一对象的实例化，抽象的难点在于对象实例化的统一**
> 
> **前面三版代码，总是要先实例化一个对象，然后再调用对象的方法，这也是面向对象常做的事情，即完成一系列的业务逻辑**
> 
> **如果想让一段代码保持稳定，那么在这段代码中就不能出现 new 这种操作，这样才能逐步实现OCP**
> 
> **实质是一段代码要保存稳定，就不应该负责对象的实例化**
> 
> **对象的实例化过程是不可消除的，可以把对象实例化的过程转移到其他的代码片段里**
> 
> 有时候在代码中不仅有实例化对象然后调用方法，还经常会给对象赋值（经常是在构造参数里赋值），但这个操作也可以归结到对象的实例化，是一个实例化的子项

> 把对象实例化的过程转移到其他的代码片段里，可以使用设计模式中的工厂模式
> 
> 工厂模式也分三种子模式：
> 
>  *  简单工厂模式
>  *  普通工厂模式
>  *  抽象工厂模式

三个 Hero 类以及ISkill 接口不变，新增 HeroFactory 工厂类

public class HeroFactory {
    
        public static ISkill getGero(String name){
            ISkill iSkill = null;
    
            switch (name){
                case "FirstHeroDiana":
                    iSkill = new FirstHeroDiana();
                    break;
    
                case "SecondHeroIrelia":
                    iSkill = new SecondHeroIrelia();
                    break;
    
                case "ThirdHeroCamille":
                    iSkill = new ThirdHeroCamille();
                    break;
    
            }
    
            return iSkill;
        }
    }

Main

public class Main {
    
    
        public static void main(String[] args) {
            String name = getPlayerInput();
            ISkill iSkill = HeroFactory.getGero(name);
    
            iSkill.e();
    
        }
    
    
        private static String getPlayerInput(){
            System.out.println("Enter a hero‘s name: ");
    
            Scanner scanner = new Scanner(System.in);
            String name = scanner.nextLine();
    
            return name;
        }
    
    
    }

> 如果将来再新增一个Hero，Main中的代码是否需要更改？对于Main来说，确实完成了OCP，但仅限于Main方法，因为HeroFactory中的代码依然需要改动，如果解释这种情况？
> 
> 很多资料中提到，使用工厂模式可以解决new的问题，但只是对于工厂来讲，还是需要改动代码，这不是冲突了？是否OCP是一个伪需求呢？
> 
> 假如HeroFactory.getGero(name); 不是一个静态方法，而是一个实例方法，这样在调用该方法时，工厂还是得new

===============================================================================================

第四版中，引入了HeroFactory使得Main的稳定性，但却使得HeroFactory的代码不稳定。

HeroFactory 的代码是不稳定的，新增Hero的时候是需要改动的，但Main是不需要的

> 稳定具有相对性，代码中总是会存在着不稳定，所以要尽可能的隔离这些不稳定代码，保证其他代码是稳定的。
> 
> 还是没有意义？换个角度思考，引入了HeroFactory使得Main的稳定性，但如果有各种各样的HeroFactory，还是需要改动很多很多的代码
> 
> 设想一下，有一个总的工厂，把整个项目所有的变动，都封装在一起，成为一个超级的HeroFactory，从而达到整个项目中，除了这个超级工厂外，所有的代码都是稳定的
> 
> 代码中不稳定的本质原因是什么？软件总是存在着变化的，正式由于这种变化，造成了代码中的不稳定

> 通过反射机制消除所有的变化，计算机里的代码，其实是现实世界里的规律，或者是业务的映射。
> 
> 使用计算机的代码模拟现实世界中的业务，从而使用代码来解决现实世界中的一些业务问题

新建一个 reflect包，将第四版中的英雄包和英雄工厂类都拷贝到reflect下

第五版：修改：HeroFactory（通过反射与元类的方式）

> 元类：类是对象的抽象，或者类是用来描述一个对象的；元类是用来描述一个类的，通过元类直接实例化一个对象

public class HeroFactory {
    
        public static ISkill getGero(String name) throws Exception {
            ISkill iSkill = null;
            //"reflect"  表示完整包
            String classStr = "reflect" + name;
            Class<?> aClass = Class.forName(classStr);
            Object o = aClass.newInstance();
    
            return (ISkill)o;
        }
    }

其他类不改

> 上述代码使用了  工厂模式中的简单模式 + 反射机制 ，但每一次用户输入一次，都要反射一次，但反射的性能是比较低的
> 
> Spring 当实例化一个对象之后，会把对象放到缓存中，下次再要创建相同对象的时候，直接从缓存中取出
> 
> 工厂模式+反射并不是IOC和DI，上述实现的仅仅只是使得代码变得稳定，但没有应用到 IOC 和 DI ，依然是常规的正向思维

改动配置文件，是否违反OCP？

> 配置文件不应该理解为系统的一部分了，配置文件更多的时候是属于系统外部的文件，而不属于代码本身

===============================================================================================

IOC 和 DI

> 以前是主动向容器要一个对象，现在是反过来，容器主动把对象给出来

为什么引入容器后可以让系统变得稳定？

> [https://www.iteye.com/blog/1141338892-2306698][https_www.iteye.com_blog_1141338892-2306698]

IOC、DI、DIP

> IOC：控制反转
> 
> DI：依赖注入
> 
> DIP：依赖倒置（Dependency Inversion Principle）
> 
>  *  高层模块（抽象）不应该依赖低层模块（具体实现），两者都应该依赖抽象
>  *  抽象不应该依赖细节
>  *  细节应该依赖抽象

DI （*Dependency* Injection）依赖注入的意义

> 对象与对象之间肯定是要产生依赖的，这个依赖肯定是不可避免的，面向对象就是对象之间相互作用
> 
> 关键是产生这个依赖的方式是有多种多样的，最常见的就是 new，但这个是最不稳定的
> 
> 换一种方式，即让容器把对象给注入进来，这样也产生了依赖，但产生依赖的形式是不同的，它是注入进来的
> 
>  *  属性注入
> 
>     public class A {
>         private IC ic;
>     
>         private void print(){
>             this.ic.print();
>         }
>     
>         public void setIc(IC ic) {
>             this.ic = ic;
>         }
>     }
> 
>  *  构造注入
> 
>     public A(IC ic) {
>         this.ic = ic;
>      }
> 
>  *  接口注入
>  *  .........

动态语言里是否可以实现依赖注入？动态语言是否能够实现依赖注入？

> 动态语言也是有必要实现依赖注入的，同时也可以实现依赖注入
> 
> OCP其实是所有语言都需要面对的问题，因为这是软甲工程里需要解决的问题
> 
> 软甲工程和语言无关
> 
> 容器的作用是在装配对象（依赖注入在更高角度上的意义）

IOC 本身是非常抽象和模糊的，它的具体实现就是DI，

> IOC的抽象概念：
> 
>  *  控制权（对于一个程序的控制权来说，主要的有程序员与用户，但最主要还是程序员。如果程序需求变化，在增加需求的类，还要更改控制的代码，所以这些控制代码还是由程序员控制的）

举个栗子

> 想像一下，一个积木生产厂家（程序员），只负责生产和设计一个一个的积木（类），由玩家/用户搭建各类成品。

[https_www.iteye.com_blog_1141338892-2306698]: https://www.iteye.com/blog/1141338892-2306698