How the Sausageable is made

It is a fact universally acknowledged that a program accessing a resource must be in need of an abstraction. In a lot of situations once you add one abstraction you need to add another just to deal with that. What's the point of having a Sausageable if you have to buy and butcher the Butcherable inherits Buyable yourself? Thus the SausageableFactory.

That's a pretty easy problem to spot, since the product and the result are so close to each other. It feels like work to do kill the animal all by yourself. The real problem starts when you get more abstract than reality. Let's take this interface here:

1
2
3
4
5
6
7
8
9
Name ::= <string>
DataObject ::= <boolean> | 
               <number> |
               <string> | 
               <Name> | 
               <Array<DataObject>> |
               <Map<Name,DataObject>> |
               <Array<byte>> |
               <null>

Let's say most of the work in a program happens on big lists of DataObjects, which could be any of a half dozen different types. This is fine. You can do a lot with this, you can nest them and it makes a good wire format. Then you start to see a lot of functions like this:

  print(DataObject[] obs);
  syncWithAdobeMiddleware(DataObject[] obs);
  infectYourComputerOnLoad(DataObject[] obs);

Yup, this is the PDF format. The api is more abstract than we are; we only care about PDFs. This spec can do a lot more than will ever be done with it. It's a close cousin of the millions of Java ThingDoer.java interfaces that only have one friend in the whole world, ThingDoerImpl.java. These interfaces aren't decoupled, they're just pretending to be.