Modular Design Patterns and Inheritance


Last week we talked about JavaScript inheritance and if you recall we had talked about modular design patterns in JavaScript just a month ago. I would also like to talk about how to connect both modules and class inheritance. We've already discussed that modules are classes. So if we can link classes by inheritance relationship, the logical half of our brain suggests that we should be able to link modules as well. The logic prevails - we can.

AMD and inheritance


I'll be using the classes we defined in the inheritance article, Mammal and Dog, and create modules from them. Let's start with our super class:
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
(function () {
    'use strict';
  
 define(function() {
   
  function Mammal() {
    this.age = 0;
    console.info("Mammal was born");
  }
    
  Mammal.prototype.grow = function() {
      this.age += 1;
      console.log("Mammal grows");
  };
 
  return Mammal;
 });
}());
Let's use it in our entry point JavaScript file. Just to remind you this file is declared in data-main attribute.
?
1
2
3
4
5
6
7
8
9
(function () {
    'use strict';
 require(["Mammal"],
     function(Mammal) {
         var m = new Mammal();
         m.grow();
     }
   );
})();
Now it's time to create our Dog module. Since it needs Mammal for the inheritance, we'll list it in our dependency list. The implementation remains the same.
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
(function () {
    'use strict';
 define(["Mammal"],
     function(Mammal) {
         function Dog(name) {
     this.name = name;
     Mammal.call(this);
   }
 
   Dog.prototype.grow=function(){
     this._super.grow.call(this);
     this.age =+ 1;
     console.log('Dog grows');
   }
     
   Dog.prototype = Object.create(Mammal.prototype);
   Dog.prototype.constructor = Dog;
   Dog.prototype._super = Mammal.prototype;
      
   return Dog;
     });
})();
And of course update our main file to see if it works:
?
1
2
3
4
5
6
7
8
9
10
(function () {
    'use strict';
 require(["Mammal", "Dog"],
     function(Mammal, Dog) {
         var m = new Mammal(), d = new Dog('Rocky');
   m.grow();
   d.grow();
     }
   );
})();

CommonJS and inheritance


As you recall modules should be defined using the CommonJS syntax if you want to use them in Node.js.
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
(function () {
    'use strict';
  
 function Mammal() {
   this.age = 0;
   console.info("Mammal was born");
 }
   
 Mammal.prototype.grow = function() {
     this.age += 1;
     console.log("Mammal grows");
 };
 
 module.exports = Mammal;
}());
As you can see we removed define method call and replaced return with module.exports.
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
(function () {
    'use strict';
  
 var Mammal = require('Mammal');
 
    function Dog(name) {
   this.name = name;
   Mammal.call(this);
 }
 
 Dog.prototype.grow=function(){
   this._super.grow.call(this);
   this.age =+ 1;
   console.log('Dog grows');
 }
   
 Dog.prototype = Object.create(Mammal.prototype);
 Dog.prototype.constructor = Dog;
 Dog.prototype._super = Mammal.prototype;
 
 module.exports = Dog;
})();
Here instead of listing the dependencies, we just require the Mammal class in our Dog definition.

Comments

Post a Comment

Popular posts from this blog

CAP Theorem and blockchain

Image
In theoretical computer science, the CAP theorem states that it is impossible for a distributed data store (such as a blockchain network) to simultaneously provide more than two out of the three guarantees: Consistency, Availability & Partition tolerance. CAP Theorem – the parts C: Consistency – At any given time, all nodes in the network have exactly the same (most recent) value. A: Availability – Every request to the network receives a response, though without any guarantee that returned data is the most recent. P: Partition tolerance – The network continues to operate, even if an arbitrary number of nodes are failing. Due to the nature of distributed data stores (such as blockchain), Partition tolerance is a given fact; there will always be failing/unreachable nodes in the network (not least because of the unstable nature of the internet). CAP Theorem states that one has to choose between C (Consistency) or A (Availability) when in the presence of P (Partition): Av...
Read more

Deep dive into Elliptic Curve Signatures

Image
To popular demand, I have decided to try and explain how the ECDSA algorithm works. We've discussed a bit eliptic curve signatures before and a little bit more afte that , but it seems it's never enough. Admitedly, I've been struggling a bit to understand it properly and while I found a lot of documentation about it, I haven't really found any ECDSA for newbies anywhere. So I thought it would be good to explain in simple terms how it works so others can understand it better. Let's give it a stab ECDSA stands for Elliptic Curve Digital Signature Algorithm and it's used to create a digital signature of data (a file for example) in order to allow you to verify its authenticity, without compromising its security. Think of it like a real signature, you can recognize someone's signature, but you can't forge it without others knowing. The ECDSA algorithm is basically all about mathematics. But these maths are fairly complicated, so while I'l...
Read more

Proof of solvency and collateral

Image
Centralized exchanges (CEXs) are a critical part of the cryptocurrency ecosystem, but they also pose a significant risk to users. In the event of a hack or bankruptcy, users can lose all of their funds. One way to mitigate this risk is to require CEXs to provide regular proof of solvency. Proof of solvency is a way for CEXs to demonstrate that they have enough assets to cover all of their user deposits. There are a number of different ways to implement proof of solvency. One simple approach is for CEXs to simply publish a list of all of their addresses and the corresponding balances. This approach is transparent and easy to verify, but it does not provide any privacy for users. Zero-knowledge Proofs A more secure approach would be for CEXes to use zero-knowledge proofs (ZKPs) to prove their solvency. ZKPs allow exchanges to prove that they have a certain amount of assets without revealing any other information about their balance sheets. This would make it much more difficult fo...
Read more