정적 팩토리 메서드를 알아보다가 느낀 점

책 Effective Java를 오랜만에 꺼내서 읽었다. 궁금한 것이 생겼을 때, 그 키워드가 책에 있으면 가끔 펼쳐서 보는 책이었는데, 특별한 계기 없이, 그냥 정독을 해보고 싶었다.

가장 먼저 나오는 아이템은 ‘생성자 대신 정적 팩토리 메서드 사용을 고려하라’인데, 전에도 읽어봤지만, 오랜만에 읽는 것이라 그런지 여러 가지 의미로 새롭게 받아들여졌다. 이 책 자체가 엄청 유명한 책이고, 이 책의 키워드만 검색해도 많은 사람들이 정리해놓은 글이 많아서, 이것의 내용을 정리할 생각은 없다. 어쨌든 내용을 이해하려고 글을 이것저것 읽어보는데, ‘객체 지향적 프로그래밍’에 대한 설명들이 역시나 조금씩 포함되어 있었다. 어떤 설명을 보거나 들어도 늘 뜬구름을 잡는 것 같았던 개념이었는데, 뭔가 느껴진(?) 것이 생겨서 생각을 짧게 정리해보려고 한다.

예전에 들었던 김영한님의 강의에서, 객체 지향적으로 프로그래밍한다는 것은 협력하는 객체들의 공동체를 만드는 방향으로 프로그래밍하는 것이라는 설명을 들은 적이 있다. (기억에 의존하는 것이라 워딩이 정확하지 않을 수도 있다.) 그것이 무슨 말인지 궁금해서 추천해준 책 ’객체 지향의 사실과 오해‘를 조금 읽어봤었는데, 지금 기억나는 것으로는 객체를 한 명의 사람처럼 여기고, 프로그램은 객체들이 ’사람 같은‘ 상호작용을 이루며 작동하는 것이라고 했다. 정적 팩토리 메서드를 사용하는 것, 그것을 통해 클래스의 캡슐화 등은 객체들의 ‘사람 같은’ 상호작용을 위한 것들로 보인다. 그러면 ‘사람 같은’ 상호작용을 이루도록 만들어야 하는 이유가 있을까?

가장 직관적으로 보이는 것은 코드를 이해하기 쉽기 때문이라는 이유인 것 같다. 어쨌든 코드를 이해하고, 짜는 것은 사람이니, 아무래도 기계가 드륵드륵 작동하는 것을 이해하는 것보다 ‘사람 같이’ 상호작용하는 것을 보는 것이 직관적으로 이해하기가 쉽다고 생각했던 것은 아닐까? 가령 객체 A, B가 있을 때, ’A의 정보를 꺼내서 일시적으로 어딘가에 저장해둔 뒤, 객체 B에 그 정보를 추가해서 B의 정보를 업데이트한다‘는 것을 ’A가 B에게 정보를 준다‘라고 하면 설명하기 편한 것처럼..? 사람이 일반적으로 기계처럼 생각하지는 않을 것이기 때문이다.

그래서 ’객체 지향적 프로그래밍‘이라는 사상을 만든 사람들은 더 많은 사람들이 프로그래밍에 쉽게 기여하는 것을 바라지 않았을까 하는 상상을 해봤다. 물론 그것에 대한 기계적인 효율이나 이외의 장점들에 대해서도 더 알아보고 이해해야겠지만, 개인적인 느낌 하나를 얻은 것 같다. 아무튼, 최근에 코딩을 하면서 정적 팩토리 메서드는 전혀 사용하지 않았는데, 지금부터라도 프로젝트에든 알고리즘 풀이에든 써보면서 좋은 점, 나쁜 점을 느껴봐야겠다. 글로만 읽어서는 제대로 이해할 수 없으니.