Sweary TL;DR Factories

I got fed up with how long-winded software pattern articles are, when often the base concepts are quite simple. In this highly-irregular micro-blog segment, I’ll give you a sweary TL;DR of some of the most common patterns out there.

From Wikipedia

In class-based programming, a factory is an abstraction of a constructor of a class, while in prototype-based programming a factory is an abstraction of a prototype object. A constructor is concrete in that it creates objects as instances of a single class, and by a specified process (class instantiation), while a factory can create objects by instantiating various classes, or by using other allocation schemes such as an object pool.

TL;DR

It makes you shit and you try not to care how, kinda like Apple.

Programming is a art

I’m pretty good at programming if I think about it. I know that there’s always more to learn, more paradigms, more languages, but at the core I think I’ve got the principles down now. It would be more accurate to say I’m good at Object Oriented Programming.

Y’see the thing about Object Oriented Programming is that it’s harder to do right than one might expect. You have to manage all these different principles (mostly SOLID, YAGNI and DRY) and find the best solution that satisfies as many of these constraints as you can, as well as not being too complex to debug or to maintain, and not taking a thousand years to execute, and the list goes on.

That’s a lot of factors to balance, and I believe that’s the key to the art of programming: finding your own balance, your own style. It sounds like programming couldn’t really be artistic, and maybe that’s down to the deterministic nature of (most) languages, but the art isn’t in the outcome, it’s in the process.

Take as an example a Dog class; how do you make that Dog walk? You give it Legs. Now the Legs handle the walking, because that’s their job. It makes sense, and the Single Responsibility Principle (the S in SOLID) is upheld, but how do you tell the Dog to walk? Well you’ll either choose Dog.Legs.Walk() but that doesn’t make a ton of sense. You don’t tell a dog’s legs to walk, you tell the dog to walk. Not only that but it breaks the Law of Demeter on top of that.

So your other option is to tell the Dog to walk and the Dog then tells its Legs to walk. This is closer to a real life situation and keeps the Law of Demeter happy and doesn’t even break the Single Responsibility Principle, but this is hardly simple code. You’ve got extra redirects in there, and the code that actually does the walking is nowhere to be found in the Dog object.

Still, the latter is the way to go with this sort of thing. It leads to tons of boilerplate, but we’re getting there with tools on how to mitigate that. VS 2015 is a step in the right direction, but there’s still a long way to go, who knows what we’ll have in ten years?

Sweary TL;DR: Dependency Injection

I got fed up with how long-winded software pattern articles are, when often the base concepts are quite simple. In this highly-irregular micro-blog segment, I’ll give you a sweary TL;DR of some of the most common patterns out there.

From Wikipedia

An injection is the passing of a dependency (a service) to a dependent object (a client). The service is made part of the client’s state. Passing the service to the client, rather than allowing a client to build or find the service, is the fundamental requirement of the pattern.

TL;DR

Giving something its shit, instead of having that something make its own shit.