Object-Oriented Programming

What's "dynamic binding"?

Martin Fowler has been one of my favorite authors for a while now, I started out by reading Refactoring (though I should probably have read it a year earlier to get the most out of it), and later moved on to Patterns of Enterprise Application Architecture. Right now I'm skimming through UML Distilled, I've mostly used class and sequence diagrams in the past, so I thought I'd check out what else UML has to offer.

The Model-View-Controller design pattern provides a very useful separation between parts of an application. Unfortunately some other patterns have emerged that add confusion to what the parts of MVC really are.

The most striking example of this is the Application Controller[^appc]. A lot of web application frameworks use this pattern and often—if not always—AppController is the only type of controller available and this leads beginners to believe that this “controller” is in fact the C in MVC. (Ruby on) Rails is an example

JavaScript is an object-oriented language. It uses prototypical inheritance instead of the more common class based inheritance, but luckily it—being the flexible language it is—allows one to utilize both methods of inheritance. But why even allow for both when you usually work with class based models? Well, I can’t speak for the people responsible for making that decision, but I will give you some of my thoughts on the subject.

Now then, what is prototypical inheritance? Douglas Crockford described it so well when he tried to defend it

Object-Oriented Programming strongly emphasizes abstraction, perhaps I can go as far as to say it’s the true core of the OO paradigm.

OO tries to model reality, or rather, it tries to model our perception of reality. What amazes me most about our perception is abstraction. We look in one direction, and our brain applies its amazingly complex pattern recognition to tell “us” what it is we see. If we look towards a tree then surely we will recognize it as a tree as well. But is it really a tree? On might reasonably argument that calling it a tree

I was reading the State pattern in GoF and there was one issue they addressed that I think I have a better solution for.

A quick reminder if you don’t remember the pattern: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. The example GoF gives is a TCPConnection class that is composed of a TCPState, the TCPstate will behave differently depending on the current state of the connection (such as throwing an exception if close() is called when the state is already