Почему Javascript не поддерживает наследование по умолчанию?

Question

Как из OOPS базы, я всегда использую наследование как мощный инструмент для повторного использования кода,

Например, если я пишу шахматную программу в OOPS и когда я реализую is-a отношения, как,

Class Piece{ 
    int teamColor; 
    bool isLive; 
    Positon pos; 
    int Points; 
    ....... 
    int getTeamColor(){....} 
    ....... 
}; 

Class Rook extend Piece{ //`is-a` 
...... // No getTeamColor() definition here.. because the parent has the definition. 
}; 

Class Pawn extend Piece{ //`is-a` 
......// No getTeamColor() definition here.. because the parent has the definition. 
}; 

I мог бы сделать это с отношением has-a в javascript, но недостаток, который я вижу, - это Я должен переопределить каждую функцию в производном классе.

Пример: переопределение getTeamColor() снова в каждом ладья, конь, пешки, король .... и т.д ..

 var Pawn = function(teamColor,pos){ 
    var piece = new Piece(teamColor,pos); 
    ....... 

    this.getTeamColor = function(){   
      return piece.getTeamColor(); 
    }; 
    } 

Мой вопрос, Почему Javascript оленья кожа поддерживает классическое наследование в качестве опции по умолчанию ?

Answer 1

JavaScript делает наследование поддержки на прототипном пути. Здесь вам нужны не классы, а инкапсуляция поведения и возможность переопределения.

function Piece() { } 

Piece.prototype.color = "white"; 
Piece.prototype.getColor = function() { return this.color } 
Piece.prototype.move = function() { throw "pure function" }; 

function Pawn() { } 
Pawn.prototype = new Piece();  
Pawn.prototype.move = function() { alert("moved"); } 

и теперь:

var p = new Pawn(); p.color = "black"; 

> p instanceof Piece 

правда

p instanceof Pawn 

правда

p.getColor() 

"черный"

p.move() 

начеку ...

Это основной подход, и есть много библиотек там, которые превращают это в чем-то знакомое для ребят, желающих классы - так сказать.

Например, с JayData вы можете написать предыдущие более герметизированным способ (с бонусом автоматического вызова конструктора вверх по цепочке:

var Piece = $data.Base.extend("Piece", { 
    move: function() { throw "pure class" } 
}); 

var Pawn = Piece.extend("Pawn", { 
    move: function() { ... } 
}); 

var p = new Pawn(); 

Answer 2

Потому что Javascript не является class-based object-oriented language, а скорее prototypal. Это просто дизайнерское решение.

Кроме того, Javascript никогда не был «предназначен» для всех вещей, которые мы делаем с ним сегодня (от Node.js до ASM.js). Тот факт, что он по-прежнему имеет значение, является завещанием Брендан Эйх и Ко. Поэтому вы можете задаться вопросом, почему X или Y никогда не были реализованы в JS, но факт в том, что мы используем JS для вещей, которые 20 лет назад были бы непредсказуемыми.

Answer 3

Многие хорошие книги на различных традиционных языках OO (включая Java, C# и C++), в частности, советуют не использовать «наследование реализации», где это возможно. Пример: Эффективная Java от Джошуа Блоха.

Странный факт заключается в том, что хотя наследование реализации, похоже, придает правильную «форму» вашему коду, это не помогает решить проблему; чаще это вызывает проблемы в долгосрочной перспективе.

Эти авторы, как правило, дают свое благословение вместо «наследования интерфейсов», но на языке утиного типа, таком как JavaScript, нет необходимости явно объявлять такое наследование.

И в JS вы можете «повторно использовать» одну и ту же функцию, просто назначив ее как свойство для нескольких объектов. Какой бы вкус наследования вам ни понадобился, вы можете вызывать это из ничего.

Answer 4

В JavaScript нет даже классов класса ООП, вы просто можете имитировать нечто подобное.

В вашем примере, вы можете получить наследство, делая

var Pawn = function(teamColor, pos) { 
    Piece.call(this, teamColor, pos); 
} 

Однако, как правило, должны приложить методы к функции прототипа, а не к любому новому созданному объекту. В этом случае, вы можете моделировать наследование пути создания цепи прототипов, например, как это делает CoffeeScript:

var a, b, _ref, 
    __hasProp = {}.hasOwnProperty, 
    __extends = function(child, parent) { for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; } function ctor() { this.constructor = child; } ctor.prototype = parent.prototype; child.prototype = new ctor(); child.__super__ = parent.prototype; return child; }; 

a = (function() { 
    function a() {} 

    return a; 

})(); 

b = (function(_super) { 
    __extends(b, _super); 

    function b() { 
    _ref = b.__super__.constructor.apply(this, arguments); 
    return _ref; 
    } 

    return b; 

})(a); 

Answer 5

Следующий блок кода будет «расширить» один прототип JavaScript из другой, и убедитесь, что оператор «InstanceOf» работает правильно для базовых и производных классов.

из того, что я могу сказать, установив прототип TestB на новую Testa позволяет логической consistancy оператора «InstanceOf».

Передача этого TestA дает новый экземпляр всем желаемым свойствам и методам.

Выполнение этого способа - это своего рода баланс между стилистическими желаниями и прагматическими. Это будет работать в большинстве браузеров, даже Internet Explorer, если вы будете вынуждены его поддерживать. Это также помогает, поскольку методы, содержащиеся в одном блоке, «чувствуют» много, как ваш традиционный синтаксис OO.

Кроме того, основная причина, по которой JavaScript не поддерживает традиционный стиль OO, объясняется его основополагающей философией. Основополагающая философия - это свобода. Эта свобода предназначена для того, чтобы позволить разработчикам создавать собственные стили в соответствии с потребностями проекта.