잘 만들어진 코드

  잘 만들어진 코드란 요구사항을 정확히 만족하는 코드이다. 그런데 현실에선 요구사항들이 끊임없이 변하기 때문에 만족시키기란 쉽지 않다. 결론적으로 변화하는 요구사항을 안정적으로 잘 동작시키는 코드가 잘 짠 코드라고 말 할 수 있다. 그런 의미에서 객체지향이 관심의 대상이 되고 각광받는 이유는 구조적 프로그래밍으로 대변되는 기존의 방식들에 비해 요구사항을 보다 유연하고 안정적으로 만족시키기 때문이다.

개발하기에 가장 좋은 방법은 수준 높은 개발자들 여럿이서 서로 원하는 수준에서 활발히 커뮤니케이션을 하면서 일하는 것이다. 하지만 우리가 일하는 현실을 돌아보자. 회사 내에서 모든 개발자가 같은 수준에서 개발할 수는 없다. 중급 개발자와 초급 개발자가 똑같은 수준에서 개발을 할 수는 없을 것이다.

통일성이나 수정의 용이성 같은 말은 사실 아주 쉬운 의미이다. 함수들의 공통점을 묶고 나아가 클래스간의 공통점을 묶고 컴포넌트간의 공통점을 묶고 이렇게 잘 묶어서 정리하다보면 그게 바로 객체지향 프로그래밍이고 컴포넌트 프로그래밍이다. 물론 프로그램의 크기가 커질수록 묶는 개념도 커지고 요구사항이나 제품의 방향에 따라 고려해야할 것도 많아지지만 언제나 기본에 충실하라. 공통점 묶기가 객체지향의 초석임을 잊지 말자.

공통점 묶기와 조금만 알기는 객체지향 언어에서 상속, 다형성, 캡슐화보다 더 중요한 개념이다. 공통점을 묶고 조금만 알기 위해 노력하다 보니 상속, 다형성, 캡슐화가 필요하게 되고 더불어 추상화(Abstaction), 일반화(Generalization)라고 세분화(Specialization)도 이루어지는 것이다.

  모든 이론이나 개념은 경험적 발전과 필요에 의해 탄생한 것이고 왜 필요하게 된 것인지를 이해하는 것이 단순히 그 정의와 내용을 공부하는 것보다 훨씬 중요하다. 객체지향의 결정판이라고 알려진 디자인 패턴을 어렵게 느끼는 이유 중 하나는 경험의 산물로 보지 않고 공부해서 익혀야 되는 것으로 인식하기 때문이다. 또 캡슐화에 관해 모든 변수를 반드시 private으로 선언해야 한다는 법이 있는 것은 아니다. 모든 개발자가 어떤 변수는 직접 접근하고 어떤 변수는 접근하면 안된다는 것을 안다면 왜 안되겠는가? 하지만 현실적으로 모두가 똑같은 지식과 레벨에서 개발할 수 없으므로 언어가 이런 점들을 지원해주는 것이다.

  언어는 개발자의 실수를 언어가 최대한 막아주어 생산성을 높이는 방향으로 발전한다는 점을 기억하자.

  모든 클래스는 하나의 책임만을 가진다.

  "이 클래스가 무슨 일을 하는 클래스입니까?" 라는 질문에 "이 클래스는 A라는 일을 합니다." 라고 간단히 대답할 수 있어야 한다. "이 클래스는 맑은 날엔 A라는 일을 하고 비오는 날엔 B라는 일을 하고 안개 낀 날에는 C라는 일을 합니다."라고 대답한다면 클래스의 의미를 정확히 파악할 수 없다. 우리가 클래스를 만드는 이유가 관련된 데이터를 하나로 묶어서 이해하기 쉽도록 하는 것인데 클레스가 너무 많은 책임을 가지면 이해하기가 쉽지 않다. 만약 이렇게 여러가지 책임을 가져야 한다면 클래스를 나눌 것을 강력 추천한다. 객체지향에서 제일 어려운 일 중 하나는 관련된 정보로만 클래스를 구성하는 일이다. 변수 하나, 함수 하나를 넣을 때 "과연 이 기능이 이 클래스에 들어가는 것이 맞을까?"에 대해 고민해야 한다. 클래스 하나가 이일 저일 다하게 되는 신(GOD) 클래스가 된다면 그건 그냥 거대한 코드 덩어리일 뿐 어떠한 방법론의 코드도 아니다.

  클래스는 하나의 책임만을 가진다라는 대명제를 중심에 놓는다면 상속으로 이루어진 클래스 트리 전체는 하나의 책임으로 묶인다고 볼 수 있다. 이런 이유로 Java는 단일 상속만을 지원하지만 부족함이 없는 것이다(Java의 상속은 extends 키워드를 사용한다).

  인터페이스 상속(Java에서는 implements)에 대해 알아보자. 앞서 클래스는 하나의 책임을 가짐과 동시에 상속받는 클래스 트리는 하나의 책임으로 묶여진다고 이야기 했다. 하지만 C++의 다중 상속이나 Java의 인터페이스 구현은 필요하기 때문에 존재하는 것이다. 여기서 혼란이 올 수 있다. 두 클래스에서 상속을 받으면 상속받은 자식 클래스는 두 개의 책임을 지는 것이 되니 하나의 책임을 지는 룰에 위배된다고 생각할 수 있다. 하지만 클래스 상속과 인터페이스 상속은 그 의미가 분명히 다르다. 클래스 상속은 분명 부모와 자식간에 같은 책임을 가지지만 작동하는 형태가 다른 것을 의미한다. 반면 인터페이스 상속은 기능을 추가하거나 클래스 간의 통신을 하기 위한 방법을 제공한다는 의미이다.

  모든 클래스는 하나의 책임만을 가지고 이런 클래스들이 서로 통신하면서 동작하는 것이 객체지향 프로그래밍이다. 이 때 클래스들이 만나는 방법(사전에서 경계면, 접점으로 표현한 부분)을 인터페이스라고 부른다.   Java에서는 모든 함수가 가상 함수(Virtual Function)로 동작하므로 virtual 키워드를 붙이지 않아도 된다. 어쨌든 Java에서는 class 키워드 대신에 더 의미가 분명한 interface 키워드를 제공한다.

  객체지향에서는 클래스 하나를 작성하는 것보다 클래스 사이의 관계를 작성하는 것이 더 중요하다. 클래스 자체가 문제라면 문제 범위를 클래스로 좁힐 수 있지만 클래스 사이의 관계가 문제가 되면 관련된 모든 클래스의 동작 방식이 문제가 되기 때문이다.

  완전한 클래스와 인터페이스 사이에 있는 개념이 추상 클래스이다. 추상 클래스는 인터페이스 개념을 잘 이해하였다면 쉽게 이해할 수 있다. 추상 클래스는 그 이름에서 알 수 있듯이 클래스의 한 종류이다. 하지만 클래스 전체를 다 구현하지 않고 자식 클래스에서 구현의 일부를 위임하기 때문에 실제(Concrete) 클래스라고 부르지 않고 추상(Abstract) 클래스라고 부르는 것이다. Java에서는 추상 클래스를 위한 키워드로 abstract라는 키워드를 지원하여 의미를 더욱 분명히 하였다. 엄밀히 따지면 인터페이스를 작성할 때 구현을 하지 않는 것을 원칙으로 한다. 하지만 인터페이스를 잘 정의하지 못한 상황에서 인터페이스 구현을 하다 보면 자식 클래스들에서 중복으로 구현되는 기능들이 있다. 이런 기능들의 공통점 묶기를 써서 부모 클래스, 즉 인터페이스에 일부 구현하는 경우가 있다. 이 때 java에서는 명백히 인터페이스를 추상 클래스로 변경하도록 컴파일러가 요구한다. 정석대로라면 추상 클래스는 상속 계층에서 책임을 지는 부모 클래스로만 만드는 것이 좋고 인터페이스는 다른 클래스와의 관계만을 기술하므로 구현이 없는 것이 좋다. 하지만 개발을 하다 보면 편의상 인터페이스에 일부 구현을 할 수 있으며 이때는 구현이 있다고 추상 클래스로 보는 것보다는 원래 목적대로 인터페이스로 보는 것이 타당하다.

 

정리

  객체지향 프로그래밍의 기본 단위는 클래스이다. 모든 클래스는 단 하나의 책임을 가지는 것이 좋다. 레고 부품을 조립하는 것처럼 각자의 책임을 가지는 클래스를 우리가 어떻게 조립하는가에 따라 결과물이 달라진다. 객체지향을 통한 재사용의 강력함은 이 분해와 조립에 있다고 할 수 있다. 클래스를 조립할 때 서로 다른 책임의 클래스를 연결하는 방법은 클래스들을 직접적으로 연관시켜서 할 수 있지만 이 방법은 결합도와 복잡도를 증가시키므로 좋은 방법이 아니다. 결합도와 복잡도는 클래스를 연결시켜주는 인터페이스 사용을 통해 낮출 수 있다. 한편 결합도와 복잡도를 낮춘다는 의미는 확장성을 높인다는 의미로 해석할 수 있다. 인터페이스도 클래스 사이를 연결시켜 주는 책임을 가지는 또 다른 클래스의 형태라고 할 수 있다.

이 글은 스프링노트에서 작성되었습니다.