2012/01/21 10:20
Enum (enumeration)은 유용한 도구입니다. 전에 좀더 나은 코드 쓰기 에서 이야기 했듯이 enum 은 자칫 발생할 수 있는 런타임 에러를 사전에 방지하거나 가독성이 좋은 코드를 만들 수 있습니다. 하지만 이 enum 을 남용하면 객체지향적인 디자인에 방해가 되거나 얽히고 섥힌 코드의 주범이 되는 경우가 많습니다.
Enum 을 사용하면 거의 필수적으로 따라 붙는 것이 if 문이나 switch 문 입니다. 보통 객체의 상태(status) 를 확인하고 그 상태에 따라 어떤 작업을 해야하는 경우입니다. Enum 의 값이 한두개 정도의 간단한 경우라면 문제가 되지 않지만, 시간이 지남에 따라서 여러개의 값으로 증가를 하게 되거나 새로운 상태가 추가가 되면 실타래 같은 코드가 시작이 됩니다. 더군다나 enum A 와 enum B 가 서로 연관성을 갖게 되면 중복된 if 문이 난무하게 되죠. 다음과 같은 코드는 많이 볼 수 있습니다.
위의 예는 enum 이 객체지향 설계를 방해하고 있는 경우입니다. 이런 경우 Employee 라는 클래스 안의 여러 곳에 if 문이 들어가는 것을 피할 수 없습니다. 무엇인가 하려 할 때 항상 EmployeementType 을 먼저 확인하고 그에 따라 다른 작업을 실행해야 하기 때문입니다.
이런 경우에는 EmployeementType 을 enumeration 으로 표현하는 것보다, Employee 객체를 FullTimeEmployee 와 PartTimeEmployee 두개로 상속을 받는 것이 바람직합니다. 그러면 중첩된 if 문을 없앨 수 있고 여기 저기 흩어진 if 문을 모두 제거할 수 있습니다.
객체는 최대한 작게 쪼개어 지는 것이 좋습니다. 객체에 속성이나 메서드가 많다면 그 객체가 너무 일반적이거나 (monolithic) 너무 많은 책임을 갖고 있는 것일 수 있습니다. 또, 한 객체 내에서 같은 상태 확인 작업을 여러 곳에서 하고 있다면 두개의 다른 객체로 분리해 낼 싯점인지 생각을 해 보는 것이 좋습니다.
Enum 을 사용하면 거의 필수적으로 따라 붙는 것이 if 문이나 switch 문 입니다. 보통 객체의 상태(status) 를 확인하고 그 상태에 따라 어떤 작업을 해야하는 경우입니다. Enum 의 값이 한두개 정도의 간단한 경우라면 문제가 되지 않지만, 시간이 지남에 따라서 여러개의 값으로 증가를 하게 되거나 새로운 상태가 추가가 되면 실타래 같은 코드가 시작이 됩니다. 더군다나 enum A 와 enum B 가 서로 연관성을 갖게 되면 중복된 if 문이 난무하게 되죠. 다음과 같은 코드는 많이 볼 수 있습니다.
if (employee.empType == EmploymentType.FullTime)
{
if (employee.serviceYears == ServiceYearsCategory.ThreeYears)
{
employee.VacationDays = 10;
}
else if (employee.serviceYears == ServiceYearsCategory.FiveYears)
{
employee.VacationDays = 20;
}
else if (employee.serviceYears == ServiceYearsCategory.TenYears)
{
employee.VacationDays = 30;
}
}
else if(employee.empType == EmploymentType.PartTime)
{
...
}
위의 예는 enum 이 객체지향 설계를 방해하고 있는 경우입니다. 이런 경우 Employee 라는 클래스 안의 여러 곳에 if 문이 들어가는 것을 피할 수 없습니다. 무엇인가 하려 할 때 항상 EmployeementType 을 먼저 확인하고 그에 따라 다른 작업을 실행해야 하기 때문입니다.
이런 경우에는 EmployeementType 을 enumeration 으로 표현하는 것보다, Employee 객체를 FullTimeEmployee 와 PartTimeEmployee 두개로 상속을 받는 것이 바람직합니다. 그러면 중첩된 if 문을 없앨 수 있고 여기 저기 흩어진 if 문을 모두 제거할 수 있습니다.
객체는 최대한 작게 쪼개어 지는 것이 좋습니다. 객체에 속성이나 메서드가 많다면 그 객체가 너무 일반적이거나 (monolithic) 너무 많은 책임을 갖고 있는 것일 수 있습니다. 또, 한 객체 내에서 같은 상태 확인 작업을 여러 곳에서 하고 있다면 두개의 다른 객체로 분리해 낼 싯점인지 생각을 해 보는 것이 좋습니다.
'소프트웨어 개발' 카테고리의 다른 글
| Enum 과 객체지향 (0) | 2012/01/21 |
|---|---|
| 어제 생긴 일... (4) | 2011/11/15 |
| 애자일 개발자 이끌기 - Software Engineering Radio (0) | 2011/10/28 |
| 메서드 독립성 (0) | 2011/09/14 |
| 유닛테스트에 대한 Roy Osherove 의 인터뷰 (0) | 2011/08/03 |
| 오라클의 자바 7 (0) | 2011/08/03 |
