Closures in Javascript

What is a closure?

A closure is when a function “remembers” its lexical scope even when the function is executed outside that lexical scope.

function makeAdder(x) {
  return function(y) {
    return x + y;
  };
}

var add5 = makeAdder(5);
var add10 = makeAdder(10);

console.log(add5(2));  // 7
console.log(add10(2)); // 12

add5 and add10 have both become closures because they share the same function body definition but store different environments and close over the x and y independently. The key mechanism at work here is the inner function is be transported out and returned.

Module pattern

A useful application of closures is the module pattern which can provide a means of encapsulation.

var foo = (function() {
  var o = { bar: "bar" };

  return {
    bar: function() {
      console.log(o.bar);
    }
  };
})();

foo.bar(); // "bar"
foo.o // "undefined" - akin to a private member

this keyword in Javascript

The following notes are a resummarization from Kyle Simpson as a note to myself

What is this? Every function, while executing, has a reference to its current execution context

What determines which object a functions this points to? What’s the default?

• Default and Implicit Binding rule

function foo() {
  console.log(this.bar);
}

var bar = "bar1";
var o2 = { bar: "bar2", foo: foo };
var o3 = { bar: "bar3", foo: foo };

//the call below is a normal call and uses default binding
//in strict mode this will be undefined
//in non strict mode it wil be the global
foo();    //"bar1"

//below we illustrate implicit binding
//we make a reference to o2 as the owner or containing object
//and use it to call the function, 'this' now points to o2's 'this' context
o2.foo(); //"bar2"
o3.foo(); //"bar3"

• Using the new keyword

function foo() {
  this.baz = "baz";
  console.log(this.bar + " " + baz);
}

var baz = "bar";

// below we will get a brand new object with a new 'this' context
// also the object inherits from foo's prototype
// if there is no return statement, 'this' will be implicitly returned
var baz = new foo();

//the above will log "undefined bar"
//this is because this.bar is set on our new this context

• Explicit Binding with a call, apply or bind(as of ES5)

function foo(a,b) {
  console.log(a + " " + b + " " + this.bar);
}

var bar = "bar1";
var obj = { bar: "bar2" };

foo(); // "bar1" due to default binding

//first argument is the owner object or 'this' context
foo.call(obj, "a", "b"); // "a b bar2" - explicitly use obj as this
foo.apply(obj, ["a", "b"]); // "a b bar2" - same except extra arguments in array
foo = foo.bind(obj, "a", "b");
foo(); // "a b bar2"  - note we have to explicitly call foo after binding

Double Dispatch

How can you code a computation that has many cases, the cross product of two families of classes? In a language like Ruby that does not support method overloading, we would need to rely on a low level pattern known as double dispatch.

The example below illustrates the dependency on the class of the object(Doctor or Dentist) and the class of the input object(Adult or Child). If we don’t use double dispatch we get a nasty case of if or switch statements

#Not using double dispatch
class Doctor
  def work_on(patient)
    if patient.is_a? Child
      #patient.do_child_work
    elsif patient.is_a? Adult
      #patient.do_adult_work
      #elseif potential maintenance explosions here
    end
  end
end

class Dentist
  def work_on(patient)
    if patient.is_a? Child
      #patient.do_child_work
    elsif patient.is_a? Adult
      #patient.do_adult_work
      #elseif potential maintenance explosions here
    end
  end
end

Using double dispatch below, we can cleanly decouple the type of work to be done and get rid of type checking

#Using double dispatch
class Doctor
  def work_on(patient)
    patient.dispatch_work(self)
  end

  def work_on_adult(patient)
    do_checkup(patient)
  end

  def work_on_child(patient)
    assure_presence_of(patient.guardian)
    ask_questions_to(patient.guardian)
    do_checkup(patient)
    give_cheap_toy_to(patient)
  end

  private
  def do_checkup(patient)
    puts "Checking all your adult aparts"
  end
end

class Dentist
  def work_on(patient)
    patient.dispatch_work(self)
  end

  def work_on_adult(patient)
    drill_as_hard_as_you_can(patient)
  end

  def work_on_child(patient)
    use_bubble_gum_toothpaste(patient)
    give_toothbrush_to(patient)
  end

  private
  def drill_as_hard_as_you_can(patient)
    puts "Drilling very hard! on #{patient}"
  end

  def use_bubble_gum_toothpaste(patient)
    puts "Heard you like bubble gum?"
  end

  def give_toothbrush_to(patient)
    puts "Here's a free toothbrush!"
  end
end

class Adult
  def dispatch_work(doctor)
    puts "dispatch_work called on an adult"
    doctor.work_on_adult(self)
  end
end

class Child
  def dispatch_work(doctor)
    puts "dispatch_work called on an child"
    doctor.work_on_child(self)
  end
end

p1 = Adult.new
c1 = Child.new

d1 = Dentist.new
d1.work_on p1
d1.work_on c1

d2 = Doctor.new
d2.work_on p1

Addendum (3/7/2024): Understanding Double Dispatch

In software development, particularly in object-oriented programming, handling complex interactions between different types of objects can be challenging. One such scenario arises when we need to perform computations that involve multiple combinations of object types. In languages like Ruby, which lack native support for method overloading, we often rely on patterns like double dispatch to address these challenges.

Understanding Double Dispatch:

Double dispatch is a design pattern that allows us to dynamically dispatch method calls based on the types of two objects involved in a computation. It involves a two-step process:

1. First Dispatch: The method call is dispatched based on the type of the first object.
2. Second Dispatch: Within the method called in the first dispatch, another method call is dispatched based on the type of the second object.

This approach effectively decouples the logic for handling different combinations of object types, leading to cleaner and more maintainable code.

Possible Alternative:

Alternatively, we could refactor the code to use duck typing and interface extraction. This approach involves defining a Patient interface with a do_work method, which both Adult and Child classes implement. The Doctor and Dentist classes then directly call the do_work method on patient objects, eliminating the need for double dispatch.

# Define an interface for patients
module Patient
  def do_work(doctor)
    raise NotImplementedError, "This method must be implemented by subclasses"
  end
end

# Define classes for Adult and Child patients implementing the Patient interface
class Adult
  include Patient

  def do_work(doctor)
    doctor.work_on_adult(self)
  end
end

class Child
  include Patient

  def do_work(doctor)
    doctor.work_on_child(self)
  end
end

# Define classes for Doctor and Dentist
class Doctor
  def work_on_adult(adult)
    puts "Checking all your adult parts"
  end

  def work_on_child(child)
    assure_presence_of(child.guardian)
    ask_questions_to(child.guardian)
    puts "Checking all your child parts"
    give_cheap_toy_to(child)
  end

  private

  def assure_presence_of(guardian)
    # Logic to assure the presence of a guardian
  end

  def ask_questions_to(guardian)
    # Logic to ask questions to the guardian
  end

  def give_cheap_toy_to(child)
    puts "Here's a free toy for you!"
  end
end

class Dentist
  def work_on_adult(adult)
    puts "Drilling very hard!"
  end

  def work_on_child(child)
    puts "Using bubble gum toothpaste"
    puts "Here's a free toothbrush for you!"
  end
end

# Usage
p1 = Adult.new
c1 = Child.new

d1 = Dentist.new
d1.work_on p1
d1.work_on c1

d2 = Doctor.new
d2.work_on p1

This refactoring promotes a more flexible and maintainable design, aligning with the Interface Segregation Principle (ISP) of the SOLID principles.

In summary, double dispatch is a powerful design pattern for handling complex interactions between objects in object-oriented systems. By leveraging double dispatch effectively, developers can write cleaner, more maintainable code that is better suited to handle the intricacies of real-world applications.

Javascript click vs touch events

If your application needs to respond to both mobile touches and desktop clicks you could write the following

function bind_button(selector, subselector) {
  $(selector).on('click', subselector, function(event) {
    handleEvent();
    return false;
  });

  if('touchstart' in window) {
    $(selector).on('touchstart', subselector, function(event) {
      handleEvent();
      return false;
    });
  }
}

Composed Method

Definition: Breaking down a method into smaller intention revealing methods

Example:

def controlActivity
  controlInitialize
  controlLoop
  controlTerminate
end

The above code is very readable and communicates at the same abstraction level. We are guiding the structure of the system subtly by the naming and chunking.

In fact we can design our system top down and leave the implementation details for later.

A pleasant side effect of intention revealing methods within this composed method is that we hide the implementation details of methods making it more extensible and easier to modify. E.g.:

# original implementation
def controlInitialize(args)
  activity_name = args[:activity_name]
end

# adding a description
def controlInitialize(args)
  activity_name = args[:activity_name]
  description = args[:description]
end

We can also actually use Composed Method bottom-up to DRY up our code. I.e controlInitialize can now be called in multiple places and changed in one place.

If the above method was an overridable method in a superclass, we now only have 1 method we need to override vs large chunks of random code in the superclass.