[Java] 객체지향을 해치지 않으면서 정적 메서드를 사용할 수 있을까?

📚 정적 메서드 사용 기준을 찾아서

코드를 작성할 때면, 불쑥 불쑥 정적으로 메서드를 선언하고 싶어진다.

그러나 뚜렷한 단점에 대한 인식 없이, 사용에 대한 기준 없이는 사용하기가 두려워 나의 기준을 세워보고자 여러 아티클들을 읽어 보았다. 그 중에서도 가장 좋았던 세 가지를 정리해보고, 나의 기준을 생각해보고자 한다.

---

📝 1. Why are static embers and methods bad for object-oriented design?

Why are static embers and methods bad for object-oriented design?

 

위 아티클에서 주로 이야기하는 것은, ⚡️ 객체지향의 패러다임과의 불일치다.

 

객체지향은 주로 다음과 같은 포인트들을 갖는다.

 

1. 메시징

OOP 의 객체들은 다른 객체들과 메시지를 통해 소통해야 한다. 그러나 static 메서드들은 어떤 객체에도 속하지 않기에 객체지향 패러다임 자체에 어긋난다는 것이다. 사실상 이렇게 정의된 메서드들은 메서드라기보다는 일종의 'procedure(절차)' 에 가깝다고 이야기한다.

 

2. 동적 디스패치 및 다형성

static 키워드를 사용하면 구현체를 런타임에 선택할 수 있는 객체지향의 추상화를 활용할 수 없다는 것이다. static 을 사용하면 구현체가 고정되어 버린다고 이야기했다.(fixed by using polymorphic behavior)

 

글에서 이야기하는 static 을 사용하기 위한 가장 적합한 상황들은 다음과 같다.

 

1. 완전히 재사용되는 코드를 분리하는 경우

2. 어떠한 인스턴스와도 연관되지 않고 특정 구현체에 완전히 종속되는 경우

 

📝 2. Use Cases for Static Methods in Java

위의 글에서는 정적 메서드의 적절한 유스 케이스들은 다음과 같다고 이야기한다.

 

1. standard 한 행동을 할 때

Math.max(a,b);

 

위와 같이 너무나도 자명하게 더 큰 값을 반환하는 것이 기대되는 경우를 말하는 것이다.

 

2. 공통적으로 사용되는 경우

여기에서 공통적이라는 것의 의미는 첫째로, 특정 도메인에 묶이지 않고 둘째로 특정한 상태를 갖지 않는 경우들을 이야기한다.

 

3. 객체의 상태를 변경하지 않는 경우

 

4. 순수함수인 경우

여기서 순수함수는 파라미터가 전달된 그대로 반환되는 경우이다. 즉, 아무런 값의 변화가 없기 때문에 어떠한 side-effect 도 발생하지 않는다.

 

public class Logger {
    private static int logCount = 0;

    public static void log(String msg) {
        logCount++;
    }
}

 

위와 같이 특정 상태를 변경하는 것은 순수함수가 아니다.

 

public class MathUtil {
    public static int square(int x) {
        return x * x;
    }
}

 

그러나 위와 같이 특정 값을 변환해 반환하기만 하는 것은 순수 함수이다.

 

📝 3. When to Make a Method Static in Java? Example

When to Make a Method Static in Java? Example

 

위의 글에서는 static 메서드를 사용해도 되는 경우에 대해 다음과 같이 이야기한다.

 

1. 순수함수이거나 인스턴스 변수를 활용하지 않는 경우

 

2. 인스턴스 생성 없이 메서드를 호출하고자 하는 경우

 

3. 파라미터를 통해서만 작업 하는 경우

 

4. 유틸 메서드들을 활용하는 경우

 

5. 클래스들의 계층 전체에서 동일하게 사용되는 경우

예를 들어, equals 메서드의 경우에는 각 객체마다 고유한 방식이 있기에 정적으로 선언해서는 안되는 대표적인 메서드라고 이야기한다.

 

🚀 나만의 기준

여러 자료들을 읽으며 내가 느꼈던 결론은 객체 지향적 맥락에서 ‘객체 간 협력’이나 ‘다형성’을 활용하지 않는다면, 정적 메서드도 적절한 선택이 될 수 있다는 것이다.

 

첫번째 아티클에서 이야기했듯, 객체지향의 객체들은 메시지를 주고 받아야 하고 다형성을 활용 할 수 있어야 한다.

 

만약 클래스 게층 전체에서 동일한 방식으로 동작할 것이 명확한 경우, 즉 다형성을 활용하지 않아도 된다면 이는 정적으로 선언해도 된다. Math 의 max 메서드는 전 계층을 아울러 같은 동작을 할 것임이 너무나 명확하다. 그러나 Student 의 goToSchool 이라는 메서드는 학생마다 등교 방식이 다를 수 있다. 어린이집 학생은 유모차를 타고 올 수도 있고, 기숙사 학생은 걸어서 올 수도 있다. 이러한 상황에서는 정적으로 메서드를 선언해서는 안된다.

 

객체지향과 절차지향의 가장 큰 차이점은 객체가 자신의 상태를 관리하는 것이다. 절차지향에서는 데이터를 외부에서 직접 조작하는 경향이 있지만, 객체지향에서는 객체가 자신의 상태를 스스로 캡슐화하고 책임을 갖는다.

 

이와 같이 객체지향의 '객체'가 의미 있기 위해서는 특정 상태에 대한 처리가 필요하거나 외부로 공개하지 않아야 하는 상태가 있는 경우가 적합하다고 생각한다. 그러나 메서드가 아무런 인스턴스 변수와 연관성이 없는 경우에는 정적 메서드를 사용해도 된다고 결론을 내렸다.

 

더 나아가, 메서드를 통해 너무나도 자명하게 어떤 행동을 할지 뻔히 예상되는 경우에는 캡슐화의 필요성이 상대적으로 낮아진다. Math 의 max 는 어떤 행동을 할지 뻔히 보인다. 그러나 Student 클래스의 goToSchool 이라면? 구체적으로 어떤 방식을 택하는지 알 수가 없다. 이러한 경우에도 정적 메서드의 사용이 가능하다고 생각했다.

 

또한 동시에, 기존의 협력 구조를 깨뜨리지 않는 방향성으로 설계해야 한다. 그렇기에 정적 메서드는 어떠한 상태도 변경하지 않는 순수함수여야 한다고 생각했다. 순수함수가 아니라면 다른 객체와의 협력이 잘 동작하고 있는 객체지향 세계에서 정적 메서드가 정의된 클래스의 외부로, 다른 객체에까지 영향을 끼칠 수 있기 때문이다. 즉 영향의 범위를 클래스 내부로 한정짓는 것이다.

 

결론적으로,

 

1. 모든 클래스의 계층에서 동일하게 동작하는 경우

2. 표준적으로 동작하는 경우

3. 인스턴스 변수와 연관성이 없는 경우

4. 순수함수인 경우

 

라고 결론을 내렸다!