절차지향 vs 객체지향(객체지향 3대요소)

 

■ 절차지향

1) 정의 :

> 순차적인 처리가 중요한 프로그래밍 방식

- 컴퓨터 작업 방식과 비슷

- 데이터 위주의 thinkig

 

2) 장단점 :

> 장점

   - 컴퓨터의 처리구조 방식과 비슷해 실행속도가 빠름

> 단점

   - 유지보수 어려움

   - 실행순 변화에 따른 동일 결과 보장이 어려움

   - 디버깅이 어려움

 

 

■ 객체지향

1) 정의 :

> 실제 세계를 모델링하여 소프트웨어를 개발하는 방식.

- "작동 방식"을 고려하여 전체를 개발하는 방법

- 데이터 + 절차를 한 동작의 덩어리로 묶어서 생각

 

2) 장단점 :

> 장점

   - 코드 재활용성

   - 코딩이 절차지향보다 쉬움

   - 디버깅 용이

> 단점

   - 처리속도 느림

   - 설계에 많은 시간 소요

 

3) 객체지향 3대 요소

1. 캡슐화

• 캡슐화란 관련된 데이터와 알고리즘(코드)이 하나의 묶음으로 정리된 것으로써 개발자가 만들었으며, 관련된 코드와 데이터가 묶여있고 오류가 없어 사용이 편리
• 데이터를 감추고 외부 세계와의 상호작용은 메소드를 통하는 방법(aka. encapsulation)
  • 메소드: 메시지에 따라 실행시킬 프로시저로서 객체지향 언어에서 사용되는 것. 객체지향 언어에서는 메시지를 보내 메소드를 수행시킴으로써 통신(communication)을 수행

 

2. 상속

• 상속은 이미 작성된 클래스를 이어 받아서 새로운 클래스를 생성하는 기법으로 위에서 말한 기존 코드를 재활용해서 사용하는 것을 의미
• 재사용성이 높아서 효율적

 

3. 다형성

• 다형성이란 하나의 이름(방법)으로 많은 상황에 대처하는 기법
  == 프로그램 언어 각요소들(상수, 변수, 식, 객체, 메쏘드.. 등)이 다양한 자료형에 속하는 것이 허가되는 성질
• 개념적으로 동일한 작업을 하는 함수들에 똑같은 이름을 부여할 수 있으므로 코드가 더 간단해지는 효과
  
  • Overloading, Overriding, Functional interface 등등...
    참조 : 우아코스
    참조 : korshika.tistory.com/62

 

Overriding / Overloading 차이

 

> 위의 특성으로 생기는 객체지향의 장점

•  신뢰성 있는 소프트웨어를 쉽게 작성할 수 있다. (개발자가 만든 데이터를 사용하기에 신뢰할 수 있다.)
•  코드를 재사용하기 쉽다.
•  업그레이드가 쉽다.
•  디버깅이 쉽다.

 

 

■ 절차지향 vs 객체지향 비교

1) 절차지향

someServiceCheck() {
    ...
    if (new Date().after(member.getExpirationDate()))) { ... } 
    ...
}



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


renewContract() { Date date = member.getExpirationDate(); Date renewedDate = ... 
// date에 1년 더한 값 member.setExpirationDate(renewedDate); }

 

> Member의 expirationDate를 공유하는 함수는 someServiceCheck()와 renewContract()로 여러개가 존재

  + 이미 객체 말고 절차지향적으로 구현되어있음

 

> Member는 객체라기 보다는 데이터를 담고 있는 구조체에 가까움

   즉, 두 함수가 데이터를 공유하고 이를 기준으로 구현하는 전형적인 절차지향 방식

 

> 만료 여부를 확인하는 코드가 많아지거나 만료 데이터를 변경하는 코드가 많아질수록

    expirationDate라는 데이터를 중심으로 함수를 구현

 

※ 이런 절차지향식의 문제점

- Example : 서비스 만료의 상태표현을 위해 expirationDate에 null을 할당 → 데이터를 공유하는 모든 함수가 영향을 받음

- 기존 코드에 null 검사를 추가해야 하고, null이면 에러가 아니라 만료일이 없도록 로직을 수정 등등...

   refund() 함수와 기타 만료일을 중심으로 중요 로직을 수행하는 코드들이 영향을 받음, 로직 개선의 문제점이 존재

---

2) 객체지향

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


    public int getRestDay() {
        ... //
    }


    public boolean renewContract() { // 데이터와 관련된 일부 기능이 객체로 들어옴
        .... //
    }
}

// 만료 확인을 위한 부분, 외부 로직
someServiceCheck() {
    ...
    if (member.isExpired())) { ... } 
    ...
}

> 계약 갱신 기능( renewContract() )과 같이 일부 기능은 Member 안에 포함

- 데이터와 밀접하게 연결된 기능을 데이터와 같은 객체의 기능으로 추가

- 이렇게 객체의 내부 구현(특히 데이터)를 외부에 노출하지 않을 수 있고, 이를 캡슐화라 함

 

> 기능 구현을 캡슐화하면 내부 구현 변경을 조금 더 용이하게 할 수 있음

- Member 객체를 사용함으로써 만료 여부 로직을 변경할 때 다른 외부 코드는 영향을 받지 않음

- 무한대로 사용할 수 있는 사용자의 만료 데이터를 확인하는, Member 객체를 확인하는 코드는 isExpired() 라는 기능을 사용

- 만료 데이터 저장 방식 때문에 영향을 받는 코드는 Member 객체 뿐이므로 변경이 수월

  (Member 안의 데이터만 신경쓰면 되고, isExpired 만 수정하면 private 데이터를 외부에서 확인하지 않고도

   기능 수정을 통해 결과를 사용하는 외부 부분을 분리한체 기능을 수정할 수 있음)

 

※ 핵심은 데이터 중심이 아닌 기능 중심으로 구현

- 여러 함수가 데이터를 공유하는 방식이 아니라 특정 함수가 다른 함수를 사용하는 방식

- 데이터 공유를 적절히 제한하면 캡슐화 효과를 얻을 수 있음

 

---

참조 :

brownbears.tistory.com/407

절차지향 VS 객체지향