Friday, November 4, 2011

A rant about Front End Developers not knowing Modular Programming

I find myself these days needing to teach many Front End Developers about basic software engineering principles that they didn't even know they didn't know. Here is a rant based on a post of mine to an internal support forum at a client site. I keep finding FEDs that think that any piece of DOM, bit of JavaScript, or chunk of CSS that they can see via Firebug is fair game to fiddle with, and they ask in all innocence why that is a bad thing! ...rant...rant...

Why does my App break when I upgrade to the new version of the Framework?

Question: Help, the following code broke when we upgraded to the new version of the [gui] framework.

Answer: In your code I see there are quite a few references to non-public framework component attributes and methods...

There are general software engineering principles of "encapsulation" and "information hiding" which come from the Modular Programming era in the mid-1970s (just before Object Oriented expanded upon it).  To combat "brittleness" of a system, Components hide their (private) implementation details inside a (public) interface so that changes in one part of a system don't break other far-flung parts of that system (aka "loose coupling").  The warranty provided by the component is that as long as you use it as designed, and via the stable interface, the insides are free to be changed/fixed/enhanced without affecting you.

So, a component (where "widget" is just another word for component) is not just a collection of functionality like the collection of bits and wires below...

 ...but rather a collection of functionality that has had a stable interface published on the outside of a "black box" thus hiding the implementation inside that box, as shown below...



This warranty is voided however if you break into the box and connect to its private implementation (aka "hacking") as seen below...

 In [GUI Framework], there are two major indicators as to whether a property or method of a widget is public interface versus private implementation:
  1. If the name of the property or method starts with an underscore ("_") then it is definitely private (or at best "protected")
  2. If the property or method is documented as public in the [GUI Framework] JsDoc API Docs then it is definitely public.
SO, IN CONCLUSION, if someone advises you to have your app use non-documented or private parts of a widget, you should get them to sign a document acknowledging that they are taking responsibility for voiding your warranty...only the Interfaces are promised to be kept stable, not the Implementations!

No comments: