Archive

Archive for May, 2007

Partial Mocks

May 25, 2007 Leave a comment
Advertisements
Categories: Great Links

Blogmark: Behavior Driven Development (BDD)

May 25, 2007 Leave a comment
Dan North’s blog: Introducing BDD
 
Beyond test-driven development: behavior-driven development
Categories: Great Links

Blogmark: TDD links collection

May 25, 2007 Leave a comment
 

Some Test Driven Development observations (A nice roadmap)

Pasted from <http://blog.jayfields.com/2006/06/some-test-driven-development.html>

Categories: Great Links

Blogmark: Unit Testing Private Methods

May 25, 2007 Leave a comment
Some nice discussions on Unit Testing private methods
 

Testing Private Methods with JUnit and SuiteRunner

Inserted from <http://www.artima.com/suiterunner/privateP.html>

 

Testing private methods (Bruce Eckel’s blog)

Pasted from <http://onthethought.blogspot.com/2004/11/testing-private-methods.html>

 

Testing private methods (TestDriven JUnit Forums discussion)

Pasted from <http://www.testdriven.com/modules/newbb/viewtopic.php?viewmode=thread&order=ASC&topic_id=427&forum=7>

Categories: Great Links

Inversion of Control, Dependency Inversion Principle and Dependency Injection

May 12, 2007 Leave a comment

Inaroozhthum naara malaranaiyar katrathu
unara virithu urayaathaar – Valluvar
Meaning: One is like a flower which doesn’t have fragrance if (s)he cannot explain in detail what (s)he has read.
This is exactly how I was feeling in the last couple of discussions we had on Inversion of Control(IoC).

Here’s an attempt.
A program is in control, a program calls a library.
A framework is in control, A framework calls a program.
This is called Inversion of Control (other words Hollywood Principle, Don’t call us we’ll call you)
Why should the framework call you? We’ll just step a few years back in history when people were programming against the Win32 API.

Then

#include <windows.h>
const char *ClsName = "BasicApp";
const char *WndName = "A Simple Window";
LRESULT CALLBACK WndProcedure(HWND hWnd, UINT uMsg,
WPARAM wParam, LPARAM lParam);
INT WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
        MSG Msg;
        HWND hWnd;
        WNDCLASSEX WndClsEx;
        // Create the application window
        WndClsEx.cbSize = sizeof(WNDCLASSEX);
        WndClsEx.style = CS_HREDRAW | CS_VREDRAW;
        WndClsEx.lpfnWndProc = WndProcedure;
        WndClsEx.cbClsExtra = 0;
        WndClsEx.cbWndExtra = 0;
        WndClsEx.hIcon = LoadIcon(NULL, IDI_APPLICATION);
        WndClsEx.hCursor = LoadCursor(NULL, IDC_ARROW);
        WndClsEx.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH);
        WndClsEx.lpszMenuName = NULL;
        WndClsEx.lpszClassName = ClsName;
        WndClsEx.hInstance = hInstance;
        WndClsEx.hIconSm = LoadIcon(NULL, IDI_APPLICATION);
        // Register the application
        RegisterClassEx(&WndClsEx);
        // Create the window object
        hWnd = CreateWindow(ClsName,
WndName,
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
NULL,
NULL,
hInstance,
NULL);
        // Find out if the window was created
        if( !hWnd ) // If the window was not created,
                return 0; // stop the application
        // Display the window to the user
        ShowWindow(hWnd, SW_SHOWNORMAL);
        UpdateWindow(hWnd);
        // Decode and treat the messages
        // as long as the application is running
        while( GetMessage(&Msg, NULL, 0, 0) )
        {
TranslateMessage(&Msg);
DispatchMessage(&Msg);
        }
        return Msg.wParam;
}
LRESULT CALLBACK WndProcedure(HWND hWnd, UINT Msg,
WPARAM wParam, LPARAM lParam)
{
switch(Msg)
{
// If the user wants to close the application
case WM_DESTROY:
// then close it
PostQuitMessage(WM_QUIT);
break;
default:
// Process the left-over messages
return DefWindowProc(hWnd, Msg, wParam, lParam);
}
// If something was not done, let it go
return 0;
}
Almost every program written then used to have these code in addition to the application code. So a Framework can have this code built in and we can provide the application specific code which the framework can call. By that way the Framework can have all the plumbing and leave the application only with things which the application is interested in.

Now

using System;
using System.Windows.Forms;
public class BasicApp : Form {
public static void Main(string args[])  {
BasicApp form = new BasicApp();
Application.Run(form);
}
public BasicApp() {
this.OnLoad += new EventHandler(HandleLoad);
}
public void HandleLoad(object sender, EventArgs e) {
MessageBox.Show("Hello World!");
}
}

Inversion of Control takes reuse to the next level. This code has very less plumbing compared to the Win32 one. The framework calls you (as opposed to you calling the Win32 API) using the delegate.

How can frameworks call your code?
The problem in Framework calling your code is that the Framework does not and cannot know that your code exists. So How can it depend on you code and call you. Welcome to Depdency Inversion Principle (DIP). Both the framework and your code depdend on a abstraction and the abstraction provides the famework the ability to call you. Rather the the Higher level module (the framework) depdening on the lower level module (your code). Both depend on the abstraction (delegate). What are the possible abstractions that can be used?

The framework can use
Abstract classes (virtual dispatch)
Interfaces
Delegates
Function Pointers
Closures
Special Methods (e.g. Main)

What is Dependency Injection?
When an object is dependent on another object, the dependency can created by the object itself (the object is in control). Or an external framework can instantiate and provide the depedency (typically based on configuration, making your code more pluggable. The framework is in control here). This is called Depdency Injection. This is a specific case of IoC. DI combined with DIP can make you code more pluggable.

Suggested Reading:
Inversion of Control:http://martinfowler.com/bliki/InversionOfControl.html
Dependency Inversion Principle: http://www.objectmentor.com/resources/articles/dip.pdf
Dependency Injection: http://www.martinfowler.com/articles/injection.html
The Delegates Abstraction: http://sendhil.spaces.live.com/blog/cns!30862CF919BD131A!346.entry
Closures: http://www.martinfowler.com/bliki/Closure.html

Iteration Retrospectives

May 8, 2007 Leave a comment

Retrospectives:- We continually improve our work habits.

Pasted from <http://www.jamesshore.com/Agile-Book/retrospectives.html>

 
 

Some Patterns for Iteration Retrospectives

Pasted from <http://xp123.com/xplor/xp0509/index.shtml>

 
 

How To Run An Iteration Retrospective

Pasted from <http://www.industriallogic.com/papers/HowToRunAnIterationRetrospective.pdf>

 
 

The team had been running iteration retrospectives for several months and they had consistently identified the same issues in need of improvement.

Pasted from <http://radio.javaranch.com/lasse/2006/02/13/1139795651169.html>

 
 

Retrospective Questions

Pasted from <http://www.futureworksconsulting.com/blog/2007/02/09/retrospective-questions/>

 
 

Iteration and Release Retrospectives: The Natural Rhythm for Agile Measurement

Pasted from <http://www.agilejournal.com/content/view/51/>

 
 

Retrospectives

Pasted from <http://codebetter.com/blogs/jeremy.miller/archive/2007/05/03/retrospectives.aspx>

 
 

Better Agile Retrospectives

Pasted from <http://theagileblog.net/2005/11/better_agile_retrospectives_1.html>

 
 

Categories: Uncategorized