The explanation requiring the fewest assumptions is most likely to be correct.
 

William of Occam

Initially I started googling, then I ended up a StackOverflow entry says you have to Roll it :) Since my need was just placing an indicator on top of the UITabItem, I didn’t go for that way.

Here is how I did:

First, I created an UIImageView which has the indicator icon. Then I added this view to my UITabBar as subview.

UIImage *upArrow = [UIImage imageNamed:@"up-arrow.png"];
UIImageView *imageView=[[UIImageView alloc] initWithImage:upArrow];
imageView.tag = ICON_TAG;
[upArrow release];
[self.tabBarController.tabBar addSubview:imageView];

This wasn’t quite enough for my need since I needed indicator to be centered. So I did some math :)

int itemCount = [self.tabBarController.tabBar.items count];
CGFloat cellWidth = tabBarController.view.frame.size.width/itemCount;
CGFloat center = (cellWidth / 2) - (INDICATOR_WIDTH / 2);

Now I could easily use this center as my indicator center. However I noticed that this wasn’t enough either since I want it to move every time after I tap to the next UITabBarItem. So I did some refactoring and:

#define INDICATOR_WIDTH 10 //u can define st like this
-(void) addIndicatorTo:(int) index {
    int itemCount = [self.tabBarController.tabBar.items count];
    CGFloat cellWidth=tabBarController.view.frame.size.width/itemCount;
    CGFloat center = (index * cellWidth) + (cellWidth / 2) 
                            - (INDICATOR_WIDTH / 2);
    UIImage *upArrow = [UIImage imageNamed:@"up-arrow.png"];
    UIImageView *imageView = [[UIImageView alloc] initWithImage:upArrow];
    imageView.tag = ICON_TAG;
    [upArrow release];
    [self.tabBarController.tabBar addSubview:imageView];
}
// just listen the item index change
- (void)tabBarController:(UITabBarController *)tbController 
        didSelectViewController:(UIViewController *)viewController {
    [self addIndicatorTo:tbController.selectedIndex];
}

So far so good. Wait a second, this adds new images every time I tap to the next UITabBarItem :S Anyways, so I refactored my code a little more:

#define INDICATOR_WIDTH 10, u can define st like this
#define INDICATOR_WIDTH 9, u can define st like this
#define ICON_TAG 11, u can define st like this
-(UIImageView *) createNewIndicator {
    UIImage *upArrow = [UIImage imageNamed:@"up-arrow.png"];
    UIImageView *imageView = [[UIImageView alloc] initWithImage:upArrow];
    imageView.tag = ICON_TAG;
    [upArrow release];
    return imageView;
}
-(UIImageView *) findIndicator {
    // return existing one
    for (UIView *view in self.tabBarController.tabBar.subviews) {
        if (view.tag == ICON_TAG) {
            return (UIImageView *) view;
        }
    }
    // if not return a new one
    return [self createNewIndicator];
}
-(void) addIndicatorTo:(int) index {
    int itemCount = [self.tabBarController.tabBar.items count];
    CGFloat cellWidth = tabBarController.view.frame.size.width / itemCount;
    CGFloat center = (index * cellWidth) 
                + (cellWidth / 2) - (INDICATOR_WIDTH / 2);
    UIImageView *imageView = [self findIndicator];
    imageView.frame = CGRectMake(
                        indicatorPositionX, 
                        3 - INDICATOR_HEIGHT, 
                        INDICATOR_WIDTH, 
                        INDICATOR_HEIGHT
                      );
    [self.tabBarController.tabBar addSubview:imageView];
}

This is basically it. So I did some animation too, here is the result:

If you guys need, I can upload the working source code to somewhere.. Hope this guides a bit.

What is Dispatching?

This is also just another OOP term. It’s not valid outside of the OOP context. I’m not gonna dive into linguistic details. Basically, it’s an invocation of a function on a specific type as in object.function(with params). For more details you can #wiki it. There are 3 types of dispatching mechanism:

• Single/Dynamic Dispatching
• Multiple Dispatching
• Double Dispatching

You might also find 2 other topics related to this subject, but I’m not gonna cover them today. You can quickly #wiki it: Monkey Patching and Duck Typing. Anyways, so let’s get back to our subject:

Single/Dynamic Dispatching

Although there is a subtle difference between them, I covered these 2 topics under the same title. So basically, when you invoke a function on a type, it’s called single dispatch as in:

    class Messenger {
        public void send(String message) { }
    }

    Messenger messenger = new Messenger();
    messenger.send("Hello World");

If there is no polymorphic structure, compiler knows this at compile time. There can be multiple send functions under different types (classes). Compiler binds them to the correct ones in the compile time:

    class Messenger {
        public void send(String message) { }
    }

    class SMSGateway {
        public void send(String sms) { }
    }

    Messenger messenger = new Messenger();
    messenger.send("Hello World");

    SMSGateway gateway = new SMSGateway();
    gateway.send("Cya in 10!");

In above example, compiler bound send(message) to Messenger and send(sms) to SMSGateway types. These are all single dispatch examples. No dynamic dispatching needed so far. However, if you have a polymorphic structure as in:

    interface Messenger {
        void send(String message);
    }

    class TextMessenger implements Messenger {
        public void send(String message) {
            System.out.println("TEXT: " + message);
        }
    }

    class XMLMessenger implements Messenger {
        public void send(String message) {
            System.out.println("" + message + "");
        }
    }

    class Demo {
        public void useMessenger(Messenger messenger) {
            messenger.send("Which messenger am I using?");
        }
    }

As you may quickly notice, this requires dynamic dispatching (run-time decision) since compiler cannot decide the actual type of the messenger which Demo.useMessenger uses. Lots of known design patterns are already based on this mechanism (Strategy, Bridge, etc..) Again I’m not going go into details, you can find more information about this on #wiki: Single/Dynamic Dispatch and #c2wiki: Single Dispatch / Dynamic Dispatch

Multiple Dispatching

Roughly it is the idea behind overloading in most programming languages. Your type has so many functions with the same name, but they all have different parameters.

    class Messenger {
        public void send(String message) { }
        public void send(String message, Person to) { }
        public void send(String message, String subject, Person to) { }
    }

You can figure out how it would work. However multiple dispatching is not just about this. I guess overloading example is misleading too. Anyways, let’s consider following example:

    interface Messenger {
        void send(String message);
    }
    class TextMessenger implements Messenger {
        public void send(String message) {
            System.out.println("TEXT: " + message);
        }
    }

    class XMLMessenger implements Messenger {
        public void send(String message) {
            System.out.println("" + message + "");
        }
    }
    class Demo {
        public void useMessenger(Messenger messenger) {
            messenger.send("Which messenger am I using?");
        }
        public void useMessenger(TextMessenger messenger) {
            messenger.send("I'm TextMessenger for sure, but?");
        }
    }

So what do you think will happen when I try to invoke Demo.useMessenger(TextMessenger). If your language doesn’t support true multiple dispatch mechanism, you’ll always end up invoking useMessenger(Messenger) function no matter what you provide. With true multiple dispatching, you’ll invoke useMessenger(TextMessenger) when you provide TextMessenger to the function. More information, again use #wiki Multiple Dispatch or #c2wiki: Multiple Dispatch BTW, #Java doesn’t support true multiple dispatching, so don’t cause any bugs while creating overloaded methods.

Double Dispatching

Well this one is pretty cool. Some define this as true dispatching :) Anyways, to me all of them are true :) In real world, all relations are actually two-way. It’s not only you’re telling somebody about something, he/she is also listening to you. Double dispatching is like this: two-way. Visitor pattern is actually good way of explaining this topic. Let’s look at the following example:

    // messenger
    interface Messenger {
        void send(Message message);
    }
    class TextMessenger implements Messenger {
        public void send(Message message) {
            // some custom operations
            message.print(this);
        }
    }
    class XMLMessenger implements Messenger {
        public void send(Message message) {
            // some other custom operations
            message.print(this);
        }
    }
    // and message
    class Message {
        public void print(TextMessenger messenger) {
            // do something
        }
        public void print(XMLMessenger messenger) {
            // do some other thing
        }
    }

As you can easily see, objects are related to each-other both ways. Message is deciding to do something based on other types.

Hope this clarifies things a bit more.

Here, I wanna just stop and speak loudly to all the developers that call themselves senior or EDIT: principal or if (experience != Experiences.JUNIOR):

People, what’s wrong with us? How come newly implemented code base is turning into a mess this fast? How come we’re allowing such a mess when we see it slowly approaching us like a monster? But of course, when it comes to the interviews, we have to ask candidates questions around design patterns, real-time problem solving skills, test driven design, and refactoring. And seriously is this why we were asking these questions? I’m so emberassed and ashamed of being a senior guy today.

Anyways, long story short, here is a 5 minute crash course about what we forget to foresee:

1. Evil Ifs

As a senior guy, you have to be aware of ifs are evil in most cases. For those who forgot, here is a quick do not forget list:

• ALLOW THEM WHEN:

Condition can be expressed without AND, OR operators: i.e

if (myContainer.hasItems()) {
    //...
}

Condition is about an encapsulated field: i.e

if (_isVisible) {
    //...
}

Condition is non-float numerical comparison: i.e

if (myCertificates.count() > 3) {
    //...
}

• BE CAUTIOUS:

When there is one or two AND, OR operators: i.e

if (_isVisible && !isParent) {
    //...
}
// SOLUTION: refactor (extract method, extract local variable, etc)

When there is negative logic: i.e

if (!_iAmSenior) {
    //...
}
// SOLUTION: refactor (make it positive like iAmJunior; 
// positive statements are easy to understand)

When there is a very long condition: i.e

if (myAwesomeServiceImpl.findExtremelyImportantSomething()
                            .equals(myLocalExtremelyImportantThing)) {
    //...
}
// SOLUTION: refactor (make it short or extract local variable, 
// trust me your application is not at the point where you should 
// worry about memory or CPU cycles)

When there is a if/else statement: i.e

if (_isVisible) {
    number = getNumberFromMoon();
} else {
    number = 1;
}
// this creates more than 2 execution paths within one method, 
// make sure you force all the possibilities to block above logic
// SOLUTION: get rid of the second part if possible as in:


number = 1;
if (_isVisible) {
    number = getNumberFromMoon();
}
// if it is not this simple, then make sure you created 
// two different executions paths (with different 
// methods/classes) before coming to this point

• DON’T ALLOW PLEASE:

When it is a null check:

if (item != null) {
    // do something...
}
// SOLUTION: find the cause of null and eliminate it.

For more information on this topic, please read my other post about null pointer exceptions.

When there is more than two AND, OR, NOT operators: i.e

if ((_isVisible && !isParent) || iAmMaster || youCanPassIsSet) {
    // do something...
}
// SOLUTION: For God's sake! you have to refactor this code. 
// The least you can do is extracting a method out of it 
// if you don't know any design patterns to apply. Check below:


if (isValid()) {
    // do something...
}

When there is nested if/else statement: i.e

if (isThisTrue) {
    if (checkIfHeIsTheMaster() && !hmmmThisSeemsWeird()) {
        // do something...
    } else {
        // do something else...
    }
} else {
    // this is just ugly...
}
// SOLUTION: Use well known OOP technique called POLYMORPHISM, 
// or if the operator is one of (>, <, ==) then various possible 
// design patterns like Strategy (behavior modification), 
// Visitor (context evaluation) or Specification (item selection). 
// If you're not happy, but you don't know what to do then talk 
// to someone you think he/she might know.

Also if you are the maintainer of the code base then you might wanna introduce static code analyzers like PMD. They can easily detect cyclomatic complexities.

Anyways, you guys can easily figure it out. You are welcome to introduce new ones. These are just some that I can think of in the middle of the night.

2. Stupid Loops

Folks, if you’re introducing loops to your logic, please make sure that you really need them. Please check the code snippets and the solutions below; I don’t wanna comment more about this:

for (int i=0; i < 2; i++) {
    if (i == 0) {
        doThis();
    } else if (i == 1) {
        doThat();
    } 
}
// SOLUTION: how about this? You don't need loop there :S
doThis();
doThat();

Another one:

for (int i=0; i < items.size(); i++) {
    if (!isVisible(items.get(i))) {
        continue;
    }
    doThis(); 
}
// SOLUTION: how about this? I stil don't know why you need continue there?
for (int i=0; i < items.size(); i++) {
    if (isVisible(items.get(i))) {
        doThis(); 
    }
}

One more:

item = null;
for (int i=0; i < items.size(); i++) {
    if (isVisible(items.get(i))) {
        item = items.get(i);
    }
}
return item;
// SOLUTION: how about this? returning values directly?
for (int i=0; i < items.size(); i++) {
    if (isVisible(items.get(i))) { // EDIT from user comments
        return items.get(i);
    }
}
return null; // if possible even return new NullItem()

3. Dependency Injections

Woov, this one is an advanced topic ah? Everyone loves dependency injection. Spring sort of frameworks are even forcing you to do it this way right? Let me tell you something; I believe after go-to statements, this one is the most misinterpreted topic in programming history. We senior guys somehow convinced ourselves to something like this: If you can inject it’s cost free! Man… just don’t do this please. Everything has a cost. This is just a way to ease/loose your tight connections with your dependencies. Don’t try to interpret otherwise.

And second thing is the famous setter injection. So if you have a setter injection set up there, it means don’t worry. It’s like we can’t think otherwise :S Opppss. Stop here! It is not like that at all if you still couldn’t figure it out. Setter injection and Constructor injection are 2 well known ways of doing this (there are other ways too). Each of them has its own advantages/disadvantages. However, let’s be honest. Constructor injection is much more declarative than setter injection.

Anyways, it’a very big debate. I’m kinda scared :P People are gonna offend me again. I just wanna say that if possible please try to use constructor injection in your custom code. If you don’t believe me, then refer to Martin Fowler’s IOC Article or Misko Hevery’s Clean Code Talks at #Google, such as: Don’t Look For Things.

4. So Many Dependencies

Just a tiny comment here. Folks, try reading #SOLID principles, ok. DON’T CREATE this much dependency :S The class itself is screaming at you: “I can’t carry this much!”, “You won’t be able to test this”, “I’ve more than 1000 lines”, “You can’t use constructor injection anymore!”

Bottom line, if you have so many dependencies, please try to find a way to separate concerns.

5. So Many Parameters

You have more than 3-4 arguments? Re-consider that code. Probably you don’t need that. I’m sure you can pull up something from that method or at least extract and call separately.

6. Pass What You Need

This bugs me a lot. Look at this:

calculateLoanForSomething(Account, Customer, World);


// here is the method
void calculateLoanForSomething(Account a, Customer c, World w) {
    if (w.date.time.hour == 11) {
        // do something here..
    }
}

// Why r u sending God objects everywhere :S
void calculateLoanForSomething(Account a, Customer c, int hour) { }

7. Long Classes/Methods

Here is my rule of thumb:

• Is it more than 20 lines? THEN: Refactor
• Is it more than 10 methods? THEN: Refactor
• Is it more than 5 package? THEN: Refactor
• Your colleague is coding? Please pair with him/her as much as you can especially if you think he/she is gonna introduce something bad. At least you can teach him/her or prevent things from happening.

I don’t know if you guys are agree with me or not. I was so ashamed today and wanted to write this. It was more like a self relaxation. Please don’t mind if I used a wrong sentence or anything. It’s almost 2AM and I’m so tired.

For more deeper information about these topics, please refer to Refactoring Book or site, SOLID Principles, Clean Code talks, Clean Code book.

A subtype must require no more and promise no less than its supertype.
 

Bertrand Meyer

How to Create a Custom Annotations?

There are a lot of documentation about this part in the Internet. All you have to do is basically creating an annotation class like below:

public @interface Copyright {
    String info() default "";
}

And that’s it. Now it’s ready to use! Now you can put copyright information to your classes :) Since we didn’t define any @Target, you can use this annotation anywhere in your classes by default. If you want your annotation to be only available for class-wise or method-wise, you should define @Target annotation. Here is a little table of what options are available:

• @Target(ElementType.PACKAGE), package header
• @Target(ElementType.TYPE), class header
• @Target(ElementType.CONSTRUCTOR), constructor header
• @Target(ElementType.METHOD), method header
• @Target(ElementType.FIELD), for class fields only
• @Target(ElementType.PARAMATER), for method parameters only
• @Target(ElementType.LOCAL_VARIABLE), for local variables only

If you want your annotation to be available in more than one place, just use array syntax as in:

@Target({ ElementType.PARAMETER, ElementType.LOCAL_VARIABLE })

One thing you may already notice is annotations are interfaces, so you don’t implement anything in them.

How to Make Use of Your Custom Annotations?

Up to here, you can find lots of examples. Okaaay, now let’s do something useful :) For instance, let’s re-implement JUnit’s @Test annotation. As you guys already know, @Test annotation is a marker annotation. Basically it marks the method as test method. If you’re expecting any exceptions, you would set expect attribute in the annotation. You can try anything here, I’m just using this example since everyone knows how @Test annotation works.

First let’s define our annotation:

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Test {
    Class expected();
}

You might notice that I used @Retention. This annotation marks our annotation to be retained by JVM at runtime. This will allow us to use Java reflections later on.

Now we need to write our annotation parser class. This class will parse our annotation and trigger some other invocations related to what we want. Keep in mind that if you have more than one custom annotation, then it’s also wise to have separate parsers for each annotation you define. So I’ll create one for this! The basic idea behind the annotation parser is using Java reflections to access the annotation information/attributes etc. So here is an example parser for our @Test annotation:

public class TestAnnotationParser {
    public void parse(Class<?> clazz) throws Exception {
        Method[] methods = clazz.getMethods();
        int pass = 0;
        int fail = 0;


    for (Method method : methods) {
        if (method.isAnnotationPresent(Test.class)) {
            try {
                method.invoke(null);
                pass++;
            } catch (Exception e) {
                fail++;
            }
        }
    }
}


}

That’s all you need. You parser is ready to use too. But wait a minute, we didn’t implement anything about the annotation attributes. This part is a bit tricky. Because you cannot directly access those attributes from the object graph. Luckily invocation helps us here. You can only access these attributes by invoking them. Sometimes you might need to cast the class to the annotation type too. I’m sure you’ll figure out when you see it:) Anyways here is a bit more logic to take our expected attribute into account:

// ...
// this is how you access to the attributes
Test test = method.getAnnotation(Test.class);
// we use Class type here because our attribute type
// is class. If it would be string, you'd use string
Class expected = test.expected();
try {
    method.invoke(null);
    pass++;
} catch (Exception e) {
    if (Exception.class != expected) {
        fail++;
    } else {
        pass++;
    }
}
// ...

Now everything is ready to use. Below example demonstrates how you use Parser with your test classes:

public class Demo {
    public static void main(String [] args) {
        TestAnnotationParser parser = new TestAnnotationParser();
        parser.parse(MyTest.class);
        // you can use also Class.forName 
        // to load from file system directly!
    }
}

Yeah, I hope you enjoyed. Don’t hesitate to put some comments down if you’ve a better approach? Thanks! Here is the full parser class implementation:

public class TestAnnotationParser {
    public void parse(Class<?> clazz) throws Exception {
        Method[] methods = clazz.getMethods();
        int pass = 0;
        int fail = 0;


    for (Method method : methods) {
        if (method.isAnnotationPresent(Test.class)) {
            // this is how you access to the attributes
            Test test = method.getAnnotation(Test.class);
            Class expected = test.expected();
            try {
                method.invoke(null);
                pass++;
            } catch (Exception e) {
                if (Exception.class != expected) {
                    fail++;
                } else {
                    pass++;
                }
            }
        }
    }
}


}

Edit: Also after receiving some emails, I guess I should add a full working example :) So here is one. Just copy paste and run the show :)

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@interface Test {
    String info() default "";
}


class Annotated {
    @Test(info = "AWESOME")
    public void foo(String myParam) {
        System.out.println("This is " + myParam);
    }
}

class TestAnnotationParser {
    public void parse(Class clazz) throws Exception {
        Method[] methods = clazz.getMethods();

    for (Method method : methods) {
        if (method.isAnnotationPresent(Test.class)) {
            Test test = method.getAnnotation(Test.class);
            String info = test.info();

            if ("AWESOME".equals(info)) {
                 System.out.println("info is awesome!");
                 // try to invoke the method with param
                 method.invoke(
                    Annotated.class.newInstance(), 
                    info
                 );
            }
        }
    }
}


}

public class Demo {
    public static void main(String[] args) throws Exception {
        TestAnnotationParser parser = new TestAnnotationParser();
        parser.parse(Annotated.class);
    }
}

So let’s say that we’ve a model class that represents Employees in the company which includes even retired ones. To reach the all employees, you would use:

Employee.objects.all()

And if you want to work with retired employees:

Employee.objects.filter(status=Employee.RETIRED)

This would give you the all retired employees. If you’re working with this object list frequently, you might want to introduce a custom manager.

Custom Managers

Before going into the custom managers, I’d like to first explain where this Employee.objects comes from. objects attribute is an instance of a special class called Manager (django.db.models.Manager). The basic idea is to provide common db operations via this attribute, e.g all(), filter(), etc.. You can find the full documentation from here. If you don’t specify any custom managers, Django automatically adds this default manager to your model class.

Custom managers on the other hand is the extended version of this manager class. And creating a custom manager is fairly easy:

class MyModel(models.Model):
    myfield = models.CharField(max_length=50)


object_provider = models.Manager()

So above model’s object_provider attribute would act exactly same as the default manager since they’re same. Please check below usages:

'''
  Below usages would provide same results.
'''
MyModel.objects.all()
MyModel.object_provider.all()

So how to customize this manager then? Again, very easy. Just extend the django.db.models.Manager class. So let’s look at the following code:

class RetiredEmployeeManager(models.Manager):
   def get_query_set(self):
      return super(RetiredEmployeeManager, self).get_query_set().filter(status=Employee.RETIRED)

From this point, the only thing you need to do is defining this manager as your manager.

class Employee(models.Model):
    name = models.CharField(max_length=50)


objects = models.Manager()
retired_ones = RetiredEmployeeManager()

And finally, you can use your new manager in your views:

Employee.retired_ones.all();

Hope it helps you to clean up some duplicated code!

Anyways, the idea is generating this placeholder words in your template by using a template tag. Here is the usage:

<!-- 
    make sure you're loading webdesign module 
    by writing {% load webdesign %} 
-->
<div id='my-text-area'>
   {% lorem %}
   <!--
       This will be replaced with "Lorem ipsum dolor 
       sit amet, consectetur adipiscing elit..."
   -->
</div>


<input type='text name='name' value='{% lorem 2 w random %}' />
<!-- 
    This will be replaced with 
    2 random latin words 
-->

<div id='description'>
   {% lorem 5 p %}
   <!--
       This will be replaced with 
       5 paragraphs of "Lorem Ipsum.." text
   -->
</div>

Isn’t Django awesome :) It has everything you need!

Anyways, the best way to learn what’s your active site-packages folder, you can quickly learn it by typing:

$ python -c \ 
"from distutils.sysconfig import get_python_lib;   \
 print get_python_lib()"

Or you can create a script like below and place it under your /usr/bin folder for further uses.

from distutils.sysconfig import get_python_lib;


print get_python_lib()

In this first screencast I’ll try to cover how you guys could break the static dependencies in your constructor. Let me give you some brief overview about these dependencies:

Dependencies

Dependencies are everywhere in our little world. Every unit, every module is depending on something. Sometimes it’s another unit, sometimes it’s another modules, and sometimes it’s another library. And there are lots of discussions currently going on to make your units, modules more scalable and more isolated! All OSGi, maven, DI (Dependency Injection) and SOLID principles are just for this purpose. To help you to break/isolate/modulate your code base.

In this screencast I’m gonna talk about only a single part of whole this picture. Static dependencies within your constructors.

Static Dependencies Within Constructors

This type of dependencies are very evil when it comes to do unit testing. It could turn into a very big puzzle game sometimes. The basic idea is some developers tend to place their dependent services or non-value objects into the constructor and using singleton and/or static methods. Without being aware of what they’re doing, they sometimes even place if/else, try/catch, switch/default statements into this tiny part of the code.

So how it happens? Very easy, let’s consider the following code snippets:

/** My class. */
public class MyClass {
    private Service service;


/** Default constructor */
public MyClass() {
    // lots of logic that shouldn't be here..
    // and
    this.service = Service.getInstance();
    TimeService.recordTime();
}


}

(EDIT) As you may clearly see, it’s very hard to test this unit since it has non-injectable static dependencies. So what do we need to do?

There are couple ways to break these dependencies. Before going into too deep, I want to clarify something here. “DON’T EVER DO THIS”! When you write your code, maybe you don’t follow TDD or anything. But please consider there will be some people that have to deal with this code after you. Then again, if you’re selfish.. There is no more word to say!

Breaking the Dependencies

As I said, there are couple ways to break these sort of dependencies.

Constructor Delegation

First and my favourite is Constructor Delegation. The basic idea for this technique is create another constructor which takes these dependencies for dependency injection and delegate the first constructor to the second one. Please consider following code’s before/after and usage scenarios:

// BEFORE 'constructor delegation'
public class LibraryManager {
    private LibraryService service;


public LibraryManager() {
    this.service = LibraryService.getInstance();
}
// more code


}

// AFTER 'constructor delegation'
public class LibraryManager {
    private LibraryService service;

public LibraryManager() {
    // delegate to the new constructor
    this(LibraryService.getInstance());
}

// new constructor
public LibraryManager(LibraryService service) {
    this.service = service;
}
// more code


}

// USAGE 'in the test'
LibraryManager manager = new LibraryManager(mockLibraryService);
// ...
// do your assertions

Endo Testing

Second technique is from Endo Testing. The technique here is extracting these dependencies to getter equivalents and overriding these methods for returning the mock/stub/fake ones. One thing here is your getter methods should be package private or protected. Please look at the following before/after and usage scenarios again:

// BEFORE 'endo testing'
public class SmartHitter {
    private Exchange exchange;


public SmartHitter() {
    this.exchange = Exchange.getActiveExchange();
}
// more code


}

// AFTER 'endo testing'
public class SmartHitter {
    private Exchange exchange;

public SmartHitter() {
    this.exchange = getActiveExchange();
}

protected Exchange getActiveExchange() {
    return Exchange.getActiveExchange();
}
// more code


}

// USAGE 'in the test'
final Exchange mockExchange = mock(Exchange.class);
SmartHitter hitter = new SmartHitter() {
    @Override
    protected Exchange getActiveExchange() {
         return mockExchange;
    }
};
// ...
// do your assertions

Setter Injection

The last one is not applicable to all scenarios, but it’s another dependency injection mechanism (@see Dependency Injection). For this one, you basically create a setter method for your dependency and allow test to inject this dependency. Let’s look at the example:

// BEFORE 'setter injection'
public class AjaxPriceModifier {
    private CatalogService catalogService;


public AjaxPriceModifier() {
    // initialization..
    this.catalogService = CatalogService(sessionHelper.getStore());
}
// more code


}

// AFTER 'setter injection'
public class AjaxPriceModifier {
    private CatalogService catalogService;

public AjaxPriceModifier() {
    // initialization..
    this.catalogService = CatalogService(sessionHelper.getStore());
}

public void setCatalogService(CatalogService catalogService) {
    this.catalogService = catalogService;
}
// more code


}

// USAGE 'in the test'
AjaxPriceModifier modifier = new AjaxPriceModifier();
modifier.setCatalogService(mockCatalogService);
// ...
// do your assertions

As you may notice, without a getter of that dependency your code still has the dependencies. It’s very wise to place a getter for that dependency and use that getter (as in Endo Testing) method in the constructor.

Summary

My personal favourite is Constructor Injection since it’s more intuitive when you’re coding the test. It clearly describes what dependencies you need to test that unit. Okay, now you can watch the screencast. Hope it turns some lights on :) All comments are welcome!