One place for hosting & domains

      Pattern

      Module Design Pattern in JavaScript


      While this tutorial has content that we believe is of great benefit to our community, we have not yet tested or
      edited it to ensure you have an error-free learning experience. It’s on our list, and we’re working on it!
      You can help us out by using the “report an issue” button at the bottom of the tutorial.


      Part of the Series:
      JavaScript Design Patterns

      Every developer strives to write maintainable, readable, and reusable code. Code structuring becomes more important as applications become larger. Design patterns prove crucial to solving this challenge – providing an organization structure for common issues in a particular circumstance.

      The design pattern below is only one of many useful patterns that can help you level up as a JavaScript developer. For the full set, see JavaScript Design Patterns.

      JavaScript modules are the most prevalently used design patterns for keeping particular pieces of code independent of other components. This provides loose coupling to support well-structured code.

      For those that are familiar with object-oriented languages, modules are JavaScript “classes”. One of the many advantages of classes is encapsulation – protecting states and behaviors from being accessed from other classes. The module pattern allows for public and private (plus the lesser-know protected and privileged) access levels.

      Modules should be Immediately-Invoked-Function-Expressions (IIFE) to allow for private scopes – that is, a closure that protect variables and methods (however, it will return an object instead of a function). This is what it looks like:

      (function() {
      
          // declare private variables and/or functions
      
          return {
              // declare public variables and/or functions
          }
      
      })();
      

      Here we instantiate the private variables and/or functions before returning our object that we want to return. Code outside of our closure is unable to access these private variables since it is not in the same scope. Let’s take a more concrete implementation:

      var HTMLChanger = (function() {
          var contents="contents"
      
          var changeHTML = function() {
          var element = document.getElementById('attribute-to-change');
          element.innerHTML = contents;
          }
      
          return {
          callChangeHTML: function() {
              changeHTML();
              console.log(contents);
          }
          };
      
      })();
      
      HTMLChanger.callChangeHTML();       // Outputs: 'contents'
      console.log(HTMLChanger.contents);  // undefined
      

      Notice that callChangeHTML binds to the returned object and can be referenced within the HTMLChanger namespace. However, when outside the module, contents are unable to be referenced.

      Revealing Module Pattern

      A variation of the module pattern is called the Revealing Module Pattern. The purpose is to maintain encapsulation and reveal certain variables and methods returned in an object literal. The direct implementation looks like this:

      var Exposer = (function() {
          var privateVariable = 10;
      
          var privateMethod = function() {
          console.log('Inside a private method!');
          privateVariable++;
          }
      
          var methodToExpose = function() {
          console.log('This is a method I want to expose!');
          }
      
          var otherMethodIWantToExpose = function() {
          privateMethod();
          }
      
          return {
              first: methodToExpose,
              second: otherMethodIWantToExpose
          };
      })();
      
      Exposer.first();        // Output: This is a method I want to expose!
      Exposer.second();       // Output: Inside a private method!
      Exposer.methodToExpose; // undefined
      

      Although this looks much cleaner, an obvious disadvantage is unable to reference the private methods. This can pose unit testing challenges. Similarly, the public behaviors are non-overridable.



      Source link

      Prototype Design Pattern in JavaScript



      Part of the Series:
      JavaScript Design Patterns

      Every developer strives to write maintainable, readable, and reusable code. Code structuring becomes more important as applications become larger. Design patterns prove crucial to solving this challenge – providing an organization structure for common issues in a particular circumstance.

      The design pattern below is only one of many useful patterns that can help you level up as a JavaScript developer. For the full set, see JavaScript Design Patterns.

      Any JavaScript developer has either seen the keyword prototype, confused by the prototypical inheritance, or implemented prototypes in their code. The Prototype design pattern relies on the JavaScript prototypical inheritance. The prototype model is used mainly for creating objects in performance-intensive situations.

      The objects created are clones (shallow clones) of the original object that are passed around. One use case of the prototype pattern is performing an extensive database operation to create an object used for other parts of the application. If another process needs to use this object, instead of having to perform this substantial database operation, it would be advantageous to clone the previously created object.

      Prototype Design PatternPrototype Design Pattern on Wikipedia

      This UML describes how a prototype interface is used to clone concrete implementations.

      To clone an object, a constructor must exist to instantiate the first object. Next, by using the keyword prototype variables and methods bind to the object’s structure. Let’s look at a basic example:

      var TeslaModelS = function() {
          this.numWheels    = 4;
          this.manufacturer="Tesla";
          this.make="Model S";
      }
      
      TeslaModelS.prototype.go = function() {
          // Rotate wheels
      }
      
      TeslaModelS.prototype.stop = function() {
          // Apply brake pads
      }
      

      The constructor allows the creation of a single TeslaModelS object. When a creating new TeslaModelS object, it will retain the states initialized in the constructor. Additionally, maintaining the function go and stop is easy since we declared them with prototype. A synonymous way to extend functions on the prototype as described below:

      var TeslaModelS = function() {
          this.numWheels    = 4;
          this.manufacturer="Tesla";
          this.make="Model S";
      }
      
      TeslaModelS.prototype = {
          go: function() {
          // Rotate wheels
          },
          stop: function() {
          // Apply brake pads
          }
      }
      

      Revealing Prototype Pattern

      Similar to Module pattern, the Prototype pattern also has a revealing variation. The Revealing Prototype Pattern provides encapsulation with public and private members since it returns an object literal.

      Since we are returning an object, we will prefix the prototype object with a function. By extending our example above, we can choose what we want to expose in the current prototype to preserve their access levels:

      var TeslaModelS = function() {
          this.numWheels    = 4;
          this.manufacturer="Tesla";
          this.make="Model S";
      }
      
      TeslaModelS.prototype = function() {
      
          var go = function() {
          // Rotate wheels
          };
      
          var stop = function() {
          // Apply brake pads
          };
      
          return {
          pressBrakePedal: stop,
          pressGasPedal: go
          }
      
      }();
      

      Note how the functions stop and go will be shielded from the returning object due to being outside of returned object’s scope. Since JavaScript natively supports prototypical inheritance, there is no need to rewrite underlying features.



      Source link

      Observer Design Pattern in JavaScript



      Part of the Series:
      JavaScript Design Patterns

      Every developer strives to write maintainable, readable, and reusable code. Code structuring becomes more important as applications become larger. Design patterns prove crucial to solving this challenge – providing an organization structure for common issues in a particular circumstance.

      The design pattern below is only one of many useful patterns that can help you level up as a JavaScript developer. For the full set, see JavaScript Design Patterns.

      There are many times when one part of the application changes, other parts needs to be updated. In AngularJS, if the $scope object updates, an event can be triggered to notify another component. The observer pattern incorporates just that – if an object is modified it broadcasts to dependent objects that a change has occurred.

      Another prime example is the model-view-controller (MVC) architecture; The view updates when the model changes. One benefit is decoupling the view from the model to reduce dependencies.

      Observer Design PatternObserver Design Pattern on Wikipedia

      As shown in the UML diagram, the necessary objects are the subject, observer, and concrete objects. The subject contains references to the concrete observers to notify for any changes. The Observer object is an abstract class that allows for the concrete observers to implements the notify method.

      Let’s take a look at an AngularJS example that encompasses the observer pattern through event management.

      // Controller 1
      $scope.$on('nameChanged', function(event, args) {
          $scope.name = args.name;
      });
      
      ...
      
      // Controller 2
      $scope.userNameChanged = function(name) {
          $scope.$emit('nameChanged', {name: name});
      };
      

      With the observer pattern, it is important to distinguish the independent object or the subject.

      It is important to note that although the observer pattern does offer many advantages, one of the disadvantages is a significant drop in performance as the number of observers increased. One of the most notorious observers is watchers. In AngularJS, we can watch variables, functions, and objects. The $$digest cycle runs and notifies each of the watchers with the new values whenever a scope object is modified.

      We can create our own Subjects and Observers in JavaScript. Let’s see how this is implemented:

      var Subject = function() {
          this.observers = [];
      
          return {
          subscribeObserver: function(observer) {
              this.observers.push(observer);
          },
          unsubscribeObserver: function(observer) {
              var index = this.observers.indexOf(observer);
              if(index > -1) {
              this.observers.splice(index, 1);
              }
          },
          notifyObserver: function(observer) {
              var index = this.observers.indexOf(observer);
              if(index > -1) {
              this.observers[index].notify(index);
              }
          },
          notifyAllObservers: function() {
              for(var i = 0; i < this.observers.length; i++){
              this.observers[i].notify(i);
              };
          }
          };
      };
      
      var Observer = function() {
          return {
          notify: function(index) {
              console.log("Observer " + index + " is notified!");
          }
          }
      }
      
      var subject = new Subject();
      
      var observer1 = new Observer();
      var observer2 = new Observer();
      var observer3 = new Observer();
      var observer4 = new Observer();
      
      subject.subscribeObserver(observer1);
      subject.subscribeObserver(observer2);
      subject.subscribeObserver(observer3);
      subject.subscribeObserver(observer4);
      
      subject.notifyObserver(observer2); // Observer 2 is notified!
      
      subject.notifyAllObservers();
      // Observer 1 is notified!
      // Observer 2 is notified!
      // Observer 3 is notified!
      // Observer 4 is notified!
      

      Publish/Subscribe

      The Publish/Subscribe pattern, however, uses a topic/event channel that sits between the objects wishing to receive notifications (subscribers) and the object firing the event (the publisher). This event system allows code to define application-specific events that can pass custom arguments containing values needed by the subscriber. The idea here is to avoid dependencies between the subscriber and publisher.

      This differs from the Observer pattern since any subscriber implementing an appropriate event handler to register for and receive topic notifications broadcast by the publisher.

      Many developers choose to aggregate the publish/subscribe design pattern with the observer though there is a distinction. Subscribers in the publish/subscribe pattern are notified through some messaging medium, but observers are notified by implementing a handler similar to the subject.

      In AngularJS, a subscriber ‘subscribes’ to an event using $on(‘event’, callback), and a publisher ‘publishes’ an event using $emit(‘event’, args) or $broadcast(‘event’, args).



      Source link