JavaScript公有、私有以及受保护的属性和方法

在某些情景下，你可能希望限制某些属性和方法的暴露程度，使他们不能通过对象实例本身被访问、修改或调用。许多传统语言可以将属性和方法定义为公有、私有或者受保护的。私有变量或方法在类定义之外不能被进行读写；受保护的变量不能被直接访问；但可以通过一个包装方法对其读写。在JS中并没有具体的语法来定义私有或受保护的变量和方法，不过我们可以对声明“类”的方法做一些改变，从而限制对属性和变量的访问。
在构造函数中通过var定义的变量其作用域局限于该构造函数内——在prototype上定义的方法无法访问这个变量，因为这些方法有其自己的作用域。想要通过公有的方法来访问私有的变量，需要创建一个包含两个作用域的新作用域。为此，我们可以创建一个自我执行的函数，称为闭包。代码如下。
JavaScript有一个非强制的但很有用的编程惯例，就是对所以私有变量或函数名加一个下划线（_）作为前缀，以标识他们是私有的。

 var Accommodation = (function(){        function Accommodation(){}                //此处定义的所有变量都是私有的                var _isLocked = false,                _isAlarmed = false,                _alarmMessage = "Alarm actiated!";          //**仅在当前作用域中定义的函数（未在构造函数原型上定义）也是私有的**        function _alarm(){                _isAlarmed = true;                alert(_alarmMessage);        }        function disableAlarm(){                _isAlarmed = false;         }        //**所有定义在原型上方法都是“公有”的，当我们在此处创建的类在闭包结束处被返回后，就可以在当前作用域之外**        //访问这些方法了        Accommodation.prototype.lock = function(){                _isLocked = true;                _alarm();        };        Accommodation.prototype.unlock = function(){                _isLocked = false;                _disableAlarm();        };        //定义一个getter函数来对来对私有变量的值作只读访问——相当于受保护的        Accommodation.prototype.getIsLocked = function(){                return _isLocked ;        };        //setter函数进行只写访问        Accommodation.prototype.setAlarmMessage = function(message){                _alarmMessage = message;        };        //返回在这个作用域中创建的类，使之在外层作用域中即后面代码的所有位置都可用        return Accommodation;}());//创建一个对象实例var house = new Accommodation();house.lock();   //弹出警告消息“Alarm activeted”house._alarm();   //错误！_alarm()未公开，无法直接访问alert(house._isLocked);   //undefined(私有，在闭包外不能访问)house.getIsLocked();      //true(返回isLocked,但不允许对其直接访问，所以该变量是只读的)house.setAlarmMessage("The alarm is now activated!");   house.lock();     //弹出警告消息“The alarm is now activated!”

一般情况下，我们应该讲所有变量和函数都定义为私有，除非明确需要将某些变量和方法公开暴露给外部。即使需要公开暴露，也应先考虑使用getter和setter方法来访问变量，这么做的好处是可以限制他人所能实施的操作，使其只能通过“类”提供的功能完成其需求，这样有助于减少“类”的使用者代码出错的机会。