캡슐화

급 추상클래스와 인터페이스가 궁금해져서 해결하고 캡슐화로 돌아오게 되었다ㅋㅋ 개꿀

캡슐화란 ?

객체가 내부적으로 기능을 어떻게 구현하는지를 감추는 것.

객체지향의 장점 : 한 곳의 구현 변경이 다른곳에 변경을 가하지 않도록 해준다.
객체지향은 기본적으로 캡슐화를 통해서 한 곳의 변화가 다른 곳에 미치는 영향을 최소화한다.

캡슐화 되기 전

public class Member {
	...// 다른 데이터
    private Date expiryDate;
    private boolean male;
    
    public Date getExpiryDate() {
    	return expiryDate;
    }
    public boolean isMale() {
    	return male;
    }
}

Member 객체를 이용해서 만료 여부를 확인하는 코드

if(member.getExpiryDate() != null &&
	member.getExpiryDate().getDate() < System.currentTimeMillis() ) {
    	//만료되었을때의 처리
}

위와 같은 형태의 코드는 시간이 흐를수록 이곳저곳에서 사용될 것이다.
게다가 서비스 정책과 관련 개발자도 바뀌었다면
위의 코드를 사용하는 모든 부분을 찾아서 바꿔야하는 노답 상황이 발생할 것이다.
위 코드를 사용하는 부분이 많을수록 수정해 주지 않는 실수를 범할 가능성이 높아지고, 이는 곧 프로그램의 버그로 직결된다.

그런데 캡슐화를 하게 된다면!

public class Member {
	... // 다른 데이터
    private Date expiryDate;
    private boolean male;
    
    public boolean isExpired() { // 만료 여부 확인 구현을 캡슐화
    	return expiryDate != null
        	&& expiryDate.getDate() < System.currentTimeMillis();
    }
}

위 코드의 isExpired() 메서드는 만료 여부 확인 기능을 제공하는데, 다른 클래스에서는 Member 클래스가 isExpired() 메서드를 어떻게 구현했는지 알지 못한다. 이거시 바로 캡슐화~!
만료 여부에 따라 다르게 동작해야 하는 코드는 다음과 같이 사용하게 된다.

if(member.isExpired()) {
	//만료에 따른 처리
}

캡슐화를 하기 전에는 정책이 바뀌었을 시 '만료 여부를 확인하는 코드'를 사용하는 모든 부분을 찾아서 수정해주어야 하는 번거로움이 있었지만, 이젠 그럴 필요가 없다!
isExpired() 메서드만 수정될 뿐, 이를 사용하는 코드는 변경되지 않는다.