We have a few positions vacant at the moment – have a look:

In Sao Paulo, Brazil – we need a junior front-end developer. You are highly skilled in front-end development, with specific skills in CSS, HTML and Javascript. You are a competent programmer, but you prefer to work on the front-end. You will be working under the guidance of an experienced and expert engineer. You like working with bright and clever people, and you are passionate about the web. The successful candidate will speak English, and will be a paulistano, or be willing to relocate to Sao Paulo.

In Johannesburg – we are looking for a senior technical architect. You will have the opportunity to establish the blueprint and create the framework for truly cutting edge media delivery platforms that will change the face of media in South Africa. And that is no exaggeration. You should have outstanding technical skills, including the ability to code as and when required. You must be able to interact with a team of highly skilled professionals. You will ideally have experience of VOD, digital TV, IP-TV and related technologies. A background as a developer is essential – you will have in-depth knowledge of the Microsoft .Net platform, but also wider knowledge of open source platforms and languages. You are comfortable dealing with executives and senior managers. You’re not only an ubergeek, but also an inspirational tech leader. This is a challenging position – but it represents a massive opportunity to the right person. Detailed requirements here.

In Cape Town – we are looking for a junior tester, who will devote a great deal of time to ensuring that a large corporate social network meets the right quality standards. You will be part of the SWAT core team – you must be prepared to work with some of the best developers, architects, geeks and web-heads you are ever likely to meet. Can you execute tasks on your own initiative, prepare and execute test plans ? More details on the position can be found here.

Cape Town – we are looking for someone to play the role of Internet Evangelist. This role is available to anyone who is absolutely passionate about the web, who is capable of conveying this passion to diverse audiences, who learns quickly … and who can teach others. Your role will be to evangelise the use of Web technologies (and other Internet related technologies) into the larger group – the challenge is to make people from all non-internet businesses see the Internet as an opportunity not a threat. In addition you will perform tasks as assistant community manager for the corporate social network, and you will assist the Analyst in the team with research tasks. You must be willing to travel in South Africa and abroad, as required. To apply for this job, you will have to demonstrate passion, interest and knowledge of the Web and related technologies. You are a well-spoken, confident geek, web-head and proud to be a Web addict.

Finally, and also in Cape Town – we want to recruit a PHP developer. You will be have outstanding technical skills, wide experience in web based development, and you will be able to hold your own amongst an elite group of developers and architects. Javascript, Zend Framework, AJAX, OO, Web 2.0, REST, SOAP and UML will be old news to you. You are passionate about the web. If you think Twitter is silly, you don’t need to apply. More information here.

If you are interested in any of these positions, please send your CV to Melanie Koch. We look forward to hearing from you.

Obviously, the schema presented here is just part of a complete software architecture – for the purposes of this discussion we assume that all orders issued are stored in a relational database instance (MySQL more specifically). The natural way of thinking leads the architect to model a dependency from Order to MySQL, mainly because the former class is the one responsible for deciding when database transactions begin. However, the resulting dependency leads to at least three undesirable consequences, as follows:

• Business objects and rules start depending on purely technical matters such as database manipulation. We all know that what is cutting-edge technology at the moment, is likely to become obsolete in a few month’s time. Business concepts, on the other hand, tend towards stability – an order will always be an order, potentially keeping the same attributes in the long-run. It’s important to notice that the undesirable direction of the dependency may force the developers to change business objects whenever the database technology they are using changes.
• The architecture assumes that storage will always be handled by a specific relational database. This is a risky assumption, since the development team may decide to swap out the database provider. Moreover, alternative storage mechanisms like the file system itself may come up as a viable option in the future.
• Unit testing becomes painful. This sort of dependency makes it difficult to use the mock objects technique, which is quite common within unit testing methods.

We can address these issues by placing an interface between the classes, and therefore inverting the related dependency. As demonstrated below, we have just succeeded in decoupling storage manipulation from business objects.

The dependency inversion technique has addressed all the problems we identified. People usually think of an interface as just a simple set of common functions, but it’s not. Instead, a strategically applied interface contributes desirable outcomes such as mobility, flexibility, reusability, and maintainability.

OK, but wait a minute, the business object Order still needs to send messages to the data access layer, doesn’t it? Yes, it does, but interfaces do not exist at runtime, only objects do. Therefore, IStorage is replaced by an object defined by a class that realizes this interface, the MySQL class in our example. It’s now clear that we could also have realizations to other database providers and storage mechanisms (Oracle, MSSQL, PostgreSQL, and File System).

Visualizing the dependency inversion is even easier when we deal with components, instead of classes. The first component diagram below does not take advantage of the technique we just learned.

Unlikely the previous diagram, the following schema turns over the dependency between the components, making the business component independent, and enabling new data providers.

The black-box notation makes things even clearer:

Again, the dependency inversion:

Techniques such as the one presented by this post prevent the Active Record pattern from being a complete failure. Now I bet you realize how powerful dependency inversion is, right? So back to your dashboard and take your interfaces to the next level!