JavaScript Inheritance Best Practices

Many sources document two major techniques and many minor variations to implement inheritance in JavaScript: constructors and prototypes. But constructors and prototypes are not exclusive, in fact they are inclusive and should always be used together. If you just use constructors or you just use prototypes, then you only did half of the job...

The best practices for JavaScript inheritance are:

1. Move all of your methods out of the constructors and into the prototypes.
2. Always define all of your properties in the prototype, it helps to document the new "type."
3. Always use Object.create to link a new object to the "super-type" prototype, never build an instance of the "super-type" as the new prototype object. And always recreate the constructor property in the prototype.
4. And always chain the constructor calls to the "super-type" constructor, even if they do not take any arguments and may not even do anything.

To explain them we are going to start from the beginning:

Marrying Angular GUIs and Spring Web Services

Using Angular for your application GUI with Spring Web Services behind it combines the power of Spring and dependency injection with the single-page GUI framework of Angular. Using Angular with AJAX eliminates the page routing that a Spring MVC application forces on the application, but we can still use the Spring MVC application framework to provide a REST web service for that AJAX application.

The obstacle during development is the "same-origin" policy that restricts the Angular application to communicate with the same server it was loaded from. The solution is to put the projects side-by-side in the Spring Tool Suite (STS) and run them side-by-side in the Pivotal TC server.

Proxy: The Man in the Middle

Proxies occur naturally all over the place, for example in politics we elect someone to represent us in government because we cannot all be there. So it naturally follows that we would use the same pattern in software design. Here is an easy example: we have a class that implements an interface and submits a credit-card charge to a service provider. The interface provides what the client code expects, and the class adapts that to the provider. So this is actually an adapter pattern:

But what happens if the provider is offline? Well, we could change the adapter class so that it detects the problem and stores the transaction to process later. But that makes the class responsible for both interfacing to the service provider and caching transactions when the provider is not available. We would really like to stick as close as possible to Robert Martin's "Single Responsibility Principle" and separate responsibilities to easily manage them (Martin).

Who's Mock is it Anyways?

How to mock a third-party module for unit tests is a coding problem I often see pop up in design pattern boot-camps. In one boot-camp I teach the design involves using a third-party scale to weigh parcels.

This particular third-party scale returns a random weight each time it is used, so it cannot be used to test the validity of any calculations that depend on weight. So here is the thing: are we testing the adapter, or are we testing the client that uses the adapter? Because what we do in each of those situations is different.

Apache Derby Won't Start Anymore!

We use Apache Derby a lot as a stand-alone SQL database for software development courses. After Java 7 came out we started to have problems with Derby on computers in the classroom. Sometimes it would run, sometimes it wouldn't.

Sometimes it would run a computer with Java 7 or even 8, other times it would not. The common denominator was Java 7+, and while early releases of Java 7 do not exhibit any issues it is just easier to lump everything from Java 7 onward together. So when would it run? If the computer also had Java 6, and JAVA_HOME was set to that JRE, and if Derby was launched with a script that checked JAVA_HOME.

The real problem of course is that Derby is a Java application and the later JREs are locked down more and throw a security fit when Derby wants to bind to a TCP/IP port.

So the simple solution is to just write a script to wrap Derby and use Java 6. But, you may not have Java 6. In fact, you should not have it, there are simply too many security issues for it to be on your computer. Oh bother, what to do now?

Which Java am I using?

What happens if you have multiple JREs on a computer? Which one is is used when you run java at the command line?

You might tell me to look at the JAVA_HOME environment variable, but the only Java launcher I know of that actually checks it is the one that gets installed on OS X. There is no joy with JAVA_HOME for Windows or Linux.

Sometimes I need to know which JRE is being used. Maybe an application has a specific requirement, or I want to change the configuration perhaps to edit the java.policy and allow the Apache Derby database to bind to a TCP/IP port if I have Java 7 or higher.

The Quick Answers

On all platforms you can control which java executable is picked by putting the bin folder of a JRE earlier in the environment PATH variable and bypassing the launcher. Many folks like to set the environment variable JAVA_HOME to point to the the JRE (or JDK) folder, and then use that variable in the path: $JAVA_HOME/bin on OS X and Linux, %JAVA_HOME%\bin on Windows. When you set the variable then changes are reflected in the PATH (if you open a new terminal or command window) and it is always available in any scripts that use it.

If you need a particular JRE for an application, then wrap the application in a startup script that hardwires which JRE will be used to launch it. Other applications that need the default JRE will not be affected.

So the fast answer is that running the java command usually launches java in the last JRE that was installed, unless someone changed that configuration. But what if you don't know what was installed last? Generally you can look at the version and update numbers, but sometimes there may be multiple JREs of the same version.

The fastest way to solve that problem is to execute java -verbose -version. It will not announce the path for you, but it does log to the console all of the jar files loaded. The path to those jar files tells you where the JRE is!

So the rest of this post is an exploration of how the Java launcher actually goes about selecting the JRE that gets used. It is fun, it can be useful to understand what is going to happen when you type java, and it is mostly here so I can refer back to it. It turns out that the decision making process is not the same on every platform. Shocker.

The Adapter Pattern: Plug and Play

I have a soft spot for the adapter pattern when I am teaching any of the twenty three Gang of Four design patterns. I guess I really like it because it is so simple to grasp. And it demonstrates designing to the abstraction, a feature that almost seventy percent of these design patterns share.

Almost every mobile phone and table sold today uses a USB cable to power and charge it. I can find a variety of adapters to connect that USB cable to different styles power outlets in the United States or other countries, or to connect it to a 12-volt automotive system. Of course some of these adapters work better than others, so getting one from a questionable source may put my device at risk. But being able to substitute any adapter that provides me with a USB port is what the adapter pattern is all about.