Tag: Software Development (Page 18 of 20)

Singleton Design Pattern and Dependency Injection, Part 2

September 1, 2016 / Tom / 0 Comments

In the previous post, I said that I was going to talk about how to use the Singleton Design Pattern as a simplistic way to introduce a dependency injection container into a project.

The Singleton Design Pattern and Dependency Injection Containers

One of the best comments I’ve seen about dependency injection containers comes from Stack Overflow (and Joel Spolsky, even):

IoC containers take a simple, elegant, and useful concept, and make it something you have to study for two days with a 200-page manual.

And there’s a time and a post for where I could digress, but that’s not this post. Instead, there are a few nuances about this idea that I want to clarify before I go any further:

Dependency Injection Containers are more than just ways to store objects. They handle other additional logic. I’ll cover more about this later in the article.
I don’t recommend sticking with an implementation of the Singleton Design Pattern for a container (or for very many things, for that matter).
The purpose of showing this as a strategy is a way to show how you can take a project with a tight deadline, a desire to use software development best practices, and find some practical middle ground.

All of that to say is that what I’m going to show is not what I consider being a best practice for using dependency injection containers.

Instead, it’s a way to “meet in the middle” when it comes to working under pressure for building solutions for others all the while not wanting to sacrifice sound engineering principles.

Singleton Design Pattern and Dependency Injection, Part 1

August 31, 2016 / Tom / 0 Comments

The Singleton Design Pattern is something that I’ve talked about before in previous articles.

As Wikipedia so eloquently defines it:

In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.

If you’ve done any work with object-oriented programming and familiar design patterns, then it’s likely that you’ve come across it (if you haven’t used it).

Depending on who you ask, the singleton design pattern may be treated as an anti-pattern, like some weird use of a “poor man’s namespace,” or one of the many other negative views of it.

Though these perspectives aren’t necessarily wrong, there are times where it’s okay to use it.

The Reality of Software Development Pressure

August 30, 2016 / Tom / 0 Comments

I recently heard a quote from someone (and if I could remember who said it, then I’d give attribution – but this is what happens when tweets just happen to scroll on by, right?) that I liked:

Setting deadlines before requirements is like setting a wedding date before you’ve met your partner.

And yes, it’s obviously tongue-in-cheek, but it’s lead me to think a lot about the breakdown that exists between all of the discussion around software best practices, things we should be doing, architectures and patterns we should be following, and then what we’re actually doing and what we’re shipping out to the world.

Development Pressure: Setting Requirements

At this point in my career, I can’t help but wonder if we enjoy talking about and discussing a lot of the things we should be doing as some escape to some of the hacked solutions we end up releasing.

Practical Tips for Refactoring Code

August 26, 2016 / Tom

If you’ve worked on a project available to any reasonably sized audience, then you’re no doubt familiar with the bug reports, problems, and issues that can come in after something has gone live.

It’s true that the majority of the work in software comes after the first reason of a release.

Think about it this way:

Once you’ve built the product, released it, and then are responsible for maintaining it, how often do you have to triage issues? Then how frustrated are you that you’re fixing something that wasn’t foreseen earlier during development?

The thing is, this is entirely normal. It’s no less frustrating. But it’s normal. However, there are small, practical things we can do to our code throughout development or during maintenance.

And that’s part of the problem that we often face, isn’t it? There are things we know we can do but the amount of time it takes to do them is often incompatible with our deadlines.

So what can we do?

One Step Towards Dependency Injection in WordPress

August 25, 2016 / Tom / 0 Comments

Dependency Injection is one of those programmer-y terms that sounds far more complicated than it is.

As defined in Wikipedia:

Dependency injection allows a program design to follow the dependency inversion principle. The client delegates to external code (the injector) the responsibility of providing its dependencies.

The client is not allowed to call the injector code. It is the injecting code that constructs the services and calls the client to inject them. This means the client code does not need to know about the injecting code.

But think about it like this (because if you’ve used object-oriented programming, you’ve no doubt done something like this):

You have a class, say Class A that maintains a reference to another class, Class B.
In the constructor for Class A, we instantiate Class B and set it equal to a property.

Easy enough, right? Here’s the implication:

Class A now has a dependency on Class B and that dependency is only set during the instantiation process in the constructor of Class A.

On a small scale, this isn’t that big of a deal but as a plugin or an application gets more and more complicated, there are all of these dependencies set in the system without any way to necessarily test them in isolation.

And don’t get me wrong: There should be some cohesion among objects in an application, but the degree to which they are coupled should be small. There are a lot of reasons for this many of which are outside the scope of this post.

To help mitigate this, programmers have created all kinds of strategies to make sure that our classes can be small and focused and tested in isolation all the while working with other parts of the system.

And one of the most popular ways to do this is through dependency injection. But what does dependency injection in WordPress look like (and is it any different than in other applications)?