AngularJS and Dependency Injection

Someone came to me lost on what "dependency injection" is and why we use it, and there is an easy explanation. Dependency Inversion is the the "D" in Robert Martin's SOLID principles of object-oriented programming (Martin). "Injection" is one implementation of dependency inversion. But what does it do for us? What does it mean when Angular folks talk about it? And how does it work?

Eclipse Team Projects & Best Practices

Sometimes the metadata attached to an Eclipse project contain absolute pathnames to files on the local computer. That becomes an issue when the project is moved to a different location, to another computer or even on the same computer. It happens almost all the time with Java projects but potentially any Eclipse project has this issue. It is usually introduced by plugins that the Eclipse team has no control over, even though there are provisions for them writing relative pathnames. For example the Grails plugin always writes absolute pathnames into the file .project, even for files inside the project. What's up with that?

When absolute pathnames are included in a source code management (SCM) repository, such as Subversion or Git, then two serious problems occur. First when the project is checked out by another team member the first user's settings in the project do not correspond to the location of resources on the new computer, so the second user has to fix all of that. Even more important, when the second user checks the project back in and the first user checks it out the changes then first user's settings are all out of whack and have to be fixed again. Then the cycle of checking out new stuff and fixing project settings goes on forever.

A typical approach to handling these problems is to configure the SCM to ignore the .classpath and .project files, and all the files in the .settings folder. That is a simple approach, but it is not necessarily the best approach. So what exactly are the best practices in a team environment? After we investigate those we will look at step-by-step scenarios for Subversion and Git.

Type is a Property so Empty Classes are OK!

The first time I encountered the phrase "type encapsulation" it took a moment before I realized that it meant what I knew as "the type of a class is a property of the class." There is nothing quite like finding fancy names to label things, but I have to admit it is easier to say.

So the type is always a property of the class, albeit a hidden property. What if the type is the only property of the class? What if there are no other fields or methods in this class? One school of thought is very adamant that no class should ever be empty. The folks in that school will fight to the end that a design is wrong if it has an empty class.