6. 무상태 프로그래밍 : 상태 매개 변수

상태를 전달하는 것은 프로그래밍에서 매우 조심해야 할 행위이다. 이미 만들어진 상태 조차도 상태를 객체화 하는 과정을 거쳐 상태를 보지 않아도 동작이 가능한 코드를 만들려고 노력하는데 상태를 전달한다는 것은 더더욱 피해야 할 일이다.

상태를 매개변수로 다른 객체에 전달하는 것은 다른 객체에게도 상태에 따른 동작을 강요하는 행위이다. 이것이 반복되다 보면 모든 코드들이 상태에 기반하여 동작하게 될 것이다. 이곳 저곳에서 조건문이나 제어문이 남발되고, 코드는 점점 이해할 수 없을 수준의 복잡성을 가지게 될 것이다.

개인적으로는 인정하기 어렵지만, 만약 객체의 동작 중에 새로운 상태가 발생했다면, 이것은 역시 객체화를 통해 해결할 수 있다. 이미 3. 무상태 프로그래밍 : 객체의 세계 외부와의 소통에서 보여준 것처럼 상태 값을 상태별 객체로 만들고, 이것을 상태 값 대신 넘겨주는 것이다.

public class ObjectWorld {

    ITemperature temperature;

    Thermostat thermostat = new Thermostat();

    DataBase dataBase = new DataBase();

    public void receiveTemperatureValue(int temperatureValue){

        temperature = TemperatureHolder.getTemperature(temperatureValue);

        temperature.operateThermostat(thermostat);

        dataBase.insertTemperature(temperature);

    }

    public static void main(String[] args) {

        ObjectWorld world = new ObjectWorld();

        world.receiveTemperatureValue(50);

    }

}

밑줄 친 부분은 데이터베이스 쪽에 상태별 객체를 넣어주는 코드이다. 수정 이전의 코드에서는 상태별 객체 대신 온도 객체가 그대로 들어갔었다. 상태별 객체가 들어가고 나면 이미 데이터베이스에서 필요한 정보, 즉 현재 상태를 나타내는 문자열 정보는 상태별 객체가 가지고 있으므로 기능을 수행하는데 아무런 지장이 없다. 상태 변수가 발생했다고 해서 굳이 상태 변수를 다른 객체에 까지 전파시킬 이유가 없다.

상태 전파

만약 다른 사람이 만든 코드의 인터페이스가 갖가지 상태 값을 받게 되어 있고, 혹시라도 그 사람과 사이가 좋지 않다면 이것은 그 사람을 야근에 빠뜨릴 좋은 기회가 될 것이다. 만약 그 사이 좋지 않은 사람이 바로 자신이라면 야근의 늪에 빠지지 않기 위해서 인터페이스를 변경하는 편이 좋다.

개인적으로 느끼기에 상태 전파는 객체지향에서 나쁜 코드로 인식하는 거의 모든 요소를 모두 가지고 있다. 잦은 조건문 사용을 유발하여 코드의 가독성을 떨어 뜨린다. 매우 간결하고 쉬웠어야 할 코드를 조건 체크로 인하여 복잡하게 만든다. 멀티 쓰레드 환경에서라면 상태 값이 모든 객체에 동일하다고 보장할 수 없으므로 안정성에도 영향을 미친다. 상태 전파는 상태 전파를 낳게 되고, 이로 인하여 중복 코드들이 나타나게 된다. 전파된 상태를 수정하는 일은 너무나 힘든 일이다. 

나는 외부와의 소통을 담당하는 코드가 아닌데도 조건문들이 코드에 등장하는 것은 다형성의 위배나 객체지향에 대한 몰이해의 산물이라고 보는 편이다. 만약 조건문 중첩이 일어났다면 거의 확실하다. 그리고 이러한 문제가 발생하는 원인 중에서 가장 큰 것은 바로 상태 전파 때문이다. 이것을 피하고 싶다면 상태를 상태별 객체로 변경해야 한다.