우아한 테크캠프 4,5주차 - 2

객체 지향에 관한 수업을 들으면서 원래 알고 있다고 생각했지만 그렇지 않은 내용이 있었다. 프로그래밍 관점에서 객체 지향을 이해해야 하고 아직 익숙치 않은 객체 지향 설계 원칙을 이해하고 지켜서 프로그래밍을 해야할 것 같다. 또한 이전에는 SOLID가 무엇인지 정확하게 대답할 수 없었지만 이번 정리를 통해 오랫동안 기억에 남아 있길 바란다.

---

객체 지향 설계 원칙

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod 에 따르면 객체 지향 설계 원칙은 의존성 관리에 초점을 맞추고 있는 것으로 보인다. ' Poor dependency managment leads to code that is hard to change, fragile, and non-reusable' 의존성 관리에 소홀하면 수정하기 어렵고, 재사용이 어렵다고 한다. SOLID 규칙들을 이해하고 개발할 때 적용할 수 있도록 하여야겠다.

 

SOLID

• 단일 책임 원칙 (Single responsibility principle / SRP) 

클래스는 단 하나의 책임을 가져야 한다는 원칙. 하나의 클래스에 책임이 많다면 각 책임마다 변경이 발생 시 다른 책임에도 영향을 줄 수 있다. 이를 어기면 재사용성을 떨어뜨리고 클래스 내에 어쩔 수 없이 추가적인 책임이 생기게 될 수도 있다. 

 

• 개방-폐쇄 원칙 (Open-closed principle / OCP) 

확장에는 열려있고 변경에는 닫혀있어야 한다는 원칙. 인터페이스나 상속을 통해 구현이 가능하다. 확장이나 변경해야할 부분을 추상화하려는 노력이 필요하다. 

 

• 리스코프 치환 원칙 (Liskov substitution principle / LSP) 

상위 타입의 객체를 하위 타입의 객체로 치환해도 정상적으로 실행되어야 한다는 원칙. Stack과 Vector의 관계나 직사각형을 상속받은 정사각형의 관계처럼 올바르지 못한 상속 관계가 아닌 부모 객체의 동작을 완벽하게 대체할 수 있는 구조로 상속을 구현해야 한다. 상위 타입의 메서드를 오버라이드할 때 이 원칙을 지킬수 있도록 고려해야 한다.

 

• 인터페이스 분리 원칙 (Interface segregation principle / ISP) 

인터페이스는 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다는 원칙. 구현할 객체에서 무의미한 메서드 구현을 막기 위해 인터페이스를 필요한 기능만 제공하도록 분리하여야 한다. 하나의 범용적인 인터페이스보다는 작게 여러 개의 인터페이스로 나누는 것이 더 좋다.

 

• 의존 역전 원칙 (Dependency inversion principle / DIP)

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다는 원칙. 객체가 일반적인 객체와 같은 저수준 모듈에 의존해서는 안되고 인터페이스와 같이 추상화된 고수준 모듈에 의존해야 한다. 객체 생성 시 객체로 구현해야 할 부분과 인터페이스로 구현해야 할 부분을 잘 나눌 수 있어야 한다.

 

대략적인 개념은 정리했지만 실제로 개발에 녹여내기 위해서는 계속 이 원칙들을 생각하고 의식하면서 개발을 하여야 할 것 같고, 오브젝트라는 책을 읽어서 한 번 더 개념을 정립하는 것도 좋아보인다.

 

---

세 번째 프로젝트가 끝나고 마지막 프로젝트를 앞두게 되었다. 지난 프로젝트를 되돌아보면 앱의 UI를 Jetpack Compose로 모두 구현할 것이다라는 무리할 수도 있는 계획으로 인해 막바지에 많은 부담을 안게 되었다. 익숙치 않은 기술을 이용하여 구현할 때는 보다 더 전략적으로 계획을 세우고 일정 관리에 신경을 쏟아야 할 것 같다. 다행인 점은 그래도 구현은 기간안에 마칠 수 있었다는 점과 실제로 배포되는 앱 프로젝트가 아닌 교육에서의 프로젝트이기 때문에 학습의 측면에서 보자면 나쁘지 않은 선택이었다고 생각한다.

 

프로젝트에서 경험하고 개발한 내용을 정리하여 다른 사람들과 공유를 하는 데모 발표에 대해서도 조금 더 신경써서 준비를 해야겠다는 생각이 들었다. 2주동안 열심히 잠을 줄여가며 개발을 했다면 이를 제대로 정리하여 보여주는 것도 그만큼 중요하다. 개발을 하면서 고민하고 부딪혔던 문제, 팀원 혹은 스터디 동료들과 공유했던 내용과 전반적인 프로젝트를 정리할 수 있도록 틈틈이 기록하는 습관을 가져야겠고 마지막 프로젝트에서 이를 잘 지켜서 데모 준비가 수월하게 진행될 수 있기를 바란다.

 

구현에 쫓기다보니 코드 품질이 그리 좋지 못했다. 중간중간 리팩토링을 하기는 했지만 개선 작업이 필요한 코드가 계속해서 나왔다. 리팩토링을 하지 않아도 될 만큼의 코드를 작성하는 것은 지금 단계에서는 불가능에 가깝기 때문에 리팩토링에 대한 일정을 넉넉하게 잡는 것도 중요하지만 처음 작성할 때 신중하게 구조를 잡고 코드를 작성할 수 있도록 노력이 필요할 것 같다.

 

 

남은 3주도 힘내자..!