이 장에서는 깨끗한 클래스를 다룹니다.
클래스 체계
클래스를 정의하는 표준 자바 관리에 따르면, 가장 먼저 변수 목록이 나옵니다.
정적(static) 공개(public) 상수가 있다면 맨 처음에 나옵니다.
그 다음 정적 비공개(private) 변수, 이어서 비공개 인스턴스 변수가 나옵니다.
공개 변수가 필요한 경우는 거의 없습니다.
변수 목록 다음에는 공개 함수가 나옵니다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣습니다.
즉, 추상화 단계가 순차적으로 내려갑니다. 그래서 프로그램은 신문 기사처럼 읽히는 것 입니다.
캡슐화
변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만, 반드시 숨겨야 한다는 법칙도 없습니다.
때로는 변수나 유틸리티 함수를 protected로 선언해 테스트 코드에 접근을 허용하기도 합니다.
우리에게 테스트는 아주 중요합니다.
캡슐화를 풀어주는 결정은 언제나 최후의 수단입니다.
클래스는 작아야 한다!
클래스를 만들 때 첫 번째 규칙은 크기입니다. 클래스는 작아야 합니다.
두 번째 규칙도 크기입니다. 더 작아야 합니다.
함수는 물리적인 행 수로 크기를 측정하지만, 클래스가 맡은 책임으로 크기를 따집니다.
목록 10-1과 같은 수십자리 줄보다는 메서드 몇 개만 포함하는 것이 훨씬 좋습니다
// 10-2
public class SuperDashboard extends JFrame implements MetaDataUser {
public Component getLastFocusedComponent()
public void setLastFocused(Component lastFocused)
public int getMajorVersionNumber()
public int getMinorVersionNumber()
public int getBuildNumber()
}그러나 여기서는 아닙니다.
메서드 수가 적음에도 불구하고, 책임이 너무 많습니다.
클래스 이름은 해당 클래스 책임을 기술해야 합니다.
실제로 작명은 클래스 크기를 줄이는 첫 관문입니다.
클래스 이름이 모호하다면 클래스의 책임이 너무 많아서입니다.
예를 들어서, 클래스 이름에 Super, Manager 등의 이름이 들어가있다면, 클래스에 여러 책임을 떠맡겼다는 뜻입니다.
또한, 클래스 설명은 만일(If), 그리고(and), ~하며(Or), 하지만(but)을 사용하지 않고서 25단어 이내로 가능해야 합니다.
SuperDashboard의 설명을 보면:
“SuperDashboard는 마지막으로 포커스를 얻었던 컴포넌트에 접근하는 방법을 제공하며, 버전과 빌드 번호를 추적하는 메커니즘을 제공한다.” 라고 합니다.
‘하며’라는 것에서 클래스에 책임을 많이 묻고 있다는 증거가 나옵니다.
단일 책임 원칙
단일 책임 원칙(Single Responsibility Principle, SPR)은 클래스나 모듈을 변경할 이유(책임)가 하나. 단 하나뿐이어야 한다는 원칙입니다.
겉보기에 작아보이는 클래스 10-2의 SuperDashboard는 변경할 이유가 두 가지 이유가 있습니다.
- SuperDashboard는 소프트웨어 버전을 추적합니다.
- SuperDashboard는 자바 스윙 컴포넌트를 관리합니다.
즉, 스윙 코드를 변경할 때 마다 버전 번호가 달라집니다.
책임. 즉, 변경할 이유를 파악하려 애쓰다보면 코드를 추상화하기 쉬워집니다.
더 좋은 추상화가 쉽게 떠오릅니다.
예를 들면, SuperDashboard에서 버전 정보를 다루는 메서드 세 개를 빼서 독자적인 클래스를 만들면,
그 클래스는 재사용하기 쉬워지는 구조가 됩니다!
SRP는 객체 지향 설계에서 더욱 중요한 개념입니다. 또한 이해하고 지키기 수월한 개념이기도 합니다.
하지만 이상하게도 SRP는 클래스 설계자가 가장 무시하는 규칙 중 하나입니다.
우리들 대다수는 ‘돌아가는 소프트웨어’에 초점을 맞춥니다.
문제는 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있습니다.
‘깨끗하고 체계적인 소프트웨어’라는 다음 관심사로 전환하지 않습니다.
게다가 많은 개발자들은 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어렵다고 우려합니다.
하지만 작은 클래스가 많은 시스템이든, 큰 클래스가 많은 시스템이든, 돌아가는 부품은 그 수가 비슷합니다.
큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직합니다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해서 필요한 동작을 수행합니다.
“도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?”
응집도(Cohesion)
클래스는 인스턴스 변수 수가 작아야 합니다.
각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 합니다.
일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높습니다.
모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높습니다.
아래는 응집도가 높은 스택을 구현한 코드입니다. size()메서드 빼고는 모두 두 변수를 사용합니다.
// 10-4 Stack.java (응집도가 높은 클래스)
public class Stack( {
private int topOfStack = 0;
List<Integer> elements = new LinkedList<Integer>();
public int size() {
return topOfStack;
}
public void push(int element) {
topOfStack++;
elements.add(element);
}
public int pop() throws PoppedWhenEmpty {
if (topOfStack == 0)
throw new PoppedWhenEmpty();
int element = elements.get(--topOfStack);
elements.remove(topOfStack);
return element;
}
}‘함수를 작게, 매개변수 목록을 짧게’라는 전략을 따르다 보면 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 많아집니다.
이는 십중팔구 새로운 클래스로 쪼개야 한다는 신호입니다. 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개줍니다.
응집도가 높아지도록 변수와 메서드를 적절히 분배해서 새로운 클래스 두세 개로 쪼개줍니다.
응집도를 유지하면 작은 클래스 여럿이 나온다
큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아집니다.
예를 들어, 변수가 아주 많은 큰 함수 하나가 있습니다. 큰 함수 일부를 작은 함수 하나로 빼내고 싶은데, 빼내려는 코드가 큰 함수에 정의된 변수 넷을 사용합니다. 그렇다면 변수 네 개를 새 함수에 인수로 넘겨야 할까요?
전혀 아닙니다! 네 변수를 클래스 인스턴스 변수로 승격한다면 새 함수는 인수가 필요없습니다.
그만큼 함수를 쪼개기 쉬워집니다.
물론 이렇게 하면 클래스가 응집력을 잃습니다. 몇몇 함수만 사용하는 인스턴스 변수가 점점 늘어나기 때문입니다.
그럼, 몇몇 함수가 몇몇 변수만을 쓴다면 독자적인 클래스로 분류 할 수 있을겁니다.
응집력을 잃으면, 쪼개면 됩니다!
아래 소수 출력 코드인 10-5를 10-6, 10-7, 10-8로 나누어 보겠습니다.
// 10-5 PrintPrimes.java
package literatePrimes;
public class PrintPrimes {
public static void main(String[] args) {
final int M = 1000;
final int RR = 50;
final int CC = 4;
final int WW = 10;
final int ORDMAX = 30;
int P[] = new int[M + 1];
int PAGENUMBER;
int PAGEOFFSET;
int ROWOFFSET;
int C;
int J;
int K;
boolean JPRIME;
int ORD;
int SQUARE;
int N;
int MULT[] = new int[ORDMAX + 1];
J = 1;
K = 1;
P[1] = 2;
ORD = 2;
SQUARE = 9;
while (K < M) {
do {
J = J + 2;
if (J == SQUARE) {
ORD = ORD + 1;
SQUARE = P[ORD] * P[ORD];
MULT[ORD - 1] = J;
}
N = 2;
JPRIME = true;
while (N < ORD && JPRIME) {
while (MULT[N] < J)
MULT[N] = MULT[N] + P[N] + P[N];
if (MULT[N] == J)
JPRIME = false;
N = N + 1;
}
} while (!JPRIME);
K = K + 1;
P[K] = J;
}
{
PAGENUMBER = 1;
PAGEOFFSET = 1;
while (PAGEOFFSET <= M) {
System.out.println("The First " + M + " Prime Numbers --- Page " + PAGENUMBER);
System.out.println("");
for (ROWOFFSET = PAGEOFFSET; ROWOFFSET < PAGEOFFSET + RR; ROWOFFSET++) {
for (C = 0; C < CC;C++)
if (ROWOFFSET + C * RR <= M)
System.out.format("%10d", P[ROWOFFSET + C * RR]);
System.out.println("");
}
System.out.println("\f"); PAGENUMBER = PAGENUMBER + 1; PAGEOFFSET = PAGEOFFSET + RR * CC;
}
}
}
}이 코드는 들여쓰기가 심하고, 이상한 변수가 많고, 구조가 빡빡합니다.
클래스와 변수에 더 의미 있는 이름으로 부여하고, 작은 클래스로 나누어 보겠습니다.
// 10-6 PrimePrinter.java
package literatePrimes;
public class PrimePrinter {
public static void main(String[] args) {
final int NUMBER_OF_PRIMES = 1000;
int[] primes = PrimeGenerator.generate(NUMBER_OF_PRIMES);
final int ROWS_PER_PAGE = 50;
final int COLUMNS_PER_PAGE = 4;
RowColumnPagePrinter tablePrinter =
new RowColumnPagePrinter(ROWS_PER_PAGE,
COLUMNS_PER_PAGE,
"The First " + NUMBER_OF_PRIMES + " Prime Numbers");
tablePrinter.print(primes);
}
}// 10-7. RowColumnPagePrinter.java
package literatePrimes;
import java.io.PrintStream;
public class RowColumnPagePrinter {
private int rowsPerPage;
private int columnsPerPage;
private int numbersPerPage;
private String pageHeader;
private PrintStream printStream;
public RowColumnPagePrinter(int rowsPerPage, int columnsPerPage, String pageHeader) {
this.rowsPerPage = rowsPerPage;
this.columnsPerPage = columnsPerPage;
this.pageHeader = pageHeader;
numbersPerPage = rowsPerPage * columnsPerPage;
printStream = System.out;
}
public void print(int data[]) {
int pageNumber = 1;
for (int firstIndexOnPage = 0 ;
firstIndexOnPage < data.length ;
firstIndexOnPage += numbersPerPage) {
int lastIndexOnPage = Math.min(firstIndexOnPage + numbersPerPage - 1, data.length - 1);
printPageHeader(pageHeader, pageNumber);
printPage(firstIndexOnPage, lastIndexOnPage, data);
printStream.println("\f");
pageNumber++;
}
}
private void printPage(int firstIndexOnPage, int lastIndexOnPage, int[] data) {
int firstIndexOfLastRowOnPage =
firstIndexOnPage + rowsPerPage - 1;
for (int firstIndexInRow = firstIndexOnPage ;
firstIndexInRow <= firstIndexOfLastRowOnPage ;
firstIndexInRow++) {
printRow(firstIndexInRow, lastIndexOnPage, data);
printStream.println("");
}
}
private void printRow(int firstIndexInRow, int lastIndexOnPage, int[] data) {
for (int column = 0; column < columnsPerPage; column++) {
int index = firstIndexInRow + column * rowsPerPage;
if (index <= lastIndexOnPage)
printStream.format("%10d", data[index]);
}
}
private void printPageHeader(String pageHeader, int pageNumber) {
printStream.println(pageHeader + " --- Page " + pageNumber);
printStream.println("");
}
public void setOutput(PrintStream printStream) {
this.printStream = printStream;
}
}// 10-8
package literatePrimes;
import java.util.ArrayList;
public class PrimeGenerator {
private static int[] primes;
private static ArrayList<Integer> multiplesOfPrimeFactors;
protected static int[] generate(int n) {
primes = new int[n];
multiplesOfPrimeFactors = new ArrayList<Integer>();
set2AsFirstPrime();
checkOddNumbersForSubsequentPrimes();
return primes;
}
private static void set2AsFirstPrime() {
primes[0] = 2;
multiplesOfPrimeFactors.add(2);
}
private static void checkOddNumbersForSubsequentPrimes() {
int primeIndex = 1;
for (int candidate = 3 ; primeIndex < primes.length ; candidate += 2) {
if (isPrime(candidate))
primes[primeIndex++] = candidate;
}
}
private static boolean isPrime(int candidate) {
if (isLeastRelevantMultipleOfNextLargerPrimeFactor(candidate)) {
multiplesOfPrimeFactors.add(candidate);
return false;
}
return isNotMultipleOfAnyPreviousPrimeFactor(candidate);
}
private static boolean isLeastRelevantMultipleOfNextLargerPrimeFactor(int candidate) {
int nextLargerPrimeFactor = primes[multiplesOfPrimeFactors.size()];
int leastRelevantMultiple = nextLargerPrimeFactor * nextLargerPrimeFactor;
return candidate == leastRelevantMultiple;
}
private static boolean isNotMultipleOfAnyPreviousPrimeFactor(int candidate) {
for (int n = 1; n < multiplesOfPrimeFactors.size(); n++) {
if (isMultipleOfNthPrimeFactor(candidate, n))
return false;
}
return true;
}
private static boolean isMultipleOfNthPrimeFactor(int candidate, int n) {
return candidate == smallestOddNthMultipleNotLessThanCandidate(candidate, n);
}
private static int smallestOddNthMultipleNotLessThanCandidate(int candidate, int n) {
int multiple = multiplesOfPrimeFactors.get(n);
while (multiple < candidate)
multiple += 2 * primes[n];
multiplesOfPrimeFactors.set(n, multiple);
return multiple;
}
}
가장 큰 변화는, 프로그램이 길어졌다는 것 입니다.
이유는 다음과 같습니다:
- 좀 더 길고 서술적인 변수 이름을 사용합니다.
- 함수 선언과 클래스 선언만으로 코드를 설명합니다.
- 가독성을 높이고자 공백을 추가하고 형식을 맞추었습니다.
10-5에서는 세 가지 책임이 있었는데, 클래스를 나누어 책임을 분산시켰습니다
- PrimePrinter
- main함수 하나를 포함하며 실행 환경을 책임짐
- RowColumnPagePrinter
- 숫자 목록을 주어진 행과 열에 맞춰 페이지 출력
- PrimeGenerator
- 소수 목록 생성
두 프로그램의 알고리즘과 동작 원리는 같지만, 하나의 거대한 함수보다는 책임이 분산된 여러 개의 클래스가 더 좋습니다.
변경하기 쉬운 클래스
대다수 시스템은 지속적인 변경이 가해집니다.
변경 때마다 시스템이 의도대로 동작하지 않을 위험이 따르고,
깨끗한 시스템은 클래스를 체계적으로 정리하여 변경에 수반하는 위험을 낮춥니다.
아래는 SQL문자열을 만드는 sql클래스입니다.
// 10-9 변경이 필요해서 '손대야 하는'클래스
public class Sql {
public Sql(String table, Column[] columns)
public String create()
public String insert(Object[] fields)
public String selectAll()
public String findByKey(String keyColumn, String keyValue)
public String select(Column column, String pattern)
public String select(Criteria criteria)
public String preparedInsert()
private String columnList(Column[] columns)
private String valuesList(Object[] fields, final Column[] columns)
private String selectWithCriteria(String criteria)
private String placeholderList(Column[] columns)
}이 클래스는 변경할 이유가 두 가지가 있기 때문에 SRP를 위반합니다.
- update문을 지원할 시점이 오면 클래스에 ‘손대어’ 고쳐야 함 - 클래스에 손대면 망가뜨릴 잠정적인 위험
- select문에 내장되 select문을 지원하기 위해
+또한, selectWithCriteria라는 비공개 메서드는 select문을 처리할 때만 사용됩니다. 클래스 일부에서만 사용되는 비공개 메서드는 코드를 개선할 잠재적인 여지를 시사합니다.
아래는 공개 인터페이스에서 각각의 Sql 클래스에서 파생하는 클래스로 만들어졌습니다.
// 10-10
abstract public class Sql {
public Sql(String table, Column[] columns)
abstract public String generate();
}
public class CreateSql extends Sql {
public CreateSql(String table, Column[] columns)
@Override public String generate()
}
public class SelectSql extends Sql {
public SelectSql(String table, Column[] columns)
@Override public String generate()
}
public class InsertSql extends Sql {
public InsertSql(String table, Column[] columns, Object[] fields)
@Override public String generate()
private String valuesList(Object[] fields, final Column[] columns)
}
public class SelectWithCriteriaSql extends Sql {
public SelectWithCriteriaSql(
String table, Column[] columns, Criteria criteria)
@Override public String generate()
}
public class SelectWithMatchSql extends Sql {
public SelectWithMatchSql(String table, Column[] columns, Column column, String pattern)
@Override public String generate()
}
public class FindByKeySql extends Sql public FindByKeySql(
String table, Column[] columns, String keyColumn, String keyValue)
@Override public String generate()
}
public class PreparedInsertSql extends Sql {
public PreparedInsertSql(String table, Column[] columns)
@Override public String generate() {
private String placeholderList(Column[] columns)
}
public class Where {
public Where(String criteria) public String generate()
public String generate() {
}
public class ColumnList {
public ColumnList(Column[] columns) public String generate()
public String generate() {
}
클래스가 서로 분리되었기에, 함수 하나를 수정한다고 다른 함수가 망가질 위험이 없고, 테스트 측면에서도 쉬워졌습니다.
update문을 추가할 때, 기존 클래스를 변경할 것 없이, 새로운 클래스를 만들어 상속받으면 그만입니다.
다른 코드가 망가질 염려는 없습니다.
이렇게 클래스를 나눔으로, 객체 지향 설계에서 또 다른 핵심 원칙인 OCP도 지원합니다.
새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직합니다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않습니다.
변경으로부터 격리
객체지향 프로그래밍에서는 구체적인(concrete) 클래스와 추상(abstract)클래스가 있습니다.
상세한 구현에 의존하는 클래스는 구현이 바뀔 때 위험하기에, 인터페이스와 추상 클래스를 사용해서 구현히 미치는 영향을 격리해야 합니다.
또한, 추상 클래스는 테스트를 더 쉽게 만듭니다.
예를 들어, 'Portfolio'라는 클래스를 생성한다고 가정해보겠습니다.
이 클래스는 TokyoStockExchange API를 사용하여 값을 계산합니다.
테스트 코드는 시장 변동에 영향을 받습니다.
매 5분마다 값이 바뀌는 API로 테스트 코드를 작성하는 것은 쉽지 않습니다.
'Portfolio' 클래스 내에서 TokyoStockExchange API를 직접 호출하는 대신 'StockExchange'라는 인터페이스를 생성하고, 이 인터페이스를 구현하는 'TokyoStockExchange' 클래스를 구현합니다.
public interface StockExchange {
Money currentPrice(String symbol);
}그리고 'Portfolio'의 생성자가 'StockExchange'를 인수로 받도록 해야 합니다.
public class Portfolio {
private StockExchange exchange;
public Portfolio(StockExchange exchange) {
this.exchange = exchange;
}
// ...
}이제 TokyoStockExchange 클래스를 흉내 낸 테스트 클래스를 생성할 수 있습니다.
public class PortfolioTest {
private FixedStockExchangeStub exchange;
private Portfolio portfolio;
@Before
protected void setUp() throws Exception {
exchange = new FixedStockExchangeStub();
exchange.fix("MSFT", 100);
portfolio = new Portfolio(exchange);
}
@Test
public void GivenFiveMSFTTotalShouldBe500() throws Exception {
portfolio.add(5, "MSFT");
Assert.assertEquals(500, portfolio.value());
}
}시스템의 결합도가 줄어들면 테스트도 가능해지며, 유연성과 재사용성도 증가합니다.
시스템 요소들은 서로 잘 격리되어 있으면 이해하기가 더 쉽습니다.
결론
클래스의 책임이 커지면 분할하자. 한 클래스는 한 가지의 책임만 가져야 하고, 책임이 늘어나면 분할해야 한다.
인터페이스와 추상 클래스를 이용하여 구현이 바뀔 때에도 유연한 대처가 가능하다.