Шаблоны проектирования - Singleton, Abstract Super Class

Приветствую всех, кто не потерял надежду что-либо здесь вновь прочитать, да и полюбоваться.

Множество раз поднимается тема шаблонов проектирования, множество книг, подкастов и статей, почему бы, я подумал, поучить более тщательно и параллельно выкладывать здесь то, что выходит.

Использую: Eclipse Indigo, JUnit 4

Singleton
Singleton - одиночка, смысл данного патерна в том, чтобы использовать единственный экземпляр какого-либо класса во всем приложении. Как одно из преимуществ, Singleton дает возможность доступа из любой точки кода приложения, через ИмяКласса.МетодВозвратаЭкземпляра. Опять таки, я бы советовал пересмотреть другие варианты и только потом переходить к Singleton, в общем не злоупотреблять! Вот так вот, перейдем к реализации:

package com.vlad.pattern.singleton;

public class Singleton {

	private static final Singleton mInstance = new Singleton();
	
	public static Singleton getInstance() {
		return mInstance;
	}
}

Так же было бы не плохо удостоверится, что я вас не обманываю, напишем рядом юнит тест:

package com.vlad.pattern.singleton;

import static org.junit.Assert.*;

import org.junit.Test;

public class SingletonTest {

	@Test
	public void test() {
		assertEquals(Singleton.getInstance(), Singleton.getInstance());
	}
}

Abstract Super Class
Так вот неожиданно перейдем к смеси Interface и Abstract Super Class. Использовать данный шаблон стоит часто, из моего личного опыта. Суть в том, что часто приходится реализовывать, описывать однородные классы, яркий классический пример: Человек (Person), но человек может занимать разные должности и иметь разные профессии, но он остается человеком. Таким образом, чтобы не раскрывать и не привязываться конкретно к каждой реализации "человека", имеет смысл выдать в публичный доступ интерфейс, по которому внешний мир (приложение) смогло бы общаться с данными реализациями "человек"ов. Но нам этого мало, и не будем же мы заставлять каждую реализацию описывать, что мол это человек, с тремя ногами, ой, с двумя и руками, тоже с двумя. Чтобы избежать этого, создадим абстрактный класс, который имплементировал интерфейс и описывал основные признаки человека. Остальные реализации будут просто наследовать наш абстрактный класс. Вот как это дело может выглядить:

package com.vlad.pattern.abstractsupperclass;

public interface SomeInterface {

	public void haveFun();
	public boolean hadFun();
	public void notHaveFun();
}

package com.vlad.pattern.abstractsupperclass;

abstract public class AbstractSuperClass implements SomeInterface {
	
	private boolean hadFun = false;
	
	public AbstractSuperClass(boolean withFun) {
		hadFun = withFun;
	}
	
	@Override
	public void haveFun() {
		hadFun = true;
	}

	@Override
	public boolean hadFun() {
		return hadFun;
	}

	@Override
	public void notHaveFun() {
		hadFun = false;
	}
}

package com.vlad.pattern.abstractsupperclass;

public class AlwaysHaveFun extends AbstractSuperClass {

	public AlwaysHaveFun() {
		super(true);
	}
	
	@Override
	public void notHaveFun() {
	}
}

package com.vlad.pattern.abstractsupperclass;

public class NoWayToHaveFun extends AbstractSuperClass {

	public NoWayToHaveFun() {
		super(false);
	}
	
	@Override
	public void haveFun() {
	}
}

Ну и куда мы без теста:

package com.vlad.pattern.abstractsupperclass;

import static org.junit.Assert.*;

import org.junit.Test;

public class AbstractSuperClassTest {

	@Test
	public void test() {
		SomeInterface doHaveFun = new AlwaysHaveFun();
		SomeInterface doNotHaveFun = new NoWayToHaveFun();
		
		doHaveFun.notHaveFun(); // no need fun
		doNotHaveFun.haveFun(); // more fun
		
		assertTrue(doHaveFun.hadFun());
		assertFalse(doNotHaveFun.hadFun());
	}
}

Вот так бегло рассмотрели парочку шаблонов проектирования, дальше больше.