Dependency Injections
The Resource Model for Web Design holds that there are certain elements of server side web pages such as the database connection and notifiction object should be considered resources available throughout a program.
A common put-down for this style of programming is to call the resources a "dependency injection," as the code that uses these resources become dependent on the resources.
I agree that it is worthwhile to minimize dependencies, but dependencies du exist in this world. For example a computer program can't run if it is not on a computer. A web based computer program is dependent on web servers.
A data-driven web site is dependent on the ability to connect to a database.
The whole point of the Internet and computer networks is to connect computers. Web sites are entirely dependent on the existence of this network. This web page is dependent on the existence of your web browser.
Yes it is possible for the programming elite to put down whoever they don't like by accusing their enemies of dependency injections.
But what these people are doing is just pure ideological garbage. (The article Patterism argues that "Design Patterns" is more of an ideology than a technology.)
Dependencies exist everyone. Let's consider the following following two objects:
class bar {
function somethingImportant () {
// do something important.
}
}
class foo extends bar {
function mystuff() {
// put together my stuff
// execute somethingImportant()
}
}
In this code class foo extends bar.
Well, guess what?
I just injected a dependency.
Every time one object extends another, the programmer injects a dependency.
The way you get rid of a dependency is to copy the function somethingImportant() from bar into foo.
Copying code to get rid of dependencies can create a programming nightmare as suddenly there is a whole bunch of code doing the same thing.
The complex class structures used by Design Pattern enthusiasts have all of the same dependencies as the traditional programs that patternists love to put down.
Programs built around complex class structures actually open the gateway for dependency injection. The problem with objects is that objects can create multiple pathways through the object.
Different programmers are likely to take different pathways through complex objects. The problem here is that programs calling the object become dependent on each of the pathways. The group that created a complex object suddenly have to support all of the pathways that programmers routinely follow.
Flow Control Procedure
One way to handle this problem is to create a procedure that encapsulates the object. YES, Object Oriented Programmers. I am advocating taking your precious little objects and encapsulating them in a procedure.
So, lets say you go through your code and find that there are four common paths through an object and you test your code with the flow control object and prove that these pathways are sufficient. The exercise allows you to go back and optimize your object for the common pathways.
The point I am trying to make here is that there is not a fundamental conflict between object oriented programming and procedural programming.
Object programmers know it is possible to roll up a group of procedures into an object. Conversely, every path through an object can be represented as a procedure. A procedure with a flow control variable can mimic the functionality of an object.
Neither Patterns nor Object Design eliminates dependencies. A class that extends a base class has a dependency on the base class.
A complex object might create unanticipated dependencies as programmers, who tend to be a resourceful lot, tend to take a variety of paths through the object. When a complex object is in the market, the company that made the object wil find itself having to support all the paths through the object.
I designed the procedure dbMain to encapsulate the PDO object and to provide consistent error reporting about the database object.
Objects and Web Design
I love object oriented programming. But I've rejected the stance that objects are somehow a higher form of thought that is in conflict with procedures.
I have always seen objects and procedures as complimentary technologies. I tend to use procedures when I want a cleanly defined path through a program and objects when I want to take variable paths during the execution of a program.
Despite the fact that I like objects, it turns out that much of web design is is best served by a procedural approach. Let's consider a standard web page:
A request for a web page comes to the server. This request usually has a very limited number of parameters in the $_POST, $_GET and $_COOKIES variables.
The web program itself will take a discrete path determined by the values in the variables.
Because the Internet happens to be full of hackers, you want to process the input through well designed procedure that simply throws out anything that does not fit the expected form.
Eventhough I like objects, I realized early on that most web pages should be written with procedures.
Unfortunately, when I try to share my code online, I am hit by a barrage of accusations that say that, since I use procedures, I am creating anti-patterns and dependency injectsions. When we all know that patternism is just ideological garbage.
Dependency Paradox
Dependencies exist. This is especially true on the world wide web where computers are strung together in networks.
The goal of the programmer isn't to eliminate dependencies but to take control of dependencies.
The best way to handle and external dependency, such as a database program or external resource, is to create a program that wraps around the dependency that you can control. This is called "encapsulation."
Now, yes, it is true that creating a wrapper for a resource creates a situation where your code is dependent on the wrapper. This so-called "dependency injection" gives you, the programmer, greater control.
The fact that people become dependent on their controls is just one of those strange paradoxes in life.
The whole point of web design is that the web lets us network together all sorts of different things. Rather than rejecting this diversity, I revel in it.It is impossible to eliminate dependencies; So, the driving question is: What is the best way to handle the dependencies.
Conclusion
The Resources Model for Web Design is called a dependency injection because code that uses the resources in the model become dependent on that code.
The code in question is a procedure that encapsulates an object. There is nothing wrong with writing procedures. In some ways, the web is better suited to procedures.
Web pages work as follows: A web browser sends a request to a server for a web page. This request has a fixed amount of data. Your web program looks at the request then outputs a string of text called a web page.
A program that follows a determined path from a fixed input to a fixed output is called a procedure.
A procedure is not an inferior form of thought.
Pattern snobs will spit in your eye and call your approach names like "anti-patterns" and "dependency injections" when the code pattern snobs admire actually has more hidden dependencies.
Don't let the insults you receive drag you down. If you have to answer a tit for a tat point out the dependencies in their code. Every extended object is a dependency and every path through a complex object must be supported, creating unanticipated dependencies. If that's not enough, point out that Design Patterns is not a technology. It's an ideology, and the last thing we need is for web programming to be taken over by ideologues..
Comments and criticisms are welcome on my disqus forum".
Resource Model ~ yintercept ~ Roots of Sound Rational Thinking