javascriptobjectdefineproperty

how to use javascript Object.defineProperty


I looked around for how to use the Object.defineProperty method, but couldn't find anything decent.

Someone gave me this snippet of code:

Object.defineProperty(player, "health", {
    get: function () {
        return 10 + ( player.level * 15 );
    }
})

But I don't understand it. Mainly, the get is what I can't get (pun intended). How does it work?


Solution

  • Since you asked a similar question, let's take it to step by step. It's a bit longer, but it may save you much more time than I have spent on writing this:

    Property is an OOP feature designed for clean separation of client code. For example, in some e-shop you might have objects like this:

    function Product(name,price) {
      this.name = name;
      this.price = price;
      this.discount = 0;
    }
    
    var sneakers = new Product("Sneakers",20); // {name:"Sneakers",price:20,discount:0}
    var tshirt = new Product("T-shirt",10);  // {name:"T-shirt",price:10,discount:0}
    

    Then in your client code (the e-shop), you can add discounts to your products:

    function badProduct(obj) { obj.discount+= 20; ... }
    function generalDiscount(obj) { obj.discount+= 10; ... }
    function distributorDiscount(obj) { obj.discount+= 15; ... }
    

    Later, the e-shop owner might realize that the discount can't be greater than say 80%. Now you need to find EVERY occurrence of the discount modification in the client code and add a line

    if(obj.discount>80) obj.discount = 80;
    

    Then the e-shop owner may further change his strategy, like "if the customer is reseller, the maximal discount can be 90%". And you need to do the change on multiple places again plus you need to remember to alter these lines anytime the strategy is changed. This is a bad design. That's why encapsulation is the basic principle of OOP. If the constructor was like this:

    function Product(name,price) {
      var _name=name, _price=price, _discount=0;
      this.getName = function() { return _name; }
      this.setName = function(value) { _name = value; }
      this.getPrice = function() { return _price; }
      this.setPrice = function(value) { _price = value; }
      this.getDiscount = function() { return _discount; }
      this.setDiscount = function(value) { _discount = value; } 
    }
    

    Then you can just alter the getDiscount (accessor) and setDiscount (mutator) methods. The problem is that most of the members behave like common variables, just the discount needs special care here. But good design requires encapsulation of every data member to keep the code extensible. So you need to add lots of code that does nothing. This is also a bad design, a boilerplate antipattern. Sometimes you can't just refactor the fields to methods later (the eshop code may grow large or some third-party code may depend on the old version), so the boilerplate is lesser evil here. But still, it is evil. That's why properties were introduced into many languages. You could keep the original code, just transform the discount member into a property with get and set blocks:

    function Product(name,price) {
      this.name = name;
      this.price = price;
    //this.discount = 0; // <- remove this line and refactor with the code below
      var _discount; // private member
      Object.defineProperty(this,"discount",{
        get: function() { return _discount; },
        set: function(value) { _discount = value; if(_discount>80) _discount = 80; }
      });
    }
    
    // the client code
    var sneakers = new Product("Sneakers",20);
    sneakers.discount = 50; // 50, setter is called
    sneakers.discount+= 20; // 70, setter is called
    sneakers.discount+= 20; // 80, not 90!
    alert(sneakers.discount); // getter is called
    

    Note the last but one line: the responsibility for correct discount value was moved from the client code (e-shop definition) to the product definition. The product is responsible for keeping its data members consistent. Good design is (roughly said) if the code works the same way as our thoughts.

    Alternatively, ES6 allows class syntax, which is a "special function" allowing the same functionality to code as:

    class Product {
      constructor(name, price) {
        this.name = name;
        this.price = price;
      }
      #discount = 0; // # = private member in classes
      get discount() { return this.#discount; }
      set discount(v) { this.#discount = v; if(this.#discount>80) this.#discount = 80; }
    }
    

    So much about properties. But javascript is different from pure Object-oriented languages like C# and codes the features differently:

    In C#, transforming fields into properties is a breaking change, so public fields should be coded as Auto-Implemented Properties if your code might be used in the separately compiled client.

    In Javascript, the standard properties (data member with getter and setter described above) are defined by accessor descriptor (in the link you have in your question). Exclusively, you can use data descriptor (so you can't use i.e. value and set on the same property):

    Both descriptors can have these members:

    * unless in strict mode - in that case JS stops execution with TypeError unless it is caught in try-catch block

    To read these settings, use Object.getOwnPropertyDescriptor().

    Learn by example:

    var o = {};
    Object.defineProperty(o,"test",{
      value: "a",
      configurable: true
    });
    console.log(Object.getOwnPropertyDescriptor(o,"test")); // check the settings    
    
    for(var i in o) console.log(o[i]); // nothing, o.test is not enumerable
    console.log(o.test); // "a"
    o.test = "b"; // o.test is still "a", (is not writable, no error)
    delete(o.test); // bye bye, o.test (was configurable)
    o.test = "b"; // o.test is "b"
    for(var i in o) console.log(o[i]); // "b", default fields are enumerable
    

    If you don't wish to allow the client code such cheats, you can restrict the object by three levels of confinement:

    You don't need to bother with this if you write just a few lines fun. But if you want to code a game (as you mentioned in the linked question), you should care about good design. Try to google something about antipatterns and code smell. It will help you to avoid situations like "Oh, I need to completely rewrite my code again!", it can save you months of despair if you want to code a lot. Good luck.