So for this week I have decided to read “Inversion of Control- An Introduction with Examples in .NET” from the joelabrahamsson website. The reason I chose this article is because with the subject of automatic testing, Inversion of Control and Dependency Injection is what I do not get mostly. It is usually a topic that I do not hear that much, so I believe this will help in understanding on the purpose of using both principles.

This article basically by the title goes over Inversion of Control from the definition to the ways of using it. So Inversion of Control is essentially a way to the invert the flow of control in comparison to procedural programming. It means that every module can focus on what is it designed for and ensures clarity with little complications. The benefits in using Inversion of Control is that when changing the interface of a particular class uses in runtime, that class can no longer be dependent on another class and the code can be decoupled. This means that the class is provided the ability to swap dependency implementations in different environments and allows a component be tested through mocking of dependencies. When having to apply Inversion of Control and getting the instance, there are two ways to get it without having to know about any concrete implementations. These ways are Dependency Injection and Service Locator. Dependency Injection injects an instance by using construction injection or property injection while Service Locator injects an instance based on the configurations of the concrete class. Dependency Injection is mostly used than that of Service Locator, but Service Locator can be used when there are situations Dependency Injection seems impractical.

Based on the content of this article, I would say that it was a good overview about the ideas of Inversion of Control. The author was able to give a few examples of using it and have the UML diagrams to back up with the codes provided. What I did before to understand Inversion of Control was to envision real life scenarios to compare without and with it. The concept is that without it, there is limited options for a software consumer. But by implementing Inversion of Control, there are more options over the software. With that in mind, it made envisioning scenarios easier than it seems.

What I learned from this article is that Inversion of Control shall not be used in all cases because of program flow. The idea is that while it is a useful way to design methods when writing a library that will be reused, it is only critical if there are many cross-cutting concerns. For future practice, I shall try to use Inversion of Control when it is necessary to change a small part of code. This is because it is a practical way of reducing code duplication and it is strong for coding against interfaces instead of implementations.

Link to the article: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/

This blog post talks about why having a constructor do too much work is a bad programming practice. When a constructor instantiates and initializes its collaborators, the result is often inflexible and can shut off the ability to inject test collaborators. The author gives a few reasons why this is a flaw:

• It violates the Single Responsibility Principle – Mixing collaborator construction with initialization suggests that there is only one way to configure the class. Having object graph creation take place in the constructor violates the Single Responsibility Principle
• Testing directly is difficult – If a constructor does a lot of work, you will have to do that work when creating the objects while testing
• Subclassing and overriding to test are still flawed – When you use subclassing you will fail to test the method that you override
• It forces collaborators on you – You don’t always want to create all an object’s collaborators when you test it

Signs that a constructor is doing too much work:

• new keyword in the constructor
• Static method calls in a constructor
• Object not fully initialized after the constructor finishes
• Conditional or looping logic in a constructor
• Complex object graph creation in a constructor rather than using a factory or builder
• Using a initialization block

Fixing the Flaw:

To fix this flaw you should remember to pass collaborators into your constructor rather than create them there. The responsibility for object graph creation and initialization should be moved into another object such as a builder, factory, or provider. These collaborators can then be passed into the constructor.

Overall, the phrase “work in the constructor” means doing anything that makes instantiating your object difficult or introducing test-double objects difficult.

I thought that this blog did a very thorough job of explaining why doing work in a constructor is a flaw that should be avoided. It did a good job explaining why it is a flaw, recognizing when it is happening, and explaining various methods to fix it. There are also a lot of code examples that demonstrate the problem more concretely and show how it can be fixed. After reading this blog I now have a better understanding of what should and should not be included in a constructor. This blog also introduced me to some new object-oriented programming concepts that are too specific to be covered in the classroom. Overall I thought this blog was very informative and I expect to use what I have learned in future programming projects.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Recently while working on our final project, my partner and I ran into an issue involving the positioning of courses on a schedule. We were trying to figure out a way to place elements (courses) on top of another element (the schedule). Naturally on our way to a solution, we stumbled upon absolute positioning. Using this we were able to place the courses in their correct positions on the schedule.

Even though that solution seemed to work, there was something about it that didn’t sit right with me. For whatever reason, the thought of using an absolute position on the page to place elements on another element just did not seem like a smart thing to do. What would happen if I added elements above the table?

Because the table uses the default position, its placement is based on its order in relation to other elements. However, the courses are using an absolute position relative to the page.

The solution to this is relatively simple, but not necessarily one of the most obvious solutions for those who are new to CSS.

CSS Positioning Blog

In the blog CSS Positioning: A Comprehensive Look, Louis Lazaris discusses the main types of positions used in CSS’s position property. The positions are:

• static – positions the element statically, following the normal flow based on its order in relation to other elements, typically unnecessary.
• relative – behaves the same way as a static element, except that if you give it a positioning attribute, such as: “left: 20px;”, it will be offset 20px left from its original spot.
• absolute – causes the element to be completely removed the the document’s normal flow, no longer interacting with other elements. Absolute elements are positioned relative to the page, or to its parent assuming its parent is relatively positioned.
• fixed – behaves similarly to absolute elements, however it won’t move when the document is scrolled or relatively to its parent element.

The key part of this is that absolutely positioned elements can be changed by added a relatively positioned element as its parent. Thus the simple solution to our problem was just to change the schedule (or table) to use a relative position, even though we weren’t making any changes to its position visually.

Not only does this change where the elements are positioned relative to, it also makes it so that if I were to set the width or height of the course’s container using a percentage instead of pixels, it would be relative to the size of the schedule instead of the page.

The reason I chose this blog was because it contained exactly what I was looking for: a way to place absolutely positioned elements relative to its parent.

Source: http://blog.teamtreehouse.com/css-positioning

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

With this semester coming to a close, I thought it would be appropriate to write about our most recent topic discussed (code review) and compare it with something widely covered during this course: unit testing. I found a great Codacy blog to aide my exploration of the similarities, differences and importance of these two topics.

Codacy explains that code review generally means to manually inspect the code, whereas unit testing is implemented to automatically detect bugs within the code. It seems to me that unit testing is focused solely on finding malfunctions (bugs) in a product, whereas code review considers the overall style, readability and functionality of that code as well.

Rather than asserting that one is superior to the other, Codacy suggests that both code reviews and unit testing ought to be done in all software projects. I feel software developers can produce efficient and supreme quality products when appropriately combining the two techniques. Thus I have to agree with Codacy regarding the implication that unit testing should not replace code reviewing, and vice versa.

The blog author gives a great example of why unit testing alone should not replace code review. It seems that there was an actual situation that occurred where a vast series of unit tests were run to ensure the integrity of a very important governmental system. But when the program was scheduled to go live, it failed to run. It turns out that the system was scheduled to launch on a Sunday, but the unit testing team only worked weekdays, thus unit tests were not run on the weekends. For one reason or another, it seems that code reviews had failed to be conducted for this governmental system.

My takeaway from the scenario described above is the fact that code reviews should have certainly have taken place. This is because I feel that code reviewers, through proper analysis, could have identified there was a flaw within the code that made the system inoperable during Sundays. Examples such as this solidify my belief that human analysis should be coupled with computerized testing. In a sense, code reviews “double check” the work of automated unit tests.

On the other hand, I also agree with Codacy in the sense that code review should not replace unit testing either. In regard to automated unit testing, computers generally have the capacity of identifying bugs at a speed that far exceeds the capability of the average person. Trying to manually replicate the work of automated tests in this sense just seems inefficient to me.

I found Codacy’s blog regarding “Code Review vs Unit Testing” to be engaging and informative. Based on what I’ve learned from the real world examples given by Codacy, I feel that code reviews and unit testing are equally important. My goal is to continue to learn and improve my expertise in code review and unit testing. I am confident that I will need both of these skills during my professional career.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.