• plis (unregistered)

    Abstract Frist

  • Bradley (unregistered)

    Sorry, I'm just not really seeing the problem with this one guys.

  • Virginia Nutu (google) in reply to Bradley

    "Sorry, PersonsBase.CreateInstance( typeof("I")) 'm just not really seeing the problem with ArticlesBase.CreateInstance( typeof("this one")) guys." Fixed it for you

  • isthisunique (unregistered)

    I've recently made a mess very similar to this one in the name of cleaning things up, not to offer different implementations though.

    What you see here is some meta coding but it is hard to say if it achieves anything. I think someone wants to be able to instantiate a variable classname.

    The task id there is going to cause some headaches. This one can spiral out of control as different variations on constructor parameters are presented. There's also the question of why not null instead of -1? That's something that could be managed in the setter.

    The factory is redunant as all the functionality shown can be provided with a couple of constructors.

  • Black Mantha (unregistered) in reply to Bradley

    The problem is that the entire point of the factory pattern is that the caller doesn't have to specify the class of the object he calls. Right now, he's just replacing the syntax of the new operator.

    Though I suppose a new version of the factory could return an instance of a subclass of the specified one. Still, then he should have a separate function (or factory) for each class he wants, not match it by string. Or did he intend to later be able to replace any class in the code by running ALL his object creations though this class? That a whole different wtf by itself.

  • isthisunique (unregistered)

    Something else easily missed:

                Type TaskType)

            int taskId,
            string fullyQualifiedTypeName)
  • Appalled (unregistered)

    Obfuscation. So many people waste their time developing it for no good reason. So many other people waste their time "refactoring" it out of existence.

  • Bradley (unregistered) in reply to Black Mantha

    I've used a similar pattern when re-inflating objects that were stored in a database. Where is isn't the programmer supplying the type name, it's the data. The developer is still free to instantiate objects via the class constructor, but the system needs a way to build objects from deflated data.

  • isthisunique (unregistered)

    Bradley this is exactly the same problem I've had. When you're confronted with DIY ORM with manual serialisation to and from the database... that wasn't the only problem and I think I know the scenario this code snippet is from.

    I also did something similar to the above when every class representing a table row had their own interfaces for every conceivable class that does something in relation to that type of row. There was almost hardly any reason to change or mix implementation or over abstract things and there was major interface bloat. Given table A, there would be interface somethingA, interface somethingelseA, etc.

    I had a factory as a rafactoring bridge (isolate what's actually different when you have a lot of duplicated code) because you had things like ten interfaces all doing the same thing exactly with nothing but a type change. You can also imagine that also means ten concrete implementations with no difference beyond the types, sometimes the name and sometimes only variable names (because something specific had to be used, not general like row). On top of that complicated anonymouse functions were being used to then passdown type specific classes to a base type inspecific subclass for some functionality.

    I replaced one WTF with a less WTF when I did something similar to the code shown here. The code here doesn't seem to be following that refactor pattern however. It makes no sense to have taskId there. Take that out and it would be a bit more concise.

  • isthisunique (unregistered)

    The more I think about it the more I think this is from something I've done recently in refactoring a horrific codebase. The original template required dozens if not hundreds of additional classes doing nothing but unrolling types (lack of a use of generics, variable types, etc). I worked with another more junior developer that didn't quite understand what I was doing especially with a lot of intermediate factories.

    If it's been obfuscated, the task id would be any generic id. The reason for some with and some without would be because it's for crud, create wont take an ID. The jump between FQCN and CN shouldn't be there though.

  • isthisunique (unregistered)

    Finally, before I sign off the rationale for this pattern:

    The code was such a mess (being that it was prototype) and in such flux that it wasn't clear exactly what it would need to be in the end or what the existing requirements were. The language also had severe limitations that programmers had difficulties adapting to such as an absence of generics, broken overloading, etc. Several strange automagic code by convention loader classes were added as an intermediate step where the code works but it also deduplicated that also reveals differences and the actual requirements so that the appropriate structure can be made with that in mind. A lot of areas where code had been unrolled had to be replaced with more scalable dynamic code.

    The alternative to this approach is as you see, new implementation Y, achieved by copying and pasting dozens of classes, searching for X and replacing it with Y. Then testing it and going through to add specifics.

  • Paul Neumann (unregistered) in reply to isthisunique

    Cool story bruh! Now, Fuck off!

  • maurizio (unregistered)

    Well, the real problem here is that there is no XML. The code should not give the class name, it should give a key to a property file containing the class name; of course, the key must be exactly equal (but upper case) to the class name (like CLASS-NAME); and to make it more patternish, the class name should be class name of a factory that can only instantiate objects of a specific class (make it CLASS-NAME-FACTORY, value "ClassNameFactory", corresponding to the ClassNameFactory class, that could instantiate only instances of ClassName); of course, for every class, you should have an interface, IClassName, that is exactly homomorphic to the ClassName. Do it for a real project, like 200 classes, 200 interfaces and 200 factory, one XML file. And of course, in the whole life of the project, there must be no real needs of polymorphism, and not a single alternative implementation of the two hundreds classes to chose from. Sound nice ? Yes, real life :-<.

  • Sole Purpose of Visit (unregistered) in reply to Paul Neumann

    That is cruel and unfair. It's not often we get to see the "thinking" behind the gibberish here presented.

    Now, whether or not Mr Unique is directly responsible, indirectly responsible, has been cargo-culted by those responsible, or even cargo-cults the same utter drivel: I for one salute anybody with the cojones to owning up to this sort of misbehaviour. The fact that Mr Unique has also chosen to describe it as "meta-programming" is icing on the cake.

  • (nodebb) 
    var task = new BasicTask(mgr);

    Obviously, that's wrong when what is really intended is this:

    var task = new BasicTask(mgr, -1);
  • Peter Wolff (unregistered)

    The obvious advantage is, that with an object created by

    var task = new BasicTask(mgr);

    you have to perform any amount of typecasts compared to the given solution.

    TaskBase task = new BasicTask(mgr);

    is far less elegant, and typecasts are so hard to implement (counting parentheses can be really hard, as any LISP guy will confirm)

  • Peter Wolff (unregistered) in reply to Virginia Nutu 
    CommentBase.CreateInstance(ArticleBase.GetInstanceByURL("https://thedailywtf.com/articles/the-distract-factory-pattern"))
    .Write(
        StatementBase.CreateInstance(
            ApologyBase.CreateInstance(1),
            Interpunct.CreateInstance("Comma", true),
            PersonsBase.CreateInstance(1,"Singular","Nominative"),
            ContractionBase.CreateInstance(ContractionBase.ContractionForceOrPermitOrDeny.Permit),
            VerbBase.CreateInstance("be",PersonsBase.CreateInstance(1,"Singular","Nominative")),
            ...
        ).ToString()
    );
  • 🤷 (unregistered)

    Moderation held for comment.

  • 🤷 (unregistered) in reply to Paul Neumann

    Cool fuck bro. Now, story off!

  • LC (unregistered)

    I got a unicorn...did anyone get a rainbow???? (The word Spring is linked to cornify.com)

  • Paul Neumann (unregistered) in reply to 🤷

    Why you gotta be so mean?

  • isthisunique (unregistered) in reply to Sole Purpose of Visit

    It might be coincidence but its a damned good one. I also sort of encourage others by pointing out dailywtf.

    I did recently make a number of triages like this and one way to similar to this to make me think it is coincidence, when inheriting a project as stopgaps. If it wasn't me and it stopped at the stopgap with no further development, that is a problem.

    If it was me, now you understand the rationality behind it :D. I had a lot of problems to contend with and when I did something like this it was meant to actually partly reveal those (one problem leads to another, if a problem is a great solution, that highlights something).

  • isthisunique (unregistered) in reply to maurizio

    Bingo.

Leave a comment on “The Distract Factory Pattern”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article