코드 재사용성을 높이는 방법

디자인 패턴의 아름다움이라는 책을 읽다가 코드 재사용성에 대한 이야기가 있어 정리하려고 합니다.

 

1. 코드의 결합도를 줄인다.

고도로 결합된 코드는 특정 기능을 재사용하거나 독립적인 모듈, 클래스, 함수로 추출하려고 할때, 일부 코드의 동작이 전체에 영향을 미치며, 일부 코드를 분리하기 위해 보다 많은 코드를 재배치해야 하는 경우가 많다. 따라서 결합도가 높은 코드는 코드의 재사용성에 영향을 미치며, 이를 피하기 위해 코드의 결합도를 최소화 할 필요가 있다.

 

• 많은 로직이 들어간 코드는 많은 곳에 영향을 미치기 때문에, 코드를 분리하려면 필요한 부분 뿐만 아니라 다른 부분의 코드를 많이 건드려야 한다.

 

2. 단일 책임 원칙을 충족시켜야 한다.

모듈이나 클래스의 책임이 충분히 단일하지 않은데, 설계가 거대하다면 해당 모듈이나 클래스에 의존하는 더 많은 코드가 있을 것이며, 반대로 이 모듈이나 클래스도 다른 코드에 많이 의존하고 있을 것이다. 이는 코드의 결합도를 증가시키고 재사용성에 영향을 미친다. 또한 코드의 단위가 작을수록 범용성이 향상되고, 재사용성이 더 쉬워진다.

• 클래스가 단일 책인 원칙을 지키지 않는다는 것은 많은 일을 한다는 말입니다.
• 많은 일은 한다는 것은 해당 클래스에 의존성이 많기 때문에 코드의 결합도를 증가시키고 재사용을 어렵게 합니다.

3. 코드의 모듈화는 필수다.

여기서 모듈은 클래스의 모음뿐만 아니라 단일 클래스나 함수로도 이해할 수 있다. 기능적으로 독립적인 코드를 모듈로 캡슐화하는 방법을 익혀둘 필요가 있다. 모듈은 재사용하기 쉽고 복잡한 시스템을 구축하는 데 직접 사용할 수 있는 빌딩 블록과 같다.

• 모듈화를 시킨다는 것은 Nuget의 패키지를 사용하는 것 처럼 쓸 수 있어야 합니다.
• 그말은 즉 다른 곳과 독립적이기 때문에 어느 곳에서든 사용이 가능해야 합니다.

4. 비즈니스 논리와 비즈니스 논리가 아닌 부분을 분리 할 필요가 있다.

특정 비즈니스와 관련이 없는 코드는 재사용하기 쉽고, 특정 비즈니스에서 사용되는 코드는 재사용이 어렵다. 비즈니스와 관련 없는 코드를 재사용하려면 비즈니스 논리에서 비즈니스와 관련 없는 논리를 분리하여 공통 프레임워크, 클래스 라이브러리, 구성 요소로 추출해야 한다.

• 교차 편집 문제라고 생각합니다.
• AOP를 통해 비즈니스 로직이 있는 코드만 개발하고, 나머지 부분은 따로 분리해야 합니다.
• AOP를 해결하는 방법은 Proxy Pattern, Intercepter, Chain of Responsibility가 있습니다.

5. 일반적인 코드는 하위 계층으로 내려보낸다.

계층화 관점에서 하위 계층의 코드는 재사용하기 쉽다. 일반적인 경우 코드가 계층으로 분리되면, 교차 호출로 인한 호출 관계의 혼동을 피하기 위해 상위 계층의 코드가 하위 계층의 코드가 상위 계층의 코드를 호출하는 작업을 금지한다. 따라서 일반적인 코드는 상위 계층 시스템에서 재사용 할 수 있도록 하위 계층으로 내려보내야 한다.

• 저희 회사 프로젝트는 코드의 계층이 없습니다.
• 기능별로 프로젝트만 분리되어 있기 때문에 A 프로젝트의 Model을 사용하려고 하면 순환 참조가 걸리기 때문에 B 프로젝트에 똑같은 Model을 만드는 경우가 많습니다.

6. 상속, 다형성, 추상화, 캡슐화를 활용한다.

상속을 사용하면 공통 코드가 상위 클래스로 추출되고 하위 클래스는 상위 클래스의 속성과 메서드를 재사용할 수 있게 된다. 또한 더 추상적인 코드일수록 재사용이 더 쉽다. 코드는 세부정보를 숨기고 변경되지 않는 인터페이스를 노출하며 재사용하기 쉬운 모듈로 캡슐화 된다.

• Interface에 속성을 편집 할 수 있게 하면 안됩니다.
• 그렇다는 것은 Public으로 할 수 있는 기능은 한정적이기 때문에 자연스럽게 재사용성이 늘어납니다.

7. 애플리케이션 템플릿과 같은 디자인 패턴을 활용하면 코드 재사용성을 향상시킬 수 있다.

예를 들어 템플릿 메서드 패턴은 코드의 일부를 유연하게 교체할 수 있는 다형성을 사용하여 전체 프로세스의 템플릿 코드를 재사용할 수 있게 해준다.