It's made up, but there are several patterns which are frequently abused by Java programmers. Some argue it's to clean up code or an attempt to be more dynamic or OO. I find both to be terrible. The first is the factory method pattern. This pattern isn't terrible when used lightly and only where it makes sense, but it seems like of all the patterns this one is the one people buy into most heavily and end up with insane meta-creation objects when in reality they probably should just simplify their objects and create them themselves. Frequently found chained together. For example, you decided that you wanted a massive object to define the state of your app. GOOD CALL! Now you need a factory to initialize that app rather than a basic static method. GOOD CALL! So you create AppFactoryclass which knows exactly how to build it the way you want. But then you run into a problem. How does the AppFactory know how to create another ultra complex object that you're using within the App to perform protocol transport? You create AppProtocolFactory but really this only works for the base Protocol. You could clean up the 1 function call and allow it to be used in places you haven't made yet if you split out base functionality into AppProtocolFactory and left specific details of implementation in AppFactoryProtocolFactory to specify that this is a protocol factory specifically for the app factory.

See the factory pattern growing heads like a hydra in the hands of an overzealous programmer? None of the object I'm talking about need to be abstracted, and they're only created one time. It's hypothetical effort in most cases and is a huge circle jerk for people who like factories.

So the joke was that this "chained" factory was taken to an extreme. In the above we have AppFactoryProtocolFactory. So FactoryFactoryFactory is a factory that creates factory factories. It's a nonsensical case. It's also worth noting that you can create factory patterns in pretty much any OO language, but it's popular in some more than others.

Now aspects. I hate aspects. Aspects are a fucking nightmare. They're made for people who hate boilerplate so much that they ignore ideas like "create an object with static methods" and instead say "every time somebody uses a get we want to log it". Aspects typically tie into Java annotations and allow the program to be "woven" together at compile time. I'd contend that aspects make a lot of bad code in the hands of a good programmer manageable but still broken, but any code in the hands of a bad programmer, spaghetti.

The joke was I was having an aspect build aspect factories to wire all the code I needed together. This would be a spaghetti mess. Nobody would do this. I also joked that I had created skynet. Although fortunately, if this is how Skynet was coded, a rogue null could take it down and it would have to recompile for a week to fix it.