객체지향 프로그래밍 (Object Oriented Programming) a.k.a OOP.
프로그래밍을 시작하는 사람이라면 누구나 한 번 쯤은 들어봤을 단어이고, 이걸 이해하려다가 프로그래밍 공부를 접는 경우도 여럿 보았다.
객체란 무엇인가.. 은닉화, 캡슐화, 상속, 다형성.. 개발을 하고 있는 사람들 조차도 이를 개발에 녹여내기가 참 어려운데 개발을 시작하는 사람들이 보기엔 더더욱 어려울 것이다.
처음 개발을 시작할 때 나는 그냥 이런 개념이 있구나.. 정도만 생각하고 넘어갔고, OOP 이 외에도 신기하고 공부할 것도 많았기에 대수롭지 않게 생각하고 넘어왔던 것 같다. 구글링 하면서 Ctrl CV만 해도 프로그램이 만들어졌고 신기했다. (물론 복붙이 나쁘다는 이야기는 아니다)
하지만 어느 정도 개발을 하다 보니 어떻게든 만들어서 어떻게든 돌아가게 만드는 개발이 아닌, Well-Made한 소프트웨어를 개발하고 싶다는 욕심이 조금 더 커지게 됐고 (미쳤지 내가..) 결국 돌아왔다. OOP로.
객체지향 소프트웨어를 설계한다는 것은 쉬운 일이 아니다. 더군다나 재사용 가능한 객체지향 소프트웨어를 만들기란 더 어렵다.
적절한 객체를 식별해야 하고
올바른 크기의 Class와 Interface를 정의해야 하며
Class 간 상속을 정의해야 하고
각 Class들 간의 관계를 설정할 수 있어야 한다.
설계는 지금 당장 가지고 있는 문제를 해결할 수 있어야 하지만, 나중에 생길 수 있는 문제나 추가된 요구 사항들도 수용할 수 있도록 일반적이고 포괄적으로 되어 있어야 한다.
즉, 재설계를 하지 않아도 다시 사용할 수 있어야 하고, 아니면 가능한 최소한의 수정을 통해서 다시 사용할 수 있어야 한다.
객체지향 설계에 경험이 있는 사람들은 아마, 유연하고 재사용 가능한 설계를 처음부터 정확하게 하는 것이 불가능하거나 매우 어렵다는 것을 알 것이다. 설계를 최종 마무리하기 전에 만든 설계를 어러 번에 걸쳐서 재사용해 보려고 시도했을 것이고, 그때마다 재설계의 노력이 필요하다는 경험을 했을 것이다.
** 완전 공감. 프로그램이 출시되면 끊임없는 요구사항과 수정사항이 발생하는데, 이 때 정말 머리가 많이 아프다
그래도 보통 (잘하는) 시니어급 개발자들은 좋은 객체지향 설계를 할 수 있다고 생각한다. 그러나 초급, 중급 개발자들의 경우, 너무 많은 개념들이 있고 이를 실행할 수 있는 다양한 방법론들이 있다는 것에 그대로 멘붕에 빠지기도 한다. 초보자들은 그저 "좋은 객체지향 설계란 무엇인가?" 하는 것을 이해하는 것만 해도 꽤 오랜 시간이 걸린다.
** 그렇다. 나 역시도 아직 이해하지 못했다. 이해했으면 이 공부 시작도 하지 않았겠지..
(잘하는) 시니어급 개발자들은 초중급자 개발자가 모르는 그 뭔가를 알고 있다는 것인데, 과연 그것이 무엇일까?
시니어급 개발자들이 초보처럼 하지 않는 것이 한 가지 있다면, 모든 문제를 처음 기초단계에서 해결하려 들지 않는다는 것이다. (만들기 전에 완성품을 개발의 신처럼 파바박 그려놓지 않는 다는 뜻이다) 대신 전에 사용했던 해결책을 다시 사용해보고, 좋은 방법을 찾아냈다면 그 방법을 반복해서 계속 사용하게 된다. 이런 과정을 통해 시너어급 개발자로 성장하게 되고, 결국에는 많은 객체지향 시스템들에서 클래스 패턴이나 객체들 간의 상호작용 방식이 반복됨을 알게 된다. 이런 반복된 패턴들은 특정 설계의 문제점들을 해결해 주고, 조금이나마 더 Well-made한 객체지향 스프트웨어를 만드는데 도움을 준다.
** 조금은 다른 이야기일 수 있겠지만, 개발 업무를 하면서도 다양한 프로젝트에서 공통적으로 사용하는 function이나 component들을 common library로 묶어서 공통으로 사용할 수 있게 하는 경우가 있다. (현재 회사가 지금 이걸 하려고 노력중이다) 이 경우 일관성있는 구조의 코드스타일로 소프트웨어를 만드는 데 조금이나마 일조하는 것 같다. + 다른 사람과의 협업 할 때도 이런 경우 업무를 진행하는 데 조금 더 수월한 경우가 있다.
영화나 드라마의 작가들이 처음부터 백지에 스토리를 써 내려가는 것이 아닐 것이다. 킹덤이나 셜록홈즈처럼 "좀비", "탐정수사"를 기초로 살을 덧붙이기 마련이다. 마찬가지로, 객체지향 설계도 객체를 가지고 표현 하거나, 특성을 쉽게 빼고 넣을 수 있도록 객체를 꾸미는 것이다.
우리가 개발을 하다보면 가끔 "어? 이거 내가 이전에 어디서 해놓은거 있을텐데..", "어? 나 이거 Stackoverflow에서 본 적 있는데.." 하는 경험이 있을 것이다. 우리가 이것들을 자세하게 기억할 수 있다면 아마 새롭게 개발하지 않고 그대로 적용할 수 있을 것이다.
** 물론 이런것들은 하나의 모듈 정도인 경우가 대부분이겠지만ㅋ
조금 더 확장해서 생각하자면, 소프트웨어 설계에서 얻은 세세한 경험들을 기록해 둔 것, 이것이 디자인 패턴이라는 방식일 것이다.
디자인 패턴을 이용하면
- 좋은 설계나 아키텍처를 재사용하기 쉬워진다.
- 입증된 기술을 디자인 패턴으로 표현해 두면 새로운 시스템 개발자들은 디자인 패턴을 더 자주 유용하게 사용할 수 있다.
- 재사용을 가능하게 하는 설계를 선택하고 재사용을 방해하는 설계는 배제하도록 도와준다.
- 이미 만든 시스템의 유지보수나 문서화도 개선해 준다. (개꿀..)
- 클래스의 명세를 정확하게 하며, 객체 간의 상호작용이나 설계의 의도 등을 명확하게 정의할 수 있다.
결국 디자인 패턴은 개발자로 하여금 "올바른" 설계를 "빨리" 만들 수 있도록 해준다.
GoF의 디자인 패턴 참고
'Development > 디자인패턴' 카테고리의 다른 글
디자인 패턴을 이용하는 방법 (2) (0) | 2022.04.18 |
---|---|
디자인 패턴을 이용하는 방법 (1) (0) | 2022.04.14 |
디자인패턴의 조직화, 관계도 (0) | 2022.04.13 |
디자인 패턴의 종류 (0) | 2022.04.13 |
디자인 패턴이란 무엇인가? (0) | 2022.04.12 |