[객체지향설계] 객체지향 생활체조 원칙 지키려고 노력하기

 

 

객체지향 생활 체조 9원칙

 

'소트윅스 앤솔러지'라는 책에서는 객체지향 프로그래밍을 보다 잘 하기 위해서 9가지 원칙을 제시한다. 지금까지 공부하고, 직접 사용해본 경험을 바탕으로 각 규칙을 왜 써야 하고 무엇이 좋은 지 작성해보고자 한다.

 

 

 

 

 

규칙 1. 한 메서드에 한 단계의 들여쓰기(indent)만 한다.

 

 

지금까지 코딩테스트를 포함하여 코드를 짤 때, 들여쓰기 따윈 신경쓰지 않았다. 남이 볼 코드라고는 전혀 생각하지 않아서였다. 하지만, 협업은 혼자서 하는 것이 아니다. 누가 보아도 알아볼 수 있는 코드여야 유지보수 측면에서 이점이 크다.

 

 

깊은 들여쓰기는 가독성을 좋지 못하게 만들기 때문에 가급적이면 줄이는 것이 좋다. 들여쓰기를 줄이는 것은 가독성 뿐만이 아니라, 재사용성과 디버깅에 있어서도 유리하다.

 

 

함수는 한 가지 일을 해야하며, 한 가지 일을 잘해야 한다. 또한 그 한 가지만을 해야한다.(- Clean Code) 들여쓰기가 깊다는 것은 함수가 한 가지 일을 하지 않을 가능성이 높다는 것을 의미하므로 지양하는 것이 좋다.

 

 

private void distributeCardsToPlayers() {
        OutputView.showDividePlayerCards(dealer.getDealerInfo(), players.getPlayersInfo());
        getPlayers().forEach(this::distributeCardsToPlayer);
}

private void distributeCardsToPlayer(Player player) {
        while (InputView.getCardCondition(player.getPlayerInfo().getPlayerName())) {
            player.pickCard(deck);
            OutputView.showPlayerCard(player.getPlayerInfo());
        }
        OutputView.showPlayerCard(player.getPlayerInfo());
}

 

 

 

혹여나 깊이가 깊어지더라도, 함수를 통해 일을 분리하는 것을 고려해보자. 앞서 말했듯이 하나의 함수가 한 가지의 일을 하도록 한다면 인덴트가 늘어나는 일은 줄어들 것이다.

 

 

 

 

 

규칙 2. else 예약어를 쓰지 않는다.

 

 

지금까지 코드에서 수정사항이 발생하면 else 예약어를 사용했던 적이 많다. 그러나, else 예약어를 사용하면 코드의 흐름이 비선형적으로 변한다. 이는 인간이 보기에 직관적이지 못하며 해석에 어려움을 겪을 수 있다.

 

 

public String getGrade(int score) {
    if (score >= 90) {
        return "A";
    } else {
        if (score >= 80) {
            return "B";
        } else {
            return "C";
        }
    }
}

 

 

 

위와 같은 코드가 그 사례이다. 단순히 성적 등급을 찾기위한 함수일 뿐인데, else문을 남발하면 좋게 보기 힘들다. 이를 Arrow-Anti-Pattern이라고 부르기도 한다.

 

 

그렇다면 조건문을 처리해야 하는 상황에서 어떻게 코드를 작성해야 할까? 바로 Early Return 패턴을 사용하는 것이다. 이는 만약 조건문에 부합하다면 그 즉시 리턴하는 패턴을 말한다.

 

 

위와 같은 상황에서는 아래와 같이 Early Return 패턴을 적용시킬 수 있다.

 

 

public String getGrade(int score) {
    if (score >= 90) {
        return "A";
    
    if (score >= 80) {
        return "B";
    }
    
    if (score >= 70) {
        return "C";
    }
}

 

 

 

 

규칙 3. 모든 원시값과 문자열을 포장한다.

 

 

 

원시값, 즉 _primitive_ 타입은 그 자체로 의미를 지니고 있지 않다. _int_는 그저 숫자를 나타낼 뿐이고, _char_는 단지 문자를 나타낼 뿐이다. 클래스는 이렇게 의미없는 _primitive_ 타입의 프로퍼티를 가지는 것을 선호하지 않는다. 특히나 생성자의 매개변수로 들어오는 때는 더더욱 그렇다.

 

 

예를들어, 아래와 같은 class가 있다고 해보자.

 

public class Card {

    private String cardSuit;
    private String cardRank;

    public Card(String cardSuit, String cardRank) {
        this.cardSuit = cardSuit;
        this.cardRank = cardRank;
    }

    public String getCardRank() {
        return cardRank();
    }

    public String getCardSuit() {
        return cardSuit();
    }
}

 

 

생성자의 매개변수로 _String_타입의 _cardSuit_과 _cardRank_를 받는다. 이때, 새롭게 객체를 생성해보자.

 

Card card = new Card("3", "spade");

 

 

위와 같이 코드를 작성하면, 의도한 바에 따르는 객체가 생성될까? 그렇지 않다. 클래스에서는 분명 첫 번째 인자로 카드의 숫자를 원했고, 두 번째 인자로 카드의 모양을 원했다. 하지만, 생성되는 객체는 카드의 숫자로 _spade_라는 이상한 값을 가지고, 카드의 모양으로 _3_이라는 정보를 지닌다.

 

 

안타깝게도 이러한 상황에 있어서 컴파일 타임에 에러를 체크할 수 없다. primitive 타입으로 선언했으니 그 타입에만 맞다면 에러가 없는 것으로 판별하기 때문이다. 이러한 현상을 _primitive obsession anti pattern_이라고 부른다.

 

 

그래서 나온 규칙이 바로 원시값과 문자열을 포장하라는 것이다. 즉, 원시값이나 문자열이 특수한 의미를 지닐 수 있도록 새로이 클래스 타입을 부여하면 된다.

 

 

public enum CardSuit {

    DIAMOND("다이아몬드"),
    HEART("하트"),
    SPADE("스페이드"),
    CLOBA("클로버");

    private final String suitName;

    CardSuit(String suitName) {
        this.suitName = suitName;
    }

    public String getSuitName() {
        return suitName;
    }
}

 

 

해당 상황에 대해서는 클래스가 가질 수 있는 프로퍼티가 한정적이므로 _enum_을 사용해 주었지만, 대개의 경우 _class_를 작성해주면 된다.

 

 

마찬가지로 _CardRank_에 대한 클래스 작성도 완료해주고, 아래와 같이 _Card_ 클래스를 수정해주자.

 

 

public class Card {

    private CardSuit cardSuit;
    private CardRank cardRank;

    public Card(CardSuit cardSuit, CardRank cardRank) {
        this.cardSuit = cardSuit;
        this.cardRank = cardRank;
    }

    public String getCardFullName() {
        return cardRank.getRankName() + cardSuit.getSuitName();
    }

    public String getCardRank() {
        return cardRank.getRankName();
    }

    public String getCardSuit() {
        return cardSuit.getSuitName();
    }
}

 

 

어떤가? 훨씬 더 보기 좋게 해석되며, 컴파일 타임에 타입 체크가 가능해졌다. 따라서, 이상한 값으로 객체를 생성하면 알아서 잡아 줄 수 있도록 만든 것이다.

 

 

 

규칙 4. 한 줄에 점을 하나만 찍는다.

 

 

이 규칙은 사실 "디미터 법칙"과 밀접한 연관이 있다. 디미터 법칙의 핵심은 객체 그래프에서 멀리 떨어진 객체에게 메세지를 보내는 설계는 최대한 피하라는 것이다. 점이 많이 찍혀 있는 것은 객체가 멀리 떨어진 객체를 참조한다는 뜻이며, 그러한 설계는 객체간의 결합도를 높인다. 이는 곧 캡슐화를 지키지 못하는 것과 같다.

 

player.getCard().getRank()

 

 

 

위의 상황을 살펴보자면, player 객체가 굳이 접근하지 않아도 되는 객체까지 접근해야 하는 문제점이 있다. 이로인해 객체가 자신의 역할을 다하지 못할 가능성이 높아질 수 있다.

 

 

해결방법으로는 "객체에게 메세지를 전달" 하는 방식을 사용해보도록 하자. 굳이 player객체가 Card 객체에 접근할 필요 없이, Player 객체에게 Card에 접근하여 원하는 정보를 추출하는 책임을 위임하는 것이다.

 

 

player.getCardRank();

 

 

 

단, DTO나 자료구조의 경우에는 내부 구조를 외부로 노출하는 것이 당연하므로 굳이 디미터 법칙을 신경쓰지 않는다. Java Stream API도 자기 자신의 객체를 매번 리턴하는 구조이므로 메서드 체이닝에 있어 디미터 법칙을 적용하지 않는다.

 

 

 

 

규칙 5. 줄여쓰지 않는다.

 

 

메서드 이름을 축약하고 싶은 욕구는 메서드가 하고 있는 일이 너무나도 많기 때문에 생긴다. 이는 SRP에 위반되는 사례이며, 메서드가 한 가지 일에 몰두한다면 자연스럽게 메서드 이름도 줄어들 것이다.

 

 

또한 문맥이 중복되는 케이스도 고려하여 네이밍을 결정할 수 있다. 가령, _Card_ 클래스에서 새로운 _Card_를 뽑는 함수를 짓는다고 할 때, 굳이 _pickCard()_라고 지을 필요가 있을까? 이러한 경우에는 간단하게 _Card_ 클래스의 _pick()_ 이라고 지어도 될 듯 싶다.

 

 

 

 

 

 

규칙 6. 모든 엔티티를 작게 유지한다.

 

 

마찬가지로, SRP를 지키기 위해 50줄 이상 되는 클래스와 10개 이상되는 패키지는 지양하자라는 뜻이다. 클래스가 한 가지 일을 할 수 있도록 억제할 수 있는 좋은 규칙인 것 같다.

 

 

다만, 50줄이 넘으면 큰 일 난다는 것은 아니고, 대략 그 정도 줄만 유지하면 된다.

 

 

 

 

 

 

 

규칙 7. 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.

 

 

인스턴스 변수가 많다는 것은 곧, 클래스의 응집도가 낮다는 의미이기도 하다. 인스턴스 변수가 어쩔 수 없이 많아야 하는 경우에는 객체를 협력 객체간의 계층 구조로 생각하며 설계하자.

 

 

출처 : https://williamdurand.fr/2013/06/03/object-calisthenics/

 

 

 

 

 

 

 

규칙 8. 일급 콜렉션을 쓴다.

 

 

이전에 배웠던 모든 원시값과 문자열은 포장한다는 규칙과 유사하다. 일급 콜렉션은 Collection을 Wrapping하면서 그 외의 다른 멤버 변수는 존재하지 않는 클래스를 말한다.

 

 

[Java] 일급 컬렉션과 사용해야 하는 이유에 대하여

 

 

비즈니스에 종속적인 자료 구조를 생성할 수 있고, 불변성을 보장, 상태와 행위를 한 곳에서 관리하여 상태가 흩어지는 것을 막을 수 있으며, 이름을 검색할 수 있는 등 다양한 이유에서 일급 콜렉션을 사용한다.

 

 

 

 

 

 

규칙 9. getter, setter를 쓰지 않는다.

 

 

이 규칙은 이전에 "메세지를 객체에게 전달해라"라는 것과 연관이 깊다. 객체는 스스로가 해야하고, 할 수 있는 책무를 다해야 한다. 자신의 책임에 따라 할 수 있는 일을 굳이 밖에서 getter와 setter를 통해 가져와 다른 객체가 하도록 놔두면 안된다.

 

 

이에 따라 객체가 가져야 하는 책임의 경계를 최대한 응집도가 높도록 설계하는 것이 바람직할 것이다.

 

 

물론 목적에 따라서 단순히 객체의 상태를 가져와 출력하는 로직에 있어서는 굳이 getter를 제한할 필요는 없다고 본다. 하지만 그 결과값을 통해 어떠한 결정을 내리는 것은 올바르지 않다.

 

 

현 객체의 상태에 대한 판단은 그 객체가 스스로 지어야 한다.

 

 

 

 

 

 

 

 

References

https://williamdurand.fr/2013/06/03/object-calisthenics/

https://hudi.blog/thoughtworks-anthology-object-calisthenics/

https://velog.io/@marisol/%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5-%EC%83%9D%ED%99%9C%EC%B2%B4%EC%A1%B0%EC%9B%90%EC%B9%99