[ Object-Oriented Programming ] 객체지향 프로그래밍

객체 Object = 물체, 속성(property)과 행동(method)를 갖고 있는 현실세계의 사물 or 물체 or 대상 

객체지향프로그래밍 이란? Object Oriented Programming

객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.

 

실제 세계의 사물을 프로그래밍으로 옮겨와 이를 객체로 보고 해당 객체의 특징과 기능을 모델링하여 프로그래밍하는 기법으로 유연하고 변경이 용이하다. ( 재사용성 ) ex) Java

 

= 컴포넌트를 쉽고 유연하게 변경하면서 개발이 가능함 

---

1. 객체지향프로그래밍의 특징

1) 다형성 Polymorphism

서로 다른 클래스의 객체가 같은 메시지를 받았을 때 각자의 방식으로 동작하는 것으로 흔한 예시로 사용되는 자동차에 빗대어 설명해보자. ( 상속과 연계하여 설명 )

 

여기 drive method를 갖고 있는 하나의 부모클래스인 Car이 있다.

그리고 Car class의 dirve method를 상속받아 재정의한(Override) 자식 class인 Bmv와 Kn class가 존재한다. 

public abstract class Car{
   public abstract void drive();
}

public class Bmv extends Car{
   @Override
   public void drive() {
      System.out.println("Bureung~"); // Bmv 부릉 ~
   }
}

public class Kn extends Car{
   @Override
   public void drive() {
      System.out.println("Boowaang~"); // Kn 부앙 ~
   }
}

 

두 자식 클래스는 부모의 method를 상속받아 drive 기능을 수행하지만 동작 방식(구현방법)은 다르다.

여기서 말하는 다형성이란 drive라는 동작 자체는 바뀌지 않지만 동작 방식은 각 자식 클래스마다 다르게 구현이 가능한 것을 말한다.

 

Car c = new Bmv();
c.drive(); // 부릉~

 

다형성을 사용하면 어떤 클래스 객체가 참조되는지와 무관하게 개발할 수 있다. 즉, 코드를 유연하게 변경하거나 새로운 클래스가 추가(확장)되더라도 코드는 영향을 받지 않는다. 

 

ex) drive( )라는 메서드(기능, 역할)를 구현하는 방법은 상속을 통해 새로운 자식 class로 구현된다.

따라서 추상 class Car( )의 dirve( ) method는 변경할 필요가 없으며, User(Client)는 Car( ) class를 사용 시 dirve( )의 구체적인 구현방법을 몰라도 dirve( )를 사용할 수 있다. 

 

Java의 다형성은 기능과 구현이 구분되기 때문에 코드의 유연성과 재사용성을 높이는 쪽으로 객체를 설계할 수 있다.

 

그래서 객체 설계 시 역할과 구현을 분리해야하며, 역할(인터페이스)를 먼저 부여해야합니다. 그 이후 해당 역할을 수행하는 구현객체를 만드는 것이다.

 

    • 역할 : 인터페이스

    • 구현 : 인터페이스를 구현한 클래스, 구현 객체

 

즉, 클라이언트는 구현 대상의 내부구조를 몰라도 되며, 내부구조가 변경되어도 영향을 받지 않습니다. 또한 대상 자체를 변경해도 영향을 받지 않는다.  ** Client 변경 없이 Server의 구현 기능을 유연하게 변경 가능 **

 

이제 알아볼 객체지향 설계원칙 SOLID도 이 다형성이라는 개념에서 출범했다고 볼 수있다.

2. 객체 지향 설계 5원칙 SOLID 

SRP 단일 책임 원칙 (Single Responsibility principle)

말 그대로 객체(클래스)는 하나의 책임만 가져야한다는 의미이다.  ( 책임이란 해야하는 것을 잘 할 수 있는 것 )

좋은 설계는 시스템에 새로운 변경 또는 요구사항이 있을 때 기존 코드가 영향받는 부분이 적어야 한다.

하지만 책임이 많아질수록 클래스 내부에서 코드끼리의 결합성이 높아져 다른 역할을 수행하는 코드끼리 변화를 일으킬 수 있으며 문제 발생 시에도 테스트해야하는 범위가 넓어진다. (산탄총 수술같은)

따라서 책임분리를 잘해야한다. 

OCP 개방 폐쇄 원칙 (Open/Closed principle)

기존코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계되어야 하는 것을 말한다. ( 코드 확장시에는 Open, 변경에는 Closed )  변하는 것과 변하지 않는 것을 구분하여 변경이 있더라도 기존의 클래스가 영향을 받지 않게 설계해야한다.

이는 인터페이스에서 구체적인 출력매체를 캡슐화 encapsulation 하여 처리해야한다. 

public class MeteorologicalAdministration { // 기상청 
   public void weatherNotification(){
      if( getTemperature() > 5 ){
      		temperatureCheck(...)
            ...
      }
   }
   private void temperatureCheck(){ ... } // 온도체크
   private int getTemperature(){ return ... }; // 온도    
}

 

위의 코드는 OCP가 지켜지지 않고있다. 무엇이 문제일까?

온도체크와 온도 메서드는 날씨에 따라 변할 가능성이 있다. ( 온도가 몇도인지에 따라서 체크결과도 달라지기 때문에.. )

이는 기존 코드에 영향을 줄 수 있으므로 해당 메서드는 분리해 줄 필요가 있다. 

 

public interface Checker { //인터페이스 생성
   public default void temperatureCheck(){ } 
   public int getTemperature(); 
}

public class Temperature implements Checker{ //온도 전용 클래스

   @Override
   public void temperatureCheck() { // 온도체크
      Checker.super.temperatureCheck();
   }

   @Override
   public int getTemperature() { // 온도
      return 0;
   }
}

 

이처럼 Checker 인터페이스를 생성하고 온도체크를 하는 클래스에 Checker를 구현한다면 다른 메서드가 추가되더라도 이를 이용하는 클라이언트 클래스는 영향을 받지 않는다.

 

+  Spring에서는 다형성에 기반한 OCP 원칙을 지키기 위해서 DI, Ioc에 대해 알아두면 좋다.

LSP 리스코프 치환 원칙 (Liskov subsitution principle)

부모클래스와 자식클래스 사이의 행위가 일관성이 있어야 한다. ( 행위의 일관성 )

즉, 자식 클래스의 instance가 부모 클래스의 instance를 대신할 수 있어야 한다. 

따라서 일관성있는 코드를 작성하기 위해서는 부모클래스에서 상속받은 메서드를 자식클래스에서 오버라이드하지 말아야한다. ( 재정의하지 않고 확장만 수행해야한다. )

ISP 인터페이스 분리 원칙 (Interface segregation principle)

클라이언트에 특화된 인터페이스를 만들어야 한다. 즉, 클라이언트 관점에서 인터페이스가 특화되도록 분리시켜야한다.

( 클라이언트 관점에서 클라이언트 자신이 이용하지 않는 기능에는 영향을 받으면 안된다. )

인터페이스가 명확히 분리되면 대체 가능성이 높아진다.

DIP 의존 관계 역전 원칙 (Dependency inversion principle)

의존관계를 맺을 때 변화가 자주 일어나는 것보다 변화가 거의 없는 것에 의존해야한다.

= 추상화(역할)에 의존하고, 구체화(구현)에 의존하면 안된다.

즉, 고수준 모듈(변화가 거의 X것 )이 저수준 모듈(고수준 모듈을 구현하기 위해 필요한 하위 기능의 실제 구현, 쉽게 변하는 것)에 의존해서는 안된다.

 

인터페이스는 변하지 않는것, 구현하는 클래스는 변하는 것으로 구분한다.

 

다시 한 번 강조하자면 변하지 않는 인터페이스에만 의존해야하고 변화가 잦은 구현 클래스에는 의존하면 안된다.

구현클래스에 의존하면 DIP 위반에 속한다. 

---

이처럼 객체지향 프로그래밍을 하기 위해서는 지켜야하는 사항들이 많다.

하지만 객체지향 프로그래밍을 함으로써 코드의 가독성과 재사용성 유연성이 높아지는 것은 확실하다.

 

이러한 원칙을 잘 지킬 수 있는 환경을 지원을 해주는 것이 바로 스프링 프레임워크이다. 

때문에 앞으로 스프링에 대해 더 구체적으로 공부할 생각이다. 

 

이상 오늘은 객체지향 프로그래밍에 대해 공부해보았다.  

---

UML 표기법 

 

P.S : 부족한 부분은 계속해서 수정하겠습니다. 🥰