抽象 订阅
抽象是从众多的事物中抽取出共同的、本质性的特征,而舍弃其非本质的特征的过程。具体地说,抽象就是人们在实践的基础上,对于丰富的感性材料通过去粗取精、去伪存真、由此及彼、由表及里的加工制作,形成概念、判断、推理等思维形式,以反映事物的本质和规律的方法。 [1] 展开全文
抽象是从众多的事物中抽取出共同的、本质性的特征,而舍弃其非本质的特征的过程。具体地说,抽象就是人们在实践的基础上,对于丰富的感性材料通过去粗取精、去伪存真、由此及彼、由表及里的加工制作,形成概念、判断、推理等思维形式,以反映事物的本质和规律的方法。 [1]
信息
过    程
分离、提纯、简略 [1]
类    别
表征性抽象、原理性抽象 [2]
中文名
抽象 [1]
外文名
abstract [1]
抽象抽象的概念
抽象是从众多的事物中抽取出共同的、本质性的特征,而舍弃其非本质的特征的过程。具体地说,抽象就是人们在实践的基础上,对于丰富的感性材料通过去粗取精、去伪存真、由此及彼、由表及里的加工制作,形成概念、判断、推理等思维形式,以反映事物的本质和规律的方法。 [1]  实际上,抽象是与具体相对应的概念,具体是事物的多种属性的总和,因而抽象亦可理解为由具体事物的多种属性中舍弃了若干属性而固定了另一些属性的思维活动。 [1] 
收起全文
精华内容
下载资源
问答
  • 抽象

    千次阅读 2021-01-21 20:52:10
    抽象就是用abstract关键字修饰 一般来说面向对象的三大特性 封装、继承、多态,但是有的国外书籍将抽象也列为面向对象的第四大特征!!!! 抽象类的特点 1.方法只有声明没有实现时,该方法就是抽象方法【不是空实现...

    抽象就是用abstract关键字修饰

    一般来说面向对象的三大特性 封装、继承、多态,但是有的国外书籍将抽象也列为面向对象的第四大特征!!!!

    抽象类的特点
    1.方法只有声明没有实现时,该方法就是抽象方法【不是空实现方法体,没有{}】,需要被abstract修饰,否则语 法报错。抽象方法必须定义在抽象类中,该类必须也被abstract修饰

    2.不能定义抽象构造函数 抽象类中可以定义构造器,也可以不定义构造器,使用系统默认提供的无参构造器,但是自定义构 造器不能private 抽象类不能是final class,final类不能被继承,从语法的角度上说不允许继承,不是构造器的原 因。

    3.不能定义抽象静态方法

    4.抽象类不能直接创建对象,只能通过继承的方式由子类实现对应的抽象方法;

    5.所有抽象类的子类必须实现抽象父类中的所有抽象方法或者自己也声明成抽象类[没有实现所有的抽象方法]

    6.抽象类除了可以有抽象方法,也可以有非抽象方法,允许静态方法

    抽象类的作用
    在面向对象方法中,抽象类主要用来进行类型隐藏。构造出一个固定的一组行为的抽象描述,但是这组行为却能够 有任意个可能的具体实现方式。这个抽象描述就是抽象类,而这一组任意个可能的具体实现则表现为所有可能的派 生类。模块可以操作一个抽象体。由于模块依赖于一个固定的抽象体,因此它可以是不允许修改的
    通过从这个抽象体派生,也可扩展此模块的行为功能。为了能够实现面向对象设计的一个最核心的原则开闭原则 OCP,抽象类是其中的关键所在
    抽象类往往用来表征对问题领域进行分析、设计中得出的抽象概念,是对一系列看上去不同,但是本质上相同的具 体概念的抽象

    没有抽象构造器的概念,但是在抽象类中可以有构造器,抽象类也是类,所以说他具备类的属性,只是说对于抽象类而言,可以在抽象类中定义抽象方法!

    展开全文
  • Java抽象类 详解

    万次阅读 多人点赞 2016-10-05 00:06:35
    一、抽象类的基本概念普通类是一个完善的功能类,可以直接产生实例化对象,并且在普通类中可以包含有构造方法、普通方法、static方法、常量和变量等内容。而抽象类是指在普通类的结构里面增加抽象方法的组成部分。...

    一、抽象类的基本概念

    普通类是一个完善的功能类,可以直接产生实例化对象,并且在普通类中可以包含有构造方法、普通方法、static方法、常量和变量等内容。而抽象类是指在普通类的结构里面增加抽象方法的组成部分。

    那么什么叫抽象方法呢?在所有的普通方法上面都会有一个“{}”,这个表示方法体,有方法体的方法一定可以被对象直接使用。而抽象方法,是指没有方法体的方法,同时抽象方法还必须使用关键字abstract做修饰

    拥有抽象方法的类就是抽象类,抽象类要使用abstract关键字声明。

    范例:定义一个抽象类

    abstract class A{//定义一个抽象类
    	
    	public void fun(){//普通方法
    		System.out.println("存在方法体的方法");
    	}
    	
    	public abstract void print();//抽象方法,没有方法体,有abstract关键字做修饰
    	
    }
    

    二、抽象类的使用

    我们先看范例。
    范例:直接实例化抽象类的对象

    package com.wz.abstractdemo;
    
    abstract class A{//定义一个抽象类
    	
    	public void fun(){//普通方法
    		System.out.println("存在方法体的方法");
    	}
    	
    	public abstract void print();//抽象方法,没有方法体,有abstract关键字做修饰
    	
    }
    
    public class TestDemo {
    
    	public static void main(String[] args) {
    		A a = new A();
    	}
    }
    

    运行:

    Exception in thread "main" java.lang.Error: Unresolved compilation problem: 
    	Cannot instantiate the type A
    
    	at com.wz.abstractdemo.TestDemo.main(TestDemo.java:15)
    
    

    从上可知,A是抽象的,无法直接进行实例化操作。为什么不能直接实例化呢?当一个类实例化之后,就意味着这个对象可以调用类中的属性或者放过了,但在抽象类里存在抽象方法,而抽象方法没有方法体,没有方法体就无法进行调用。既然无法进行方法调用的话,又怎么去产生实例化对象呢。

    抽象类的使用原则如下:
    (1)抽象方法必须为public或者protected(因为如果为private,则不能被子类继承,子类便无法实现该方法),缺省情况下默认为public;
    (2)抽象类不能直接实例化,需要依靠子类采用向上转型的方式处理;
    (3)抽象类必须有子类,使用extends继承,一个子类只能继承一个抽象类;
    (4)子类(如果不是抽象类)则必须覆写抽象类之中的全部抽象方法(如果子类没有实现父类的抽象方法,则必须将子类也定义为为abstract类。);

    范例:

    package com.wz.abstractdemo;
    
    abstract class A{//定义一个抽象类
    	
    	public void fun(){//普通方法
    		System.out.println("存在方法体的方法");
    	}
    	
    	public abstract void print();//抽象方法,没有方法体,有abstract关键字做修饰
    	
    }
    //单继承
    class B extends A{//B类是抽象类的子类,是一个普通类
    
    	@Override
    	public void print() {//强制要求覆写
    		System.out.println("Hello World !");
    	}
    	
    }
    public class TestDemo {
    
    	public static void main(String[] args) {
    		A a = new B();//向上转型
    		
    		a.print();//被子类所覆写的过的方法
    	}
    }
    
    

    运行结果:

    Hello World !
    
    

    现在就可以清楚的发现:
    (1)抽象类继承子类里面有明确的方法覆写要求,而普通类可以有选择性的来决定是否需要覆写;
    (2)抽象类实际上就比普通类多了一些抽象方法而已,其他组成部分和普通类完全一样;
    (3)普通类对象可以直接实例化,但抽象类的对象必须经过向上转型之后才可以得到。

    虽然一个类的子类可以去继承任意的一个普通类,可是从开发的实际要求来讲,普通类尽量不要去继承另外一个普通类,而是去继承抽象类。

    三、抽象类的使用限制

    (1)抽象类中有构造方法么?
    由于抽象类里会存在一些属性,那么抽象类中一定存在构造方法,其存在目的是为了属性的初始化。
    并且子类对象实例化的时候,依然满足先执行父类构造,再执行子类构造的顺序。

    范例如下:

    package com.wz.abstractdemo;
    
    abstract class A{//定义一个抽象类
    	
    	public A(){
    		System.out.println("*****A类构造方法*****");
    	}
    
    	public abstract void print();//抽象方法,没有方法体,有abstract关键字做修饰
    	
    }
    //单继承
    class B extends A{//B类是抽象类的子类,是一个普通类
    
    	public B(){
    		System.out.println("*****B类构造方法*****");
    	}
    	
    	@Override
    	public void print() {//强制要求覆写
    		System.out.println("Hello World !");
    	}
    	
    }
    public class TestDemo {
    
    	public static void main(String[] args) {
    		A a = new B();//向上转型
    	}
    
    }
    
    

    执行结果:

    *****A类构造方法*****
    *****B类构造方法*****
    

    (2)抽象类可以用final声明么?
    不能,因为抽象类必须有子类,而final定义的类不能有子类;

    (3)抽象类能否使用static声明?
    先看一个关于外部抽象类的范例:

    package com.wz.abstractdemo;
    
    static abstract class A{//定义一个抽象类
    	
    	public abstract void print();
    	
    }
    
    class B extends A{
    	
    	public void print(){
    		System.out.println("**********");
    	}
    }
    public class TestDemo {
    
    	public static void main(String[] args) {
    		A a = new B();//向上转型
    		a.print();
    	}
    
    }
    
    

    执行结果

    Exception in thread "main" java.lang.Error: Unresolved compilation problem: 
    	Illegal modifier for the class A; only public, abstract & final are permitted
    
    	at com.wz.abstractdemo.A.<init>(TestDemo.java:3)
    	at com.wz.abstractdemo.B.<init>(TestDemo.java:9)
    	at com.wz.abstractdemo.TestDemo.main(TestDemo.java:18)
    
    

    再看一个关于内部抽象类:

    package com.wz.abstractdemo;
    
    abstract class A{//定义一个抽象类
    	
    	static abstract class B{//static定义的内部类属于外部类
    		public abstract void print();
    	}
    	
    }
    
    class C extends A.B{
    	
    	public void print(){
    		System.out.println("**********");
    	}
    }
    public class TestDemo {
    
    	public static void main(String[] args) {
    		A.B ab = new C();//向上转型
    		ab.print();
    	}
    
    }
    
    

    执行结果:

    **********
    

    由此可见,外部抽象类不允许使用static声明,而内部的抽象类运行使用static声明。使用static声明的内部抽象类相当于一个外部抽象类,继承的时候使用“外部类.内部类”的形式表示类名称。

    (4)可以直接调用抽象类中用static声明的方法么?
    任何时候,如果要执行类中的static方法的时候,都可以在没有对象的情况下直接调用,对于抽象类也一样。
    范例如下:

    package com.wz.abstractdemo;
    
    abstract class A{//定义一个抽象类
    	
    	public static void print(){
    		System.out.println("Hello World !");
    	}
    	
    }
    
    public class TestDemo {
    
    	public static void main(String[] args) {
    		A.print();
    	}
    
    }
    
    

    运行结果:

    Hello World !
    
    

    (5)有时候由于抽象类中只需要一个特定的系统子类操作,所以可以忽略掉外部子类。这样的设计在系统类库中会比较常见,目的是对用户隐藏不需要知道的子类。
    范例如下:

    package com.wz.abstractdemo;
    
    abstract class A{//定义一个抽象类
    	public abstract void print();
    	
    	private static class B extends A{//内部抽象类子类
    		
    		public void print(){//覆写抽象类的方法
    			System.out.println("Hello World !");
    		}
    	}
    	
    	//这个方法不受实例化对象的控制
    	public static A getInstance(){
    		return new B();
    	}
    	
    }
    
    public class TestDemo {
    
    	public static void main(String[] args) {
    		
    		//此时取得抽象类对象的时候完全不需要知道B类这个子类的存在
    		A a = A.getInstance();
    		a.print();
    	}
    }
    
    

    运行结果:

    Hello World !
    

    四、抽象类的应用——模板设计模式

    例如,现在有三类事物:
    (1)机器人:充电,工作;
    (2)人:吃饭,工作,睡觉;
    (3)猪:进食,睡觉。
    现要求实现一个程序,可以实现三种不同事物的行为。

    先定义一个抽象行为类:

    package com.wz.abstractdemo;
    
    public abstract class Action{
    	
    	public static final int EAT = 1 ;
    	public static final int SLEEP = 3 ;
    	public static final int WORK = 5 ;
    	
    	public abstract void eat();
    	public abstract void sleep();
    	public abstract void work();
    	
    	public void commond(int flags){
    	  switch(flags){
    		case EAT:
    			this.eat();
    			break;
    		case SLEEP:
    			this.sleep();
    			break;
    		case WORK:
    			this.work();
    			break;
    		case EAT + SLEEP:
    			this.eat();
    			this.sleep();
    			break;
    		case SLEEP + WORK:
    			this.sleep();
    			this.work();
    			break;
    		default:
    			break;
    		}
    	}
    }
    
    

    定义一个机器人的类:

    package com.wz.abstractdemo;
    
    public class Robot extends Action{
    
    	@Override
    	public void eat() {
    		System.out.println("机器人充电");
    		
    	}
    
    	@Override
    	public void sleep() {
    		
    	}
    
    	@Override
    	public void work() {
    		System.out.println("机器人工作");
    		
    	}
    	
    }
    
    
    

    定义一个人的类:

    package com.wz.abstractdemo;
    
    public class Human extends Action{
    
    	@Override
    	public void eat() {
    		System.out.println("人吃饭");
    		
    	}
    
    	@Override
    	public void sleep() {
    		System.out.println("人睡觉");
    		
    	}
    
    	@Override
    	public void work() {
    		System.out.println("人工作");
    		
    	}
    	
    }
    

    定义一个猪的类:

    package com.wz.abstractdemo;
    
    public class Pig extends Action{
    
    	@Override
    	public void eat() {
    		System.out.println("猪进食");
    		
    	}
    
    	@Override
    	public void sleep() {
    		System.out.println("猪睡觉");
    		
    	}
    
    	@Override
    	public void work() {
    		
    		
    	}
    	
    }
    
    

    测试主类:

    package com.wz.abstractdemo;
    
    public class AbstractDemo {
    
    	public static void main(String[] args) {
    		
    		fun(new Robot());
    		
    		fun(new Human());
    		
    		fun(new Pig());
    
    	}
    	
    	public static void fun(Action act){
    		act.commond(Action.EAT);
    		act.commond(Action.SLEEP);
    		act.commond(Action.WORK);
    	}
    
    }
    
    

    运行结果:

    机器人充电
    机器人工作
    人吃饭
    人睡觉
    人工作
    猪进食
    猪睡觉
    
    

    所有的子类如果要想正常的完成操作,必须按照指定的方法进行覆写才可以,而这个时候抽象类所起的功能就是一个类定义模板的功能。

    展开全文
  • 程序员必备的思维能力:抽象思维

    万次阅读 多人点赞 2021-02-12 18:03:28
    若想捉大鱼,就得潜入深渊。深渊里的鱼更有力,也更纯净。硕大而抽象,且非常美丽。——大卫·林奇抽象思维是我们工程师最重要的思维能力。因为软件技术 本质上就是一门抽象的艺术。我们的工作是存思维...

    若想捉大鱼,就得潜入深渊。深渊里的鱼更有力,也更纯净。硕大而抽象,且非常美丽。——大卫·林奇

    抽象思维是我们工程师最重要的思维能力。因为软件技术 本质上就是一门抽象的艺术。我们的工作是存思维的“游戏”,虽然我们在使用键盘、显示器,打开电脑可以看到主板、硬盘等硬件。但我们即看不到程序如何被执行,也看不到0101是如何被CPU处理的。

    我们工程师每天都要动用抽象思维,对问题域进行分析、归纳、综合、判断、推理。从而抽象出各种概念,挖掘概念和概念之间的关系,对问题域进行建模,然后通过编程语言实现业务功能。所以,我们大部分的时间并不是在写代码,而是在梳理需求,理清概念,当然,也包括尝试看懂那些“该死的、别人写的”代码。

    在我接触的工程师中,能深入理解抽象概念的并不多,能把抽象和面向对象、架构设计进行有机结合,能用抽象思维进行问题分析、化繁为简的同学更是凤毛麟角。

    对于我本人而言,每当我对抽象有进一步的理解和认知,我都能切身感受到它给我在编码和设计上带来的质的变化。同时感慨之前对抽象的理解为什么如此肤浅。如果时间可以倒流的话,我希望我在我职业生涯的早期,就能充分意识到抽象的重要性,能多花时间认真的研究它,深刻的理解它,这样应该可以少走很多弯路。

    1.1 什么是抽象

    关于抽象的定义,百度百科是这样说的:

    抽象是从众多的事物中抽取出共同的、本质性的特征,而舍弃其非本质的特征的过程。具体地说,抽象就是人们在实践的基础上,对于丰富的感性材料通过去粗取精、去伪存真、由此及彼、由表及里的加工制作,形成概念、判断、推理等思维形式,以反映事物的本质和规律的方法。
    实际上,抽象是与具体相对应的概念,具体是事物的多种属性的总和,因而抽象亦可理解为由具体事物的多种属性中舍弃了若干属性而固定了另一些属性的思维活动。[1]

    Wikipedia的解释是:

    抽象是指为了某种目的,对一个概念或一种现象包含的信息进行过滤,移除不相关的信息,只保留与某种最终目的相关的信息。例如,一个皮质的足球,我们可以过滤它的质料等信息,得到更一般性的概念,也就是球。从另外一个角度看,抽象就是简化事物,抓住事物本质的过程。[2]

    简单而言,“抽”就是抽离,“象”就是具象,字面上理解抽象,抽象的过程就是从“具象”事物中归纳出共同特征,“抽取”得到一般化(Generalization)的概念的过程。英文的抽象——abstract来自拉丁文abstractio,它的原意是排除、抽出。

    为了更好的方便你理解抽象,让我们先来看一幅毕加索的画,如下图所示,图的左边是一头水牛,是具象的,右边是毕加索画,是抽象的。怎么样,是不是感觉自己一下子理解了抽象画的含义。 

    可以看到,抽象牛只有几根线条,不过这几根线条是做了高度抽象之后的线条,过滤了水牛的绝大部分细节,保留了牛最本质特征,比如牛角,牛头,牛鞭、牛尾巴等等。这种对细节的舍弃使得“抽象牛”具有更好的泛化(Generalization)能力。可以说,抽象更接近问题的本质。也就是说所有的牛都逃不过这几根线条。

    1.2 抽象和语言是一体的

    关于抽象思维,我们在百度百科上可以看到如下的定义:

    抽象思维,又称词(概念)的思维或者逻辑思维,是指用词(概念)进行判断、推理并得出结论的过程。抽象思维以词(概念)为中介来反映现实。这是思维的最本质特征,也是人的思维和动物心理的根本区别。[3]

    之所以把抽象思维称为词思维或者概念思维,是因为语言和抽象是一体的。当我们说“牛”的时候,说的就是“牛”的抽象,他代表了所有牛共有的特征。同样,当你在程序中创建Cow这个类的时候,道理也是一样。在生活中,我们只见过一头一头具象的牛,“牛”作为抽象的存在,即看不见也摸不着。

    这种把抽象概念作为世界本真的看法,也是古希腊哲学家柏拉图的最重要哲学思想。柏拉图认为,我们所有用感觉感知到的事物,都源于相应的理念。他认为具体事物的“名”,也就是他说的“理念世界”才是本真的东西,具体的一头牛,有大有小,有公有母,颜色、性情、外形各自不同。因此我们不好用个体感觉加以概括,但是这些牛既然都被统称为“牛”,则说明它们必然都源于同一个“理念”,即所谓“牛的理念”或者“理念的牛”,所以它们可以用“牛”加以概括。尚且不论“理念世界”是否真的存在,这是一个哲学问题,但有一点可以确定,我们的思考,对概念的表达都离不开语言。[4]

    这也是为什么,我在做设计和代码审查(Code Review)的时候,会特别关注命名是否合理的原因。因为命名的好坏,在很大程度上反应了我们对一个概念的思考是否清晰,我们的抽象是否合理,反应在代码上就是,代码的可读性、可理解性是不是良好,以及我们的设计是不是到位。

    有人做过一个调查,问程序员最头痛的事情是什么,通过Quora和Ubuntu Forum的调查结果显示,程序员最头疼的事情是命名。如果你曾经为了一个命名而绞尽脑汁,就不会对这个结果感到意外。

    就像Stack Overflow的创始人Joel Spolsky所说的:“起一个好名字应该很难,因为,一个好名字需要把要义浓缩在一到两个词。(Creating good names is hard, but it should be hard, because a great name captures essential meaning in just one or two words)。”

    是的,这个浓缩的过程就是抽象的过程。我不止一次的发现,当我觉得一个地方的命名有些别扭的时候,往往就意味着要么这个地方我没有思考清楚,要么是我的抽象弄错了。

    关于如何命名,我在《代码精进之路》里已经有比较详尽的阐述,这里就不赘述了。

    我想强调的是语言是明晰概念的基础,也是抽象思维的基础,在构建一个系统时,值得我们花很多时间去斟酌、去推敲语言。在我做过的一个项目中,就曾为一个关键实体讨论了两天,因为那是一个新概念,尝试了很多名字,始终感觉到别扭、不好理解。随着我们讨论的深入,对问题域理解的深入,我们最终找到了一个相对比较合适的名字,才肯罢休。

    这样的斟酌是有意义的,因为明晰关键概念,是我们设计中的重要工作。虽然不合理的命名,不合理的抽象也能实现业务功能。但其代价就是维护系统时,极高的认知负荷。随着时间的推移,就没人能搞懂系统的设计了。

    1.3 抽象的层次性

    回到毕加索的抽象画,如下图所示,如果映射到面向对象编程,抽象牛就是抽象类(Abstract Class),代表了所有牛的抽象。抽象牛可以泛化成更多的牛,比如水牛、奶牛、牦牛等。每一种牛都代表了一类(Class)牛,对于每一类牛,我们可以通过实例化,得到一头具体的牛实例(Instance)。 

    从这个简单的案例中,我们可以到抽象的三个特点:

    1. 第一,抽象是忽略细节的。抽象类是最抽象的,忽略的细节也最多,就像抽象牛,只是几根线条而已。在代码中,这种抽象可以是Abstract Class,也可以是Interface。

    2. 第二,抽象代表了共同性质。类(Class)代表了一组实例(Instance)的共同性质,抽象类(Abstract Class)代表了一组类的共同性质。对于我们上面的案例来说,这些共同性质就是抽象牛的那几根线条。

    3. 第三,抽象具有层次性。抽象层次越高,内涵越小,外延越大,也就是说它的涵义越小,泛化能力越强。比如,牛就要比水牛更抽象,因为它可以表达所有的牛,水牛只是牛的一个种类(Class)。

    抽象的这种层次性,是除了抽象概念之外,另一个我们必须要深入理解的概念,因为小到一个方法要怎么写,大到 一个系统要如何架构,以及我们后面第三章要介绍的结构化思维,都离不开抽象层次的概念。

    在进一步介绍抽象层次之前,我们先来理解一下外延和内涵的意思:

    抽象是以概念(词语)来反映现实的过程,每一个概念都有一定的外延和内涵.概念的外延就是适合这个概念的一切对象的范围,而概念的内涵就是这个概念所反映的对象的本质属性的总和.例如“平行四边形”这个概念,它的外延包含着一切正方形、菱形、矩形以及一般的平行四边形,而它的内涵包含着一切平行四边形所共有的“有四条边,两组对边互相平行”这两个本质属性。

    一个概念的内涵愈广,则其外延愈狭;反之,内涵愈狭,则其外延愈广。例如,“平行四边形”的内涵是“有四条边,两组对边互相平行”,而“菱形”的内涵除了这两条本质属性外,还包含着“四边相等”这一本质属性。“菱形”的内涵比“平行四边形”的内涵广,而“菱形”的外延要比“平行四边形”的外延狭。

    所谓的抽象层次就体现在概念的外延和内涵上,这种层次性,基本可以体现在任何事物上,比如一份报纸就存在多个层次上的抽象,“出版品”最抽象,其内涵最小,但外延最大,“出版品”可以是报纸也可以是期刊杂志等。

    1. 一个出版品

    2. 一份报纸

    3. 《旧金山纪事报》

    4. 5 月 18 日的《旧金山纪事报》

    当我要统计美国有多少个出版品,那么就要用到最上面第一层“出版品”的抽象,如果我要查询旧金山5月18日当天的新闻,就要用到最下面第四层的抽象。

    每一个抽象层次都有它的用途,对于我们工程师来说,如何拿捏这个抽象层次是对我们设计能力的考验,抽象层次太高和太低都不行。

    比如,现在要写一个水果程序,我们需要对水果进行抽象,因为水果里面有红色的苹果,我们当然可以建一个RedApple的类,但是这个抽象层次有点低,只能用来表达“红色的苹果”。来一个绿色的苹果,你还得新建一个GreenApple类。

    为了提升抽象层次,我们可以把RedApple类改成Apple类,让颜色变成Apple的属性,这样红色和绿色的苹果就都能表达了。再继续往上抽象,我们还可以得到水果类、植物类等。再往上抽象就是生物、物质了。

    你可以看到,抽象层次越高,内涵越小,外延越大,泛化能力越强。然而,其代价就是业务语义表达能力越弱。 

    具体要抽象到哪个层次,要视具体的情况而定了,比如这个程序是专门研究苹果的可能到Apple就够了,如果是卖水果的可能需要到Fruit,如果是植物研究的可能要到Plant,但很少需要到Object。

    我经常开玩笑说,你把所有的类都叫Object,把所有的参数都叫Map的系统最通用,因为Object和Map的内涵最小,其延展性最强,可以适配所有的扩展。从原理上来说,这种抽象也是对的,万物皆对象嘛。但是这种抽象又有什么意义呢?它没有表达出任何想表达的东西,只是一句正确的废话而已。

    越抽象,越通用,可扩展性越强,然而其语义的表达能力越弱。越具体,越不好延展,然而其语义表达能力很强。所以,对于抽象层次的权衡,是我们系统设计的关键所在,也是区分普通程序员和优秀程序员的关键所在

    1.4 软件中的分层抽象无处不在

    越是复杂的问题越需要分层抽象,分层是分而治之,抽象是问题域的合理划分和概念语义的表达。不同层次提供不同的抽象,下层对上层隐藏实现细节,通过这种层次结构,我们才有可能应对像网络通信、云计算等超级复杂的问题。

    网络通信是互联网最重要的基础实施,但同时它又是一个很复杂的过程,你要知道把数据包传给谁——IP协议,你要知道在这个不可靠的网络上出现状况要怎么办——TCP协议。有这么多的事情需要处理,我们可不可以在一个层次中都做掉呢?当然是可以的,但显然不科学。因此,ISO制定了网络通信的七层参考模型,每一层只处理一件事情,低层为上层提供服务,直到应用层把HTTP,FTP等方便理解和使用的协议暴露给用户。 

    编程语言的发展史也是一个典型的分层抽象的演化史。

    机器能理解的只有机器语言,即各种二进制的01指令。如果我们采用O1的输入方式,其编程效率极低(学过数字电路的同学,体会下用开关实现加减法)。所以我们用汇编语言抽象了二进制指令。然而汇编还是很底层,于是我们用C语言抽象了汇编语言。而高级语言Java是类似于C这样低级语言的进一步抽象,这种逐层抽象极大的提升了我们的编程效率。 

    1.5 重复代码是抽象的缺失

    如果说抽象的本质是共性的话,那么我们代码中的重复代码,是不是就意味着抽象的缺失呢?

    是这样的,重复代码是典型的代码坏味道,其本质问题就是抽象的缺失。因为我们Ctrl+C加Ctrl+V的工作习惯,导致没有对共性代码进行抽取,或者虽然抽取了,只是简单的用了一个Util名字,没有给到一个合适的名字,没有正确的反应这段代码所体现的抽象概念,都属于抽象不到位。

    有一次,我在Review团队代码的时候,发现有一段组装搜索条件的代码,在几十个地方都有重复。这个搜索条件还比较复杂,是以元数据的形式存在数据库中,因此组装的过程是这样的:

    • 首先,我们要从缓存中把搜索条件列表取出来;

    • 然后,遍历这些条件,将搜索的值填充进去;

    //取默认搜索条件
    List<String> defaultConditions = searchConditionCacheTunnel.getJsonQueryByLabelKey(labelKey);
    for(String jsonQuery : defaultConditions){
    	jsonQuery = jsonQuery.replaceAll(SearchConstants.SEARCH_DEFAULT_PUBLICSEA_ENABLE_TIME, String.valueOf(System.currentTimeMillis() / 1000));
    	jsonQueryList.add(jsonQuery);
    }
    //取主搜索框的搜索条件
    if(StringUtils.isNotEmpty(cmd.getContent())){
        List<String> jsonValues = searchConditionCacheTunnel.getJsonQueryByLabelKey(SearchConstants.ICBU_SALES_MAIN_SEARCH);
        for (String value : jsonValues) {
    		String content = StringUtil.transferQuotation(cmd.getContent());
    		value = StringUtil.replaceAll(value, SearchConstants.SEARCH_DEFAULT_MAIN, content);
        	jsonQueryList.add(value);
    	}
    }
    

    简单的重构无外乎就是把这段代码提取出来,放到一个Util类里面给大家复用。然而我认为这样的重构只是完成了工作的一半,我们只是做了简单的归类,并没有做抽象提炼。

    简单分析,不难发现,此处我们是缺失了两个概念:一个是用来表达搜索条件的类——SearchCondition;另一个是用来组装搜索条件的类——SearchConditionAssembler。只有配合命名,显性化的将这两个概念表达出来,才是一个完整的重构。

    重构后,搜索条件的组装会变成一种非常简洁的形式,几十处的复用只需要引用SearchConditionAssembler就好了。

    public class SearchConditionAssembler {
        public static SearchCondition assemble(String labelKey){
            String jsonSearchCondition =  getJsonSearchConditionFromCache(labelKey);
            SearchCondition sc = assembleSearchCondition(jsonSearchCondition);
            return sc;
        }
    }
    

    由此可见,提取重复代码只是我们重构工作的第一步。对重复代码进行概念抽象,寻找有意义的命名才是我们工作的重点

    因此,每一次遇到重复代码的时候,你都应该感到兴奋,想着,这是一次锻炼抽象能力的绝佳机会,当然,测试代码除外。

    1.6 强制类型转换是抽象层次有问题

    面向对象设计里面有一个著名的SOLID原则是由Bob大叔(Robert Martin)提出来的,其中的L代表LSP,就是Liskov Substitution Principle(里氏替换原则)。简单来说,里氏替换原则就是子类应该可以替换任何父类能够出现的地方,并且经过替换以后,代码还能正常工作。

    思考一下,我们在写代码的过程中,什么时候会用到强制类型转换呢?当然是LSP不能被满足的时候,也就是说子类的方法超出了父类的类型定义范围,为了能使用到子类的方法,只能使用类型强制转换将类型转成子类类型。

    举个例子,在苹果(Apple)类上,有一个isSweet()方法是用来判断水果甜不甜的;西瓜(Watermelon)类上,有一个isJuicy()是来判断水分是否充足的;同时,它们都共同继承一个水果(Fruit)类

    此时,我们需要挑选出甜的水果和有水分的习惯,我们会写一个如下的程序:

    public class FruitPicker {
    
        public List<Fruit> pickGood(List<Fruit> fruits){
            return fruits.stream().filter(e -> check(e)).
                    collect(Collectors.toList());
        }
        
        private boolean check(Fruit e) {
            if(e instanceof Apple){
                if(((Apple) e).isSweet()){
                    return true;
                }
            }
            if(e instanceof Watermelon){
                if(((Watermelon) e).isJuicy()){
                    return true;
                }
            }
            return false;
        }
    }
    

    因为pick方法的入参的类型是Fruit,所以为了获得Apple和Watermelon上的特有方法,我们不得不使用instanceof做一个类型判断,然后使用强制类型转换转成子类类型,以便获得他们的专有方法,很显然,这是违背了里式替换原则的。

    这里问题出在哪里?对于这样的代码我们要如何去优化呢?仔细分析一下,我们可以发现,根本原因是因为isSweet和isJuicy的抽象层次不够,站在更高抽象层次也就是Fruit的视角看,我们挑选的就是可口的水果,只是具体到苹果我们看甜度,具体到西瓜我们看水分而已。

    因此,解决方法就是对isSweet和isJuicy进行抽象,并提升一个层次,在Fruit上创建一个isTasty()的抽象方法,然后让苹果和西瓜类分别去实现这个抽象方法就好了。 

    下面是重构后的代码,通过抽象层次的提升我们消除了instanceof判断和强制类型转换,让代码重新满足了里式替换原则。抽象层次的提升使得代码重新变得优雅了。

    public class FruitPicker {
    
        public List<Fruit> pickGood(List<Fruit> fruits){
            return fruits.stream().filter(e -> check(e)).
                    collect(Collectors.toList());
        }
        
        //不再需要instanceof和强制类型转换
        private boolean check(Fruit e) {
            return e.isTasty();
        }
    }
    
    

    所以,每当我们在程序中准备使用instanceof做类型判断,或者用cast做强制类型转换的时候。每当我们的程序不满足LSP的时候。你都应该警醒一下,好家伙,这又是一次锻炼抽象能力的绝佳机会

    1.7 如何提升抽象思维能力

    抽象思维能力是我们人类特有的、与生俱来的能力,除了上面说的在编码过程中可以锻炼抽象能力之外,我们还可以通过一些其他的练习,不断的提升我们的抽象能力。

    多阅读

    为什么阅读书籍比看电视更好呢?因为图像比文字更加具象,阅读的过程可以锻炼我们的抽象能力、想象能力,而看画面的时候会将你的大脑铺满,较少需要抽象和想象。

    这也是为什么我们不提倡让小孩子过多的暴露在电视或手机屏幕前的原因,因为这样不利于他抽象思维的锻炼。

    抽象思维的差别让孩子们的学习成绩从初中开始分化,许多不能适应这种抽象层面训练的,就去读技校了,因为技校比大学会更加具象:车铣刨磨、零部件都能看得见摸得着。体力劳动要比脑力劳动来的简单。

    多总结沉淀

    小时候不理解,语文老师为什么总是要求我们总结段落大意、中心思想什么的。现在回想起来,这种思维训练在基础教育中是非常必要的,其实质就是帮助学生提升抽象思维能力。

    记录也是很好的总结习惯。就拿读书笔记来说,最好不要原文摘录书中的内容,而是要用自己的话总结归纳书中的内容,这样不仅可以加深理解,而且还可以提升自己的抽象思维能力。

    我从四年前开始系统的记录笔记,做总结沉淀,构建自己的知识体系。这种思维训练的好处显而易见,可以说我之前写的《从码农到工匠》和现在正在写的《程序员必备的思维能力》都离不开我总结沉淀的习惯。

    命名训练

    每一次的变量命名、方法命名、类命名都是一次难得的抽象思维训练机会,前面已经说过了,语言和抽象是一体的,命名的好坏直接反应了我们的问题域思考的是否清晰,反应了我们抽象的是否合理。

    现实情况是,我们很多的工程师常常忽略了命名的重要性,只要能实现业务功能,名字从来就不是重点。

    实际上,这是对系统的不负责任,也是对自己的不负责任,更是对后期维护系统的人不负责任。写程序和写文章有很大的相似性,本质上都是在用语言阐述一件事情。试想下,如果文章中用的都是些词不达意的句子,这样的文章谁能看得懂,谁又愿意去看呢。

    同样,我一直强调代码要显性化的表达业务语义,其中命名在这个过程中扮演了极其重要的角色。为了代码的可读性,为了系统的长期可维护性,为了我们自身抽象思维的训练,我们都不应该放过任何一个带有歧义、表达模糊、意不清的命名。

    领域建模训练

    对于技术同学,我们还有一个非常好的提升抽象能力的手段——领域建模。当我们对问题域进行分析、整理和抽象的时候,当我们对领域进行划分和建模的时候,实际上也是在锻炼我们的抽象能力。

    我们可以对自己工作中的问题域进行建模,当然也可以通过阅读一些优秀源码背后的模型设计来学习如何抽象、如何建模。比如,我们知道Spring的核心功能是Bean容器,那么在看Spring源码的时候,我们可以着重去看它是如何进行Bean管理的?它使用的核心抽象是什么?不难发现,Spring是使用了BeanDefinition、BeanFactory、BeanDefinitionRegistry、BeanDefinitionReader等核心抽象实现了Bean的定义、获取和创建。抓住了这些核心抽象,我们就抓住了Spring设计主脉。

    除此之外,我们还可以进一步深入思考,它为什么要这么抽象?这样抽象的好处是什么?以及它是如何支持XML和Annotation(注解)这两种关于Bean的定义的。

    这样的抽象思维锻炼和思考,对提升我们的抽象能力和建模能力非常重要。关于这一点,我深有感触,初入职场的时候,当我尝试对问题域进行抽象和建模的时候,会觉得无从下手,建出来的模型也感觉很别扭。然而,经过长期的、刻意的学习和锻炼之后,很明显可以感觉到我的建模能力和抽象能力都有很大的提升。不但分析问题的速度更快了,而且建出来的模型也更加优雅了。

    1.8 小结

    • 抽象思维是程序员最重要的思维能力,抽象的过程就是寻找共性、归纳总结、综合分析,提炼出相关概念的过程。

    • 语言和抽象是一体的,抽象思维也叫词思维,因为抽象的概念只能通过语言才能表达出来。

    • 抽象是有层次性的,抽象层次越高,内涵越小,外延越大,扩展性越好;反之,抽象层次越低,内涵越大,外延越小,扩展性越差,但语义表达能力越强。

    • 对抽象层次的拿捏,体现了我们的设计功力,视具体情况而定,抽象层次既不能太高,也不能太低。

    • 重复代码意味着抽象缺失,强制类型转换意味着抽象层次有问题,我们可以利用这些信号来重构代码,让代码重新变的优雅。

    • 我们可以通过刻意练习来提升抽象能力,这些练习包括阅读、总结、命名训练、建模训练等。

    [1] https://baike.baidu.com/item/抽象/9021828

    [2] https://zh.wikipedia.org/wiki/抽象化

    [3] https://baike.baidu.com/item/抽象思维

    [4] https://www.sohu.com/a/359915387_260616

    展开全文
  • 当程序员具备了抽象思维

    万次阅读 2021-03-22 14:32:46
    硕大而抽象,且非常美丽。 作者:张建飞 若想捉大鱼,就得潜入深渊。深渊里的鱼更有力,也更纯净。硕大而抽象,且非常美丽。——大卫·林奇 前言 抽象思维是我们工程师最重要的思维能力。因为软件技术 ...

    简介: 若想捉大鱼,就得潜入深渊。深渊里的鱼更有力,也更纯净。硕大而抽象,且非常美丽。

    作者:张建飞

     

    若想捉大鱼,就得潜入深渊。深渊里的鱼更有力,也更纯净。硕大而抽象,且非常美丽。——大卫·林奇

     

     

    前言

     

    抽象思维是我们工程师最重要的思维能力。因为软件技术 本质上就是一门抽象的艺术。我们的工作是存思维的“游戏”,虽然我们在使用键盘、显示器,打开电脑可以看到主板、硬盘等硬件。但我们即看不到程序如何被执行,也看不到 0101 是如何被 CPU 处理的。

     

    我们工程师每天都要动用抽象思维,对问题域进行分析、归纳、综合、判断、推理。从而抽象出各种概念,挖掘概念和概念之间的关系,对问题域进行建模,然后通过编程语言实现业务功能。所以,我们大部分的时间并不是在写代码,而是在梳理需求,理清概念。当然,也包括尝试看懂那些“该死的、别人写的”代码。

     

    在我接触的工程师中,能深入理解抽象概念的并不多,能把抽象和面向对象、架构设计进行有机结合,能用抽象思维进行问题分析、化繁为简的同学更是凤毛麟角。

     

    对于我本人而言,每当我对抽象有进一步的理解和认知,我都能切身感受到它给我在编码和设计上带来的质的变化。同时,感慨之前对抽象的理解为什么如此肤浅。如果时间可以倒流的话,我希望我在我职业生涯的早期,就能充分意识到抽象的重要性,能多花时间认真的研究它,深刻的理解它,这样应该可以少走很多弯路。

     

    什么是抽象

     

    关于抽象的定义,百度百科是这样说的:

     

    抽象是从众多的事物中抽取出共同的、本质性的特征,而舍弃其非本质的特征的过程。具体地说,抽象就是人们在实践的基础上,对于丰富的感性材料通过去粗取精、去伪存真、由此及彼、由表及里的加工制作,形成概念、判断、推理等思维形式,以反映事物的本质和规律的方法。实际上,抽象是与具体相对应的概念,具体是事物的多种属性的总和,因而抽象亦可理解为由具体事物的多种属性中舍弃了若干属性而固定了另一些属性的思维活动。[1]

     

    Wikipedia 的解释是:

     

    抽象是指为了某种目的,对一个概念或一种现象包含的信息进行过滤,移除不相关的信息,只保留与某种最终目的相关的信息。例如,一个皮质的足球,我们可以过滤它的质料等信息,得到更一般性的概念,也就是球。从另外一个角度看,抽象就是简化事物,抓住事物本质的过程。[2]

     

    简单而言,“抽”就是抽离,“象”就是具象,字面上理解抽象,抽象的过程就是从“具象”事物中归纳出共同特征,“抽取”得到一般化(Generalization)的概念的过程。英文的抽象——abstract 来自拉丁文 abstractio,它的原意是排除、抽出。

     

    为了更好的方便你理解抽象,让我们先来看一幅毕加索的画,如下图所示,图的左边是一头水牛,是具象的;右边是毕加索画,是抽象的。怎么样,是不是感觉自己一下子理解了抽象画的含义。

    image.png

     

    可以看到,抽象牛只有几根线条,不过这几根线条是做了高度抽象之后的线条,过滤了水牛的绝大部分细节,保留了牛最本质特征,比如牛角,牛头,牛鞭、牛尾巴等等。这种对细节的舍弃使得“抽象牛”具有更好的泛化(Generalization)能力。

     

    可以说,抽象更接近问题的本质,也就是说所有的牛都逃不过这几根线条。

     

    抽象和语言是一体的

     

    关于抽象思维,我们在百度百科上可以看到如下的定义:

     

    抽象思维,又称词(概念)的思维或者逻辑思维,是指用词(概念)进行判断、推理并得出结论的过程。抽象思维以词(概念)为中介来反映现实。这是思维的最本质特征,也是人的思维和动物心理的根本区别。[3]

     

    之所以把抽象思维称为词思维或者概念思维,是因为语言和抽象是一体的。当我们说“牛”的时候,说的就是“牛”的抽象,他代表了所有牛共有的特征。同样,当你在程序中创建 Cow 这个类的时候,道理也是一样。在生活中,我们只见过一头一头具象的牛,“牛”作为抽象的存在,即看不见也摸不着。

     

    这种把抽象概念作为世界本真的看法,也是古希腊哲学家柏拉图的最重要哲学思想。柏拉图认为,我们所有用感觉感知到的事物,都源于相应的理念。他认为具体事物的“名”,也就是他说的“理念世界”才是本真的东西,具体的一头牛,有大有小,有公有母,颜色、性情、外形各自不同。因此我们不好用个体感觉加以概括,但是这些牛既然都被统称为“牛”,则说明它们必然都源于同一个“理念”,即所谓“牛的理念”或者“理念的牛”,所以它们可以用“牛”加以概括。尚且不论“理念世界”是否真的存在,这是一个哲学问题,但有一点可以确定,我们的思考和对概念的表达都离不开语言。[4]

     

    这也是为什么,我在做设计和代码审查(Code Review)的时候,会特别关注命名是否合理的原因。因为命名的好坏,在很大程度上反映了我们对一个概念的思考是否清晰,我们的抽象是否合理,反应在代码上就是,代码的可读性、可理解性是不是良好,以及我们的设计是不是到位。

     

    有人做过一个调查,问程序员最头痛的事情是什么,通过 Quora 和 Ubuntu Forum 的调查结果显示,程序员最头疼的事情是命名。如果你曾经为了一个命名而绞尽脑汁,就不会对这个结果感到意外。

     

    就像 Stack Overflow 的创始人 Joel Spolsky 所说的:“起一个好名字应该很难,因为,一个好名字需要把要义浓缩在一到两个词。(Creating good names is hard, but it should be hard, because a great name captures essential meaning in just one or two words)。”

     

    是的,这个浓缩的过程就是抽象的过程。我不止一次的发现,当我觉得一个地方的命名有些别扭的时候,往往就意味着要么这个地方我没有思考清楚,要么是我的抽象弄错了。

     

    关于如何命名,我在《代码精进之路》里已经有比较详尽的阐述,这里就不赘述了。

     

    我想强调的是,语言是明晰概念的基础,也是抽象思维的基础,在构建一个系统时,值得我们花很多时间去斟酌、去推敲语言。在我做过的一个项目中,就曾为一个关键实体讨论了两天,因为那是一个新概念,尝试了很多名字,始终感觉到别扭、不好理解。随着我们讨论的深入,对问题域理解的深入,我们最终找到了一个相对比较合适的名字,才肯罢休。

     

    这样的斟酌是有意义的,因为明晰关键概念,是我们设计中的重要工作。虽然不合理的命名、不合理的抽象也能实现业务功能。但其代价就是维护系统时需要极高的认知负荷。随着时间的推移,就没人能搞懂系统的设计了。

     

    抽象的层次性

     

    回到毕加索的抽象画,如下图所示,如果映射到面向对象编程,抽象牛就是抽象类(Abstract Class),代表了所有牛的抽象。抽象牛可以泛化成更多的牛,比如水牛、奶牛、牦牛等。每一种牛都代表了一类(Class)牛,对于每一类牛,我们可以通过实例化,得到一头具体的牛实例(Instance)。

     

    image.png

     

    从这个简单的案例中,我们可以到抽象的三个特点:

     

    1. 抽象是忽略细节的。抽象类是最抽象的,忽略的细节也最多,就像抽象牛,只是几根线条而已。在代码中,这种抽象可以是 Abstract Class,也可以是 Interface。

     

    2. 抽象代表了共同性质。类(Class)代表了一组实例(Instance)的共同性质,抽象类(Abstract Class)代表了一组类的共同性质。对于我们上面的案例来说,这些共同性质就是抽象牛的那几根线条。

     

    3. 抽象具有层次性。抽象层次越高,内涵越小,外延越大,也就是说它的涵义越小,泛化能力越强。比如,牛就要比水牛更抽象,因为它可以表达所有的牛,水牛只是牛的一个种类(Class)。

     

    抽象的这种层次性,是除了抽象概念之外,另一个我们必须要深入理解的概念,因为小到一个方法要怎么写,大到 一个系统要如何架构,以及我们后面第三章要介绍的结构化思维,都离不开抽象层次的概念。

     

    在进一步介绍抽象层次之前,我们先来理解一下外延和内涵的意思:

     

    抽象是以概念(词语)来反映现实的过程,每一个概念都有一定的外延和内涵。概念的外延就是适合这个概念的一切对象的范围,而概念的内涵就是这个概念所反映的对象的本质属性的总和。例如“平行四边形”这个概念,它的外延包含着一切正方形、菱形、矩形以及一般的平行四边形,而它的内涵包含着一切平行四边形所共有的“有四条边,两组对边互相平行”这两个本质属性。

     

    一个概念的内涵愈广,则其外延愈狭;反之,内涵愈狭,则其外延愈广。例如,“平行四边形”的内涵是“有四条边,两组对边互相平行”,而“菱形”的内涵除了这两条本质属性外,还包含着“四边相等”这一本质属性。“菱形”的内涵比“平行四边形”的内涵广,而“菱形”的外延要比“平行四边形”的外延狭。

     

    所谓的抽象层次就体现在概念的外延和内涵上,这种层次性,基本可以体现在任何事物上,比如一份报纸就存在多个层次上的抽象,“出版品”最抽象,其内涵最小,但外延最大,“出版品”可以是报纸也可以是期刊杂志等。

     

    1. 一个出版品
    2. 一份报纸
    3. 《旧金山纪事报》
    4. 5 月 18 日的《旧金山纪事报》

     

    当我要统计美国有多少个出版品,那么就要用到最上面第一层“出版品”的抽象,如果我要查询旧金山 5月18日当天的新闻,就要用到最下面第四层的抽象。

     

    每一个抽象层次都有它的用途,对于我们工程师来说,如何拿捏这个抽象层次是对我们设计能力的考验,抽象层次太高和太低都不行。

     

    比如,现在要写一个水果程序,我们需要对水果进行抽象,因为水果里面有红色的苹果,我们当然可以建一个 RedApple 的类,但是这个抽象层次有点低,只能用来表达“红色的苹果”。来一个绿色的苹果,你还得新建一个 GreenApple 类。

     

    为了提升抽象层次,我们可以把 RedApple 类改成 Apple 类,让颜色变成 Apple 的属性,这样红色和绿色的苹果就都能表达了。再继续往上抽象,我们还可以得到水果类、植物类等。再往上抽象就是生物、物质了。

     

    你可以看到,抽象层次越高,内涵越小,外延越大,泛化能力越强。然而,其代价就是业务语义表达能力越弱。

     

    image.png

     

    具体要抽象到哪个层次,要视具体的情况而定了,比如这个程序是专门研究苹果的可能到 Apple 就够了,如果是卖水果的可能需要到 Fruit,如果是植物研究的可能要到 Plant,但很少需要到 Object。

     

    我经常开玩笑说,你把所有的类都叫 Object,把所有的参数都叫 Map 的系统最通用,因为 Object 和 Map 的内涵最小,其延展性最强,可以适配所有的扩展。从原理上来说,这种抽象也是对的,万物皆对象嘛。但是这种抽象又有什么意义呢?它没有表达出任何想表达的东西,只是一句正确的废话而已。

     

    越抽象,越通用,可扩展性越强,然而其语义的表达能力越弱。越具体,越不好延展,然而其语义表达能力很强。所以,对于抽象层次的权衡,是我们系统设计的关键所在,也是区分普通程序员和优秀程序员的关键所在。

     

    软件中的分层抽象无处不在

     

    越是复杂的问题越需要分层抽象,分层是分而治之,抽象是问题域的合理划分和概念语义的表达。不同层次提供不同的抽象,下层对上层隐藏实现细节,通过这种层次结构,我们才有可能应对像网络通信、云计算等超级复杂的问题。

     

    网络通信是互联网最重要的基础实施,但同时它又是一个很复杂的过程,你要知道把数据包传给谁——IP协议,你要知道在这个不可靠的网络上出现状况要怎么办——TCP 协议。有这么多的事情需要处理,我们可不可以在一个层次中都做掉呢?当然是可以的,但显然不科学。因此,ISO制定了网络通信的七层参考模型,每一层只处理一件事情,低层为上层提供服务,直到应用层把HTTP、FTP等方便理解和使用的协议暴露给用户。

     

    image.png

     

    编程语言的发展史也是一个典型的分层抽象的演化史。

     

    机器能理解的只有机器语言,即各种二进制的 01 指令。如果我们采用 01 的输入方式,其编程效率极低(学过数字电路的同学,体会下用开关实现加减法)。所以我们用汇编语言抽象了二进制指令。

     

    然而汇编还是很底层,于是我们用 C 语言抽象了汇编语言。而高级语言 Java 是类似于 C 这样低级语言的进一步抽象,这种逐层抽象极大的提升了我们的编程效率。

     

    image.png

     

    重复代码是抽象的缺失

     

    如果说抽象的本质是共性的话,那么我们代码中的重复代码,是不是就意味着抽象的缺失呢?

    //取默认搜索条件
    List<String> defaultConditions = searchConditionCacheTunnel.getJsonQueryByLabelKey(labelKey);
    for(String jsonQuery : defaultConditions){
      jsonQuery = jsonQuery.replaceAll(SearchConstants.SEARCH_DEFAULT_PUBLICSEA_ENABLE_TIME, String.valueOf(System.currentTimeMillis() / 1000));
      jsonQueryList.add(jsonQuery);
    }
    //取主搜索框的搜索条件
    if(StringUtils.isNotEmpty(cmd.getContent())){
        List<String> jsonValues = searchConditionCacheTunnel.getJsonQueryByLabelKey(SearchConstants.ICBU_SALES_MAIN_SEARCH);
        for (String value : jsonValues) {
        String content = StringUtil.transferQuotation(cmd.getContent());
        value = StringUtil.replaceAll(value, SearchConstants.SEARCH_DEFAULT_MAIN, content);
          jsonQueryList.add(value);
      }
    }

     

    是这样的,重复代码是典型的代码坏味道,其本质问题就是抽象的缺失。因为我们 Ctrl+C 加 Ctrl+V 的工作习惯,导致没有对共性代码进行抽取;或者虽然抽取了,只是简单的用了一个 Util 名字,没有给到一个合适的名字,没有正确的反应这段代码所体现的抽象概念,都属于抽象不到位。

     

    有一次,我在 Review 团队代码的时候,发现有一段组装搜索条件的代码,在几十个地方都有重复。这个搜索条件还比较复杂,是以元数据的形式存在数据库中,因此组装的过程是这样的:

     

    • 首先,我们要从缓存中把搜索条件列表取出来;
    • 然后,遍历这些条件,将搜索的值填充进去;

     

     

    简单的重构无外乎就是把这段代码提取出来,放到一个Util类里面给大家复用。然而我认为这样的重构只是完成了工作的一半,我们只是做了简单的归类,并没有做抽象提炼。

     

    简单分析,不难发现,此处我们是缺失了两个概念:一个是用来表达搜索条件的类——SearchCondition;另一个是用来组装搜索条件的类——SearchConditionAssembler。只有配合命名,显性化的将这两个概念表达出来,才是一个完整的重构。

     

    重构后,搜索条件的组装会变成一种非常简洁的形式,几十处的复用只需要引用SearchConditionAssembler就好了。

    public class SearchConditionAssembler {
        public static SearchCondition assemble(String labelKey){
            String jsonSearchCondition =  getJsonSearchConditionFromCache(labelKey);
            SearchCondition sc = assembleSearchCondition(jsonSearchCondition);
            return sc;
        }
    }

     

    由此可见,提取重复代码只是我们重构工作的第一步。对重复代码进行概念抽象,寻找有意义的命名才是我们工作的重点。

     

    因此,每一次遇到重复代码的时候,你都应该感到兴奋,想着这是一次锻炼抽象能力的绝佳机会,当然,测试代码除外。

     

    强制类型转换是抽象层次有问题

     

    面向对象设计里面有一个著名的 SOLID 原则是由 Bob 大叔(Robert Martin)提出来的,其中的 L 代表 LSP,就是 Liskov Substitution Principle(里氏替换原则)。简单来说,里氏替换原则就是子类应该可以替换任何父类能够出现的地方,并且经过替换以后,代码还能正常工作。

     

    思考一下,我们在写代码的过程中,什么时候会用到强制类型转换呢?当然是 LSP 不能被满足的时候,也就是说子类的方法超出了父类的类型定义范围,为了能使用到子类的方法,只能使用类型强制转换将类型转成子类类型。

     

    举个例子,在苹果(Apple)类上,有一个 isSweet() 方法是用来判断水果甜不甜的;西瓜(Watermelon)类上,有一个 isJuicy() 是来判断水分是否充足的;同时,它们都共同继承一个水果(Fruit)类。

     

    此时,我们需要挑选出甜的水果和有水分的习惯,我们会写一个如下的程序:

     

    public class FruitPicker {
    ​
        public List<Fruit> pickGood(List<Fruit> fruits){
            return fruits.stream().filter(e -> check(e)).
                    collect(Collectors.toList());
        }
    ​
        private boolean check(Fruit e) {
            if(e instanceof Apple){
                if(((Apple) e).isSweet()){
                    return true;
                }
            }
            if(e instanceof Watermelon){
                if(((Watermelon) e).isJuicy()){
                    return true;
                }
            }
            return false;
        }
    }

     

    因为pick方法的入参的类型是 Fruit,所以为了获得 Apple 和 Watermelon 上的特有方法,我们不得不使用 instanceof 做一个类型判断,然后使用强制类型转换转成子类类型,以便获得他们的专有方法,很显然,这是违背了里式替换原则的。

     

    这里问题出在哪里?对于这样的代码我们要如何去优化呢?仔细分析一下,我们可以发现,根本原因是因为 isSweet 和 isJuicy 的抽象层次不够,站在更高抽象层次也就是 Fruit 的视角看,我们挑选的就是可口的水果,只是具体到苹果我们看甜度,具体到西瓜我们看水分而已。

     

    因此,解决方法就是对 isSweet 和 isJuicy 进行抽象,并提升一个层次,在 Fruit 上创建一个 isTasty() 的抽象方法,然后让苹果和西瓜类分别去实现这个抽象方法就好了。

     

    image.png

     

    下面是重构后的代码,通过抽象层次的提升我们消除了 instanceof 判断和强制类型转换,让代码重新满足了里式替换原则。抽象层次的提升使得代码重新变得优雅了。

     

    public class FruitPicker {    
    public List<Fruit> pickGood(List<Fruit> fruits){        
    return fruits.stream().filter(e -> check(e)).                collect(Collectors.toList());    }    
    //不再需要instanceof和强制类型转换    p
    rivate boolean check(Fruit e) {        
    return e.isTasty();    }}

     

    所以,每当我们在程序中准备使用 instanceof 做类型判断,或者用 cast 做强制类型转换的时候。每当我们的程序不满足 LSP 的时候。你都应该警醒一下,好家伙,这又是一次锻炼抽象能力的绝佳机会。

     

    如何提升抽象思维能力

     

    抽象思维能力是我们人类特有的、与生俱来的能力,除了上面说的在编码过程中可以锻炼抽象能力之外,我们还可以通过一些其他的练习,不断的提升我们的抽象能力。

     

    多阅读

     

    为什么阅读书籍比看电视更好呢?因为图像比文字更加具象,阅读的过程可以锻炼我们的抽象能力、想象能力,而看画面的时候会将你的大脑铺满,较少需要抽象和想象。

    这也是为什么我们不提倡让小孩子过多的暴露在电视或手机屏幕前的原因,因为这样不利于他抽象思维的锻炼。

     

    抽象思维的差别让孩子们的学习成绩从初中开始分化,许多不能适应这种抽象层面训练的,就去读技校了,因为技校比大学会更加具象:车铣刨磨、零部件都能看得见摸得着。体力劳动要比脑力劳动来的简单。

    多总结沉淀

     

    小时候不理解,语文老师为什么总是要求我们总结段落大意、中心思想什么的。现在回想起来,这种思维训练在基础教育中是非常必要的,其实质就是帮助学生提升抽象思维能力。

     

    记录也是很好的总结习惯。就拿读书笔记来说,最好不要原文摘录书中的内容,而是要用自己的话总结归纳书中的内容,这样不仅可以加深理解,而且还可以提升自己的抽象思维能力。

     

    我从四年前开始系统的记录笔记,做总结沉淀,构建自己的知识体系。这种思维训练的好处显而易见,可以说我之前写的《从码农到工匠》和现在正在写的《程序员必备的思维能力》都离不开我总结沉淀的习惯。

    命名训练

     

    每一次的变量命名、方法命名、类命名都是一次难得的抽象思维训练机会,前面已经说过了,语言和抽象是一体的,命名的好坏直接反应了我们的问题域思考的是否清晰,反映了我们抽象的是否合理。

     

    现实情况是,我们很多的工程师常常忽略了命名的重要性,只要能实现业务功能,名字从来就不是重点。

     

    实际上,这是对系统的不负责任,也是对自己的不负责任,更是对后期维护系统的人不负责任。写程序和写文章有很大的相似性,本质上都是在用语言阐述一件事情。试想下,如果文章中用的都是些词不达意的句子,这样的文章谁能看得懂,谁又愿意去看呢。

     

    同样,我一直强调代码要显性化的表达业务语义,其中命名在这个过程中扮演了极其重要的角色。为了代码的可读性,为了系统的长期可维护性,为了我们自身抽象思维的训练,我们都不应该放过任何一个带有歧义、表达模糊、意不清的命名。

     

    领域建模训练

     

    对于技术同学,我们还有一个非常好的提升抽象能力的手段——领域建模。当我们对问题域进行分析、整理和抽象的时候,当我们对领域进行划分和建模的时候,实际上也是在锻炼我们的抽象能力。

     

    我们可以对自己工作中的问题域进行建模,当然也可以通过阅读一些优秀源码背后的模型设计来学习如何抽象、如何建模。比如,我们知道 Spring 的核心功能是 Bean 容器,那么在看Spring源码的时候,我们可以着重去看它是如何进行Bean管理的?它使用的核心抽象是什么?不难发现,Spring 是使用了 BeanDefinition、BeanFactory、BeanDefinitionRegistry、BeanDefinitionReader 等核心抽象实现了 Bean 的定义、获取和创建。抓住了这些核心抽象,我们就抓住了 Spring 设计主脉。

     

    除此之外,我们还可以进一步深入思考,它为什么要这么抽象?这样抽象的好处是什么?以及它是如何支持 XML 和 Annotation(注解)这两种关于 Bean 的定义的。

    这样的抽象思维锻炼和思考,对提升我们的抽象能力和建模能力非常重要。关于这一点,我深有感触,初入职场的时候,当我尝试对问题域进行抽象和建模的时候,会觉得无从下手,建出来的模型也感觉很别扭。

     

    然而,经过长期的、刻意的学习和锻炼之后,很明显可以感觉到我的建模能力和抽象能力都有很大的提升。不但分析问题的速度更快了,而且建出来的模型也更加优雅了。

     

    小结

     

    • 抽象思维是程序员最重要的思维能力,抽象的过程就是寻找共性、归纳总结、综合分析,提炼出相关概念的过程。

     

    • 语言和抽象是一体的,抽象思维也叫词思维,因为抽象的概念只能通过语言才能表达出来。

     

    • 抽象是有层次性的,抽象层次越高,内涵越小,外延越大,扩展性越好;反之,抽象层次越低,内涵越大,外延越小,扩展性越差,但语义表达能力越强。

     

    • 对抽象层次的拿捏,体现了我们的设计功力,视具体情况而定,抽象层次既不能太高,也不能太低。

     

    • 重复代码意味着抽象缺失,强制类型转换意味着抽象层次有问题,我们可以利用这些信号来重构代码,让代码重新变的优雅。

     

    • 我们可以通过刻意练习来提升抽象能力,这些练习包括阅读、总结、命名训练、建模训练等。

    原文链接

    本文为阿里云原创内容,未经允许不得转载。

    展开全文
  • 1、利用关键字abstract在访问修饰符后面修饰抽象类和抽象方法。 2、包含抽象方法的类一定是抽象类,但是抽象类不一定包含抽象方法。 3、抽象类虽然可以声明构造器,但是不能被实例化。 4、继承抽象类的类只有实现了...
  • Scala 抽象抽象方法 抽象字段

    千次阅读 2018-10-29 11:33:01
    1.抽象类 如果父类中的方法不能立即实现,需要依赖其他子类进行覆盖实现则可以将类定义为抽象类。 抽象类的写法: abstract class 类名{ XXXX... } 注: 1.包含抽象成员的类必须声明为抽象类。 2.抽象类不...
  • 抽象

    万次阅读 多人点赞 2019-01-01 11:55:58
    1,抽象类与抽象方法概念 抽象类用来描述一种类型应该具备的基本特征与功能, 具体如何去完成这些行为由子类通过方法重写来完成,如: 犬科均会吼叫,但属于犬科的狼与狗其吼叫内容不同。所以犬科规定了有吼叫功能,但...
  • 抽象类和抽象方法

    千次阅读 2020-04-12 23:36:13
    抽象方法: 就是加上abstract关键字,然后去掉大括号,直接分号结束 抽象类:抽象方法所在的类,必须是抽象类才行,在class之前写上abstract即可。 如何使用: 1.不能直接创建new抽象类对象。 2.必须用一个子类,...
  • C#中的抽象类、抽象属性、抽象方法

    千次阅读 2020-06-10 00:51:31
    前言:本博文讲述了C#面向对象中的抽象类,通过本博文的阅读,读者可以掌握C#抽象类的概念、应用、好处以及一些特性。 文章目录一、抽象类概念二、示例讲解三、抽象类的作用四、使用抽象类的好处五、抽象类总结 一、...
  • 抽象类、抽象函数/抽象方法详解

    千次阅读 2018-06-13 23:55:23
    抽象类、抽象函数/抽象方法详解 C#抽象类运用 本文提供全流程,中文翻译。 China助力快速理解 抽象类、抽象函数 为新手节省宝贵的时间,避免采坑! 抽象类 —— 修饰词 : abstract 抽象父类中的 抽象函数 是不完整...
  • 抽象方法以及抽象

    千次阅读 2019-06-10 11:21:44
    抽象类: eg: 学生类: 成员方法:职位描述 比如说学生类中,有一个职位描述的成员方法,可是学生中有很多的职位 这里只提到职位的描述,但并没说什么职位,班长,组长,职位的描述都是不一样的。 在这里,职位描述...
  • AbstractKnowledgeGraph AbstractKnowledgeGraph, a systematic knowledge graph that concentrate on abstract thing including abstract entity and action. 抽象知识图谱,目前规模50...目标于抽象知识,包括抽象...
  • 抽象类、抽象方法、抽象属性

    千次阅读 2016-05-05 16:25:00
    抽象类一般用于表达一种比较抽象的事物,比如前面所说的“水果”,而抽象方法则说明此抽象类应该具有的某种性质,比如Fruit 类中有一个抽象方法GrowInArea(),说明水果一定有一个最适合其生长的地区,但不同的水果...
  • java抽象类和抽象方法

    千次阅读 2019-01-11 19:29:03
    ****2、抽象类和抽象方法的特点****3、抽象类的使用:****4、抽象类和抽象方法的实例:俄罗斯方块** 1、什么时候使用抽象方法? 当多个类有相同的方法,但方法体不一样,这时候就可以抽取出抽象方法。 2、抽象类和...
  • 抽象类必须要有抽象方法吗?

    万次阅读 2019-04-18 14:01:58
    抽象类必须要有抽象方法吗? 不一定。如 public abstract class TestAbstractClass { public static void notAbstractMethod() { System.out.println("I am not a abstract method."); } } 【Java面试...
  • 面向对象——抽象类与抽象方法

    千次阅读 2020-04-13 09:26:04
    如果一个类不与具体的食物相联系,而只表达一种抽象的概念,仅是作为其派生类的一个基类,这样的类就是派生类,在抽象类中,声明抽象类中声明抽象方法是,如果加上abstract关键字则为抽象方法。abstract 修饰符可...
  • 常用设计模式-抽象工厂

    万次阅读 2020-11-19 17:18:48
    模式简介 工厂模式主要是为创建对象提供了接口。工厂模式按照《Java与模式》中的提法分为三类: 1. 简单工厂模式(Simple Factory) 2. 工厂方法模式(Factory Method) ...在抽象工厂模式中,接口是负责创建一
  • C#抽象类和抽象方法

    千次阅读 2018-10-13 17:59:18
    定义格式: abstract class 类名{ ..... } 抽象类的使用规定: 1.抽象类只能作为其他类的基类,它不能直接被实例化。...5.如果一个非抽象类的基类是抽象类,那么必须要通过覆盖来实现所有继承而来的抽象方...
  • abstract(抽象)类与抽象方法 抽象类可以有抽象方法,也可以有非抽象方法 抽象方法只允许声明,不允许实现 public abstract class A{ void eat(){ System.out.println("eat"); } abstract int getMax();...
  • Java的抽象方法和抽象

    千次阅读 2019-06-08 11:43:15
    抽象方法和抽象类必须使用abstract修饰符来定义,有抽象方法的类只能被定义为抽象类,抽象类里可以没有抽象方法。 抽象类和抽象方法的规则: 抽象类必须使用abstract修饰符来修饰,抽象方法必须使用abstract修饰符...
  • 抽象类就是不能使用new方法进行实例化的类,即没有具体实例对象的类。抽象类有点类似“模板”的作用,目的是根据其格式来创建和修改新的类。对象不能由抽象类直接创建,只可以通过抽象类派生出新的子类,再由其子类...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 384,091
精华内容 153,636
关键字:

抽象