Controller model model antipattern

I ran into a bit of code today that's at best awkward.One thing that generally works pretty well to get flexible and customizable code is to have the parameters to you main function be an object. This gives you the possibility to have the model to get filled in statically or perhaps even creating it dynamically in a closure or whatever.This is pretty good. It provides some good separation of responsibilities and testability.But here's where it gets strange.I ran into some code today that is like this, but backwards.Here's the rough structure:

class Model { ... }class Worker {Model m;createModel(params) {m = new Model() {... all of the props ...}}doStuff() {... do stuff with model ...}}class Runner {Worker w = new Worker(params);w.doStuff();}

The problem is that the model is set up in the controller / worker and not the caller... In this case all you have is contorted code and none of the real benefit from the structure.It's like have a model-view-controller where one of the layers like the model is completely gone even though the model still really exists and you take extra effort to construct the model inside the controller even though the model should've already existed (and honestly really does) on the outside.It's like someone got the idea that this is a good pattern to use and used it -- but didn't actually do it in a way that gets the benefit that you'd want to justify the added complexity.

Previous
Previous

On call

Next
Next

A Box