此篇文章讲解目录：

• 面向对象的概念

• 创建对象的方式

• 继承

面向对象的概念

1. 对象:JS中万物皆对象,它是一个泛指,（类似生活中的世界）

2. 类:对象的具体的细分,（类似生活中的人类，动物类）

3. 实例:某一个类别中具体的一个事物（类似人的个体）

转换成生活中的比喻就是：对象是一个抽象的概念,类似于我们的自然界,世界这种概念；我们自然界中分为了 人类、动物类、植物类...,而我们每一个人都是人类中的一个实例

创建对象的方式

1. 单例模式

就是对象类型; Object构造函数或对象字面量都可以用来创建单个对象,下面是字面量的单例模式;(原生的Object构造函创建对象的方式，在某种意义上也是属于单例模式)

单例模式，因为简单易用的原因，是封模块和日常写代码中，最常用的创建方式；

优点：直观，易用，对象的可塑性非常强；

缺点：面向对象，创建对象，有点类似做衣服，单例模式的优点是可定制性非常强，有点类似手工做衣服；虽然可塑性非常强，但是缺点就是如果批量做衣服的时候，效率就非常差；

1. 工厂模式

说白了就是一种函数类型："函数的封装" -->"高内聚低耦合":减少页面中的冗余代码,提高代码的重复利用率；

虽然工厂模式解决了重复创建多个相似对象的问题，但是也存在不可避免的缺点：没有解决对象的识别问题，也就是说某个对象属于什么类，无法通过代码来得知，这是一个普通的函数方法，还是一个类对象

1. 构造函数模式

由于工厂模式的缺点，衍生出了构造函数模式：创建一个自定义的类，并且创建这个类的实例

通过构造函数的方式，创建的对象，我们可以通过instanceof来检测对象的类型，解决了工厂模式所造成的缺点

console.log(t1 instanceof createTshirt) //true

缺点：虽然解决了归属问题，但是构造函数模式也存在一个问题，即上面例子中t1.say 和 t2.say是相同的，函数的意义是高内聚，低耦合，避免同样的事情重复创建，所以才把做相同事务的代码封在一起；构造函数中的函数已经失去了函数的意义了；

1. 原型模式

上述问题的出现，使得我们想到了原型模式：我们创建的每个函数都有一个 prototype （原型）属性，这个属性是一个指针，指向一个对象，而这个对象的用途是包含可以由特定类型的所有实例共享的属性和方法。

原型模式的弊端也很明显：不同的实例之间需要有自己的单独的私有属性和方法，并不能都是公共的！如果每个人的东西都是大家伙的，那就乱套了；

1. 构造函数+原型模式

上面的构造函数模式中，总结的是构造函数中，每个实例的中的内部属性都是相互独立的，为了解决公用的方法才引入原型模式的概念；但是并不是所有的属性和方法都是公共的，这就引申到了公认最佳的创建类的方式构造函数模式+原型模式：

构造函数模式用于定义实例属性，而原型模式用于定义方法和共享的属性。结果，每个实例都会有自己的一份实例属性的副本，但同时又共享着对方法的引用，最大限度地节省了内存。另外，这种混成模式还支持向构造函数传递参数；可谓是集两种模式之长。

继承

1. 原型继承

原型继承的原理：B要继承A,只需要让B的原型等于A的一个实例即可 ->B.prototype=new A;

比如下面的例子（写一个方法，求评委打分的平均分（去掉一个最高分，去掉一个最低分）：

缺点：完全继承了A，自己原型上的方法被吃掉了；杀敌1000，自损800的做法；最主要的问题来自包含引用类型值的原型。包含引用类型值的原型属性会被所有实例共享，即没有办法在不影响所有对象实例的情况下，给超类型的构造函数传递参数。

1. call继承

由于原型继承的缺点，引出了call（apply）继承：在子类B的私有属性中,把父类A当做一个普通的函数执行,并且把里面的this变为子类B的一个实例b,这样的话,在执行A的时候,A中写的this.xxx=xxx都相当于给b增加的私有的属性

call继承解决了对实例B的操作，不影响实例A的问题，但是又引出了其它的问题，也就是说call继承的缺点：只继承了A的私有属性，没有继承A的原型； 如果仅仅是call继承，那么也将无法避免构造函数模式存在的问题——方法都在构造函数中定义，因此函数复用就无从谈起了。

1. call+原型继承（推荐）

既然原型继承与call继承都存在缺点，那么我们把两者结合使用，不就解决了问题了，继续上面的例子，

B无法调用A中的getX方法，如果我们在call继承的基础上，增加了原型继承呢，这个问题就迎刃而解了：

大家好接下来我们会邀请前端架构师以连载的方式，通过30天的实战系统讲解JavaScript的专业知识，欢迎大家关注头条号“互联网IT信息”。