보통 책에서는 OOP 캡슐화에 대해서 멤버변수의 값을 보호 할 수 있음에 촛점을 두고 있습니다.
예로 나이에는 음수 값이 들어가면 안되기 때문에 setAge()라는 메소드를 통해 양수만 받게 할 수 있습니다.
하지만 이런 코드적 캡슐화 뿐만 아니라 논리적 캡슐화가 중요합니다.
(코드적/논리적 캡슐화는 제가 지어낸 용어일뿐 실제 통용되는 용어가 아닙니다.
그리고 논리적 캡슐화는 코드적 캡슐화를 기반으로 합니다.)
코드적/논리적 캡슐화의 차이를 간단한 예제로 알아보겠습니다.
1. 코드적 캡슐화로 설계된 클래스와 사용예
class 배터리{
private 에너지 = 10
public get에너지() {
return 에너지
}
public set에너지( E ) {
if ( E > 0 ) 에너지 = E
}
}
B = new 배터리()
while ( e = B.get에너지() ) {
로봇.move() // 로봇을 이동
B.set에너지( e - 1 ) // 에너지 줄어듬
}
위의 배터리 클래스는 얼핏 보기에 문제가 없어 보입니다.
하지만 실수로 set에너지()의 인수값을 잘못 넣게되면 에너지가 급증/급감/변화없는 논리적 문제들이 발생 할 수 있습니다.
즉, 논리적 버그가 발생하게 됩니다.
2. 논리적 캡슐화로 설계된 클래스와 사용예
class 배터리{
private 에너지 = 10
public get에너지() {
return 에너지
}
public use에너지() {
if ( 에너지 > 1 )
{
--에너지
return true
}
else
{
return false
}
}
}
B = new 배터리()
while ( B.use에너지() ) {
로봇.move()
}
이제 배터리의 에너지는 논리에 맞게 사용하는 만큼 지속적으로 일정량이 줄어듭니다.
이렇듯 좋은 클래스를 설계하기 위해서는 첫번째 예제처럼 단순히 메소드 통해서 멤버변수에 접근할 수 있게 만든 것 뿐인 코드적 캡슐화가 아닌 두번째 예제와 같은 논리적 캡슐화가 필요합니다.
주의)
개발자의 편의를 위해서 use에너지() 내부에서 에너지를 감소 시키도록 설계한 것이 아닙니다.
배터리 클래스를 사용하는 개발자의 실수와 클래스의 오작동을 줄이기 위한 것 입니다.
개발자의 판단에 의지해도 되는 부분조차 자동으로 처리되게 만드는 실수를 조심해야 합니다.
예로 나이에는 음수 값이 들어가면 안되기 때문에 setAge()라는 메소드를 통해 양수만 받게 할 수 있습니다.
하지만 이런 코드적 캡슐화 뿐만 아니라 논리적 캡슐화가 중요합니다.
(코드적/논리적 캡슐화는 제가 지어낸 용어일뿐 실제 통용되는 용어가 아닙니다.
그리고 논리적 캡슐화는 코드적 캡슐화를 기반으로 합니다.)
코드적/논리적 캡슐화의 차이를 간단한 예제로 알아보겠습니다.
1. 코드적 캡슐화로 설계된 클래스와 사용예
class 배터리{
private 에너지 = 10
public get에너지() {
return 에너지
}
public set에너지( E ) {
if ( E > 0 ) 에너지 = E
}
}
B = new 배터리()
while ( e = B.get에너지() ) {
로봇.move() // 로봇을 이동
B.set에너지( e - 1 ) // 에너지 줄어듬
}
위의 배터리 클래스는 얼핏 보기에 문제가 없어 보입니다.
하지만 실수로 set에너지()의 인수값을 잘못 넣게되면 에너지가 급증/급감/변화없는 논리적 문제들이 발생 할 수 있습니다.
즉, 논리적 버그가 발생하게 됩니다.
2. 논리적 캡슐화로 설계된 클래스와 사용예
class 배터리{
private 에너지 = 10
public get에너지() {
return 에너지
}
public use에너지() {
if ( 에너지 > 1 )
{
--에너지
return true
}
else
{
return false
}
}
}
B = new 배터리()
while ( B.use에너지() ) {
로봇.move()
}
이제 배터리의 에너지는 논리에 맞게 사용하는 만큼 지속적으로 일정량이 줄어듭니다.
이렇듯 좋은 클래스를 설계하기 위해서는 첫번째 예제처럼 단순히 메소드 통해서 멤버변수에 접근할 수 있게 만든 것 뿐인 코드적 캡슐화가 아닌 두번째 예제와 같은 논리적 캡슐화가 필요합니다.
주의)
개발자의 편의를 위해서 use에너지() 내부에서 에너지를 감소 시키도록 설계한 것이 아닙니다.
배터리 클래스를 사용하는 개발자의 실수와 클래스의 오작동을 줄이기 위한 것 입니다.
개발자의 판단에 의지해도 되는 부분조차 자동으로 처리되게 만드는 실수를 조심해야 합니다.




최근 덧글