0409_PJI는 이걸로 대체한다.

흔히 객체 지향 프로그래밍과 절차 지향 프로그래밍을 말할 때 Java와 C를 말한다.
그래서 절차지향과 객체지향은 처음에는 작성 순서의 차이라고 생각했는데,
생각해보니 함수 선언부가 있으면 C언어도 작성 순서는 다르게 짤 수 있다.

그래서 항상 절차 지향과 객체 지향을 설명하라고 하면 잘 이해가 가지 않았다.
이번 기회에 한번 정리해보기로 했다 :)

객체 지향 프로그래밍과 절차 지향 프로그래밍의 차이는?

절차 지향은 데이터를 중심으로 코드를 구현하고, 객체 지향은 기능을 중심으로 구현한다.

절차 지향 프로그래밍

someServiceCheck(){
    if(new Date().after(member.getExpirationDate())){
        //TO-DO SOMETHING...
    }
}

//Member Class의 일부
private Date expirationDate;
public Date getExpirationDate(){
    return expirationDate;
}
public void setExpirationDate(Date expDate){
    expirationDate = expDate;
}

이 코드는 회원 만료 여부를 확인하기 위해서 member.getExpirationDate()를 통해 만료일을 구한다.
someServiceCheck() 메서드가 member의 expirationDate 데이터를 사용하는 것이다.
이 시점에서 Member의 expirationDate는 someServiceCheck()가 공유하고 있다.

만약 여기서 회원의 만료일을 1년 늘려주는 코드를 작성한다고 하자. 그럼 아래와 같다.

renewContract(){
    Date date = member.getExpirationDate();
    Date renewedDate = date + 1year;
    member.setExpirationDate(renewedDate);
}

그럼 이제 Member의 expirationDate는 someServiceCheck()와 renewContract()가 공유하고 있다.

이런 식으로 코드를 작성했다면, Member는 Object라고 할 수 있을까?
그렇지 않다.

정확히 보자면 Member는 Object라기보다는 데이터를 담는 구조체에 가깝다.
someServiceCheck()와 renewContract()가 데이터를 공유하고, 이것을 기준으로 구현하는 것이 전형적인 절차지향 방식이라고 할 수 있다.

someServiceCheck()와 renewContract()와 같은 프로시저가 기능을 구현하지만, 기능의 완성은 Member의 expirationDate 데이터 공유에 있다.

하지만 데이터를 공유해 사용하게 되면 다른 프로시저에서 데이터를 변경하면서 따르는 SideEffect가 있을 수 있다.

객체 지향 프로그래밍

위에서 설명한 절차 지향 코드를 객체 지향적으로 바꿔보면 아래와 같다.

public class Member{
    private Date expirationDate;
    public boolean isExpired(){
        return new Date().after(expirationDate);
    }

    public int getRestDay(){
        //TO-DO SOMETHING...
    }

    public boolean renewContract(){
        //TO-DO SOMETHING...
    }
}

이제 만료 여부를 확인하기 위해서 expirationDate를 사용하지 않는다.
대신 Member에서 제공하는 isExpired() 메소드를 통해 확인할 수 있다.

객체지향에서 someServiceCheck()를 구현해보자면 아래와 같다.

someServiceCheck(){
    if(member.isExpired()){
        //TO-DO SOMETHING...
    }
}

앞선 절차 지향적 프로그래밍에서 데이터를 변경하는 프로시저였던 renewContract()는
객체 지향에서는 Member의 안으로 들어갔다. 데이터와 밀접하게 연결된 데이터이기 때문이다.

이렇게 함으로써 객체의 내부 구현(데이터)를 외부에 노출하지 않을 수 있다.
이것이 바로 캡슐화이다.

기능 구현을 캡슐화하면 내부 구현 변경을 조금 더 쉽게 할 수 있다.
Member객체를 사용함으로써 만료 여부 로직을 변경한다고해서 다른 코드가 영향을 받지는 않게 된다.

이 글은 객체지향과 절차지향에 대한 질문 답변을 참고하여 내가 이해한 방식으로 다시 작성해보았다.