Professional Development 10/19 through 10/25/2015

Software Development


Cable TV, Contracts, and the Interface Segregation Principle

The Cable Empire: Misuses of Contracts

When purchasing cable television at my address, there are 3 providers available for me to choose from; Charter, DirecTV, and Dish. Each of these options give me several “package” choices, which each contain different channel line-up. Charter has 3 package options; DirecTV has 6 English and 4 Spanish package options; and, Dish has 4 package options along with smaller add-on packages. In order to get all the channels that I would like, I need to choose a package that contains all those channels from a provider that I prefer to do business with.

For the purposes of the argument I am building up to, my favorite channels include NBC, PBS, Cartoon Network, Comedy Central, Food Network, SEC Network, and, since I like movies too, Starz. I cannot live without these channels, therefore I have to choose a package that has all the included channels, or I fall into a deep depression and become useless to the rest of the world, slowly dying from lack of hygiene and sustenance.

Choosing Charter as my television provider, I find that NBC, PBS, Comedy Central, Food Network, and SEC network are all in the lowest priced package. That is pretty good, but the lowest priced package does not include two of my must haves, Cartoon Network and Starz. The 2nd tier package contains Cartoon Network, but not Starz. This means that, in order to get all the channels that I need to live, I am forced to get the highest priced package which includes every last channel that Charter has to offer. Most of these I will never even flip past early in the morning, searching for something good on at the time there is nothing good.

If I choose DirecTV instead, the situation is even worse. Since I only speak English, the Spanish packages are out of the question. I find that the lowest priced package contains Cartoon Network, Comedy Central, and Food Network. The second tier adds none of the other channels I need. The third tier adds only the SEC Network. NBC comes with the fourth. Starz is available in the highest priced package, but none of the packages provide PBS. If I had to choose DirecTV, I would die of scurvy, unable to travel to the store to buy limes.

Finally, choosing Dish, NBC, Cartoon Network, Comedy Central, and Food Network are available in the lowest priced package. The SEC network becomes available in the second tier package, Starz is available in an add-on package, and, just like DirecTV, PBS is not available. Muerte.

I find myself unfortunately excluded from two of the television providers that service my home address, and more unfortunately priced into the most expensive option of the third based on the channels I want and need.

The Interface Segregation Principle

Aside from the fact that, since government regulation does not require cable companies to offer channels on an “a la carte” basis, cable companies strategically allocate the channels into their service tiers in order to force consumers into the highest priced tier. This demonstrates a real life violation of the interface segregation principle. “The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.” – Wikipedia. Until recent years, consumers have been force fed television channels that they don’t want, need, or even use. While this makes good business sense. Code should never conduct business this way.

Interfaces are contracts. They are contracts that classes sign so that expected behavior can be defined for the consumer of the class. If a class implements the ICablePackage, then I know that I should have access to a specific set of methods (channels) as defined in the interface. This means that I can change the concrete class to any other class that implements ICablePackage that I want to, whether it is a CharterCablePackage, a DirecTvCablePackage, or a DishCablePackage.

There are, however,  problems with the CablePackage design implied above. First, if I want access to all the methods that I can possibly use on a PremiumCablePackage class to be available to the consumer of the PremiumCablePackage’s API, is it sufficient to expose everything in the ICablePackage interface? It would certainly work, but if the consumers of my ICablePackage are only paying for basic cable package and my BasicCablePackage implements all the things needed to properly implement the ICablePackage, and therefore the same things availible to the PremiumCablePackage, then some of the more enterprising clients of my BasicCablePackage class could be getting access to stuff they aren’t paying for, or I would be catching NotImplementedExceptions all over the place. In this case there should probably be more than one interface, each providing different, additive, functionality. The BasicCablePackage might only implement a IBasicCablePackage interface while the PremiumCablePackage class might implement IBasicCablePackage, IMiddleTierCablePackage, and IPremiumCablePackage. Each interface would add exposure to the channels that are added by the next service tier.

With the first problem solved, there is a second problem. What if the consumer of my class only wants to use NBC(), PBS(), and Starz(). Aside from overwhelming greed and complete disregard for the happiness of my clients, is it appropriate to make them pay for methods they don’t need and won’t use? This just unnecessarily confuses the developer who is writing the code that consumes the interfaces. Each interface should expose just what it needs in order to give proper functionality to each of its consumers. This insures that the consumer doesn’t have more access than it needs and also doesn’t have to deal with the extras it doesn’t want.

This necessarily adds complexity to the code base, but the reward is concise, testable code. Ensuring adherence to the ISP helps define what methods are available to each consumer class and reduces the number of execution paths that need to be tested.

Professional Development from 10/12 through 10/18/2015

Software Development



Personal Managment

Professional Development 10/5 through 10/11/2015

Software Development



Computer Science

Interpersonal skills

Professional Development – 9/21 through 10/4/2015

Software Development

Business Practices