클래스와 메서드는 원래 작다

osul_world 2022. 11. 8. 16:22

728x90

테스트 주도 설계를 학습한 후, 막상 테스트를 진행하려 하니, 기존에 작성한 클래스는 여러 기능이 섞여있고 서로 강한 의존성을 가져, 테스트는 물론 문제가 발생했을 때 파악과 수정이 쉽지 않았습니다

때문에, 클래스 설계에 대한 깊은 고민과 학습이 필요하다는 생각을 하였고, 클래스는 어떻게 설계해야 하는지? 내가 무엇을 놓치고 있었는지? 정리해 보려고 합니다

*클래스와 메서드를 간단하게 클래스로 칭하겠습니다

클래스 설계에 가장 중요한 원칙들은, 첫째도 작게, 둘째도 작게이다

작게 쪼개어진 클래스는 극도로 단순하여 순식간에 역할을 이해할 수 있게 하고, 체계적인 관리와 추상화 그리고 유연성과 재 사용성을 보장한다

클래스는 하나의 책임을 이름에 나타내야 합니다, 따라서 명확한 하나의 이름이 떠오르지 않느다면 여러 책임을 떠안기진 않았는지 점검할 필요가 있습니다

단일 책임 원칙은 깨끗하고 체계적인 소프트웨어에서 더욱 중요한 개념입니다만, 간과하기 쉬운 부분인 것 같습니다

자신이 설계한 클래스가 정말 하나의 책임만 가지고 있는지? 항상 의심해야 합니다

규모가 어느 수준에 이르면 시스템은 복잡해진다, 이런 복잡성에 대응하기 위해 체계적인 관리는 필수이고 개발자가 어디에 무엇이 있는지 명확하게 파악할 수 있어야 합니다

이를 위해 개발자가 우선시 해야하는 것은 모든 클래스가 각자 맡은 하나의 책임을 수행하고, 다른 클래스와 협력해 시스템을 구축하도록 설계하는 것입니다

모든 클래스 메서드가 클래스 인스턴스 변수를 많이 사용하면 할수록 ‘응집도’는 높아집니다

응집도가 최상인 클래스는 존재하기 어렵지만, 최대한으로 끌어올릴 필요가 있습니다

변수와 메서드를 적절히 분리해 새로운 클래스로 쪼개면, 하나의 클래스에 섞여있던 메서드와 인스턴스 변수들이 하나의 책임아래 분배되기 때문에 각 클래스는 자신의 인스턴스 변수를 100% 활용하게 되고자연스럽게 응집도가 높아지게 됩니다

여러 역할이 섞여 있는 코드는 특정 기능만 테스트하기가 쉽지 않습니다, 특정 기능만 테스트하기 위해서는 해당 기능과 의존관계에 있는 모든 상태를 설정해야합니다

이 경우, 의존 관계를 파악하는 것이 가장 중요한데, 역할과 책임이 복잡하게 섞인 큰 클래스들은 어디서 어떻게 관계를 맺고있는지 확인하기가 쉽지 않습니다

또한, 테스트 후 수정이 발생하더라도 어디에 어떻게 수정을 적용할지 난감합니다

때문에 SRP를 준수하여 작은 클래스로 나뉘도록 코드를 변경하여 의존관계 파악과 수정이 용이하게 해야 합니다

728x90