객체지향 프로그래밍과 디자인 패턴

⚠️ 지속 업데이트 되는 문서입니다.
⚠️ 정보 전달보다는 개인적인 기록에 가까운 글이 작성될 예정입니다.

🥳 개요

항상 내가 작성하는 코드에 대한 확신이 부족했다.
그저 감에 의지해서 코드를 작성할 뿐 이렇게 작성하는 것이 맞는지, 왜 맞는지에 대한 갈증이 항상 존재했다.
작년 우아한테크코스를 하면서도 그런 갈증이 계속 있어서, 설계에 대한 글을 작성한 적이 꽤나 있었지만 취업 준비 중에 해당 주제를 공부한다는 것이 현실적으로 힘들었다. 단기간에 공부할 수 있는 것이 아니라 더더욱 그랬다. 신입 개발자 면접에서 해당 주제를 꺼낸다는 것은 사실 면접을 포기하는 것이나 마찬가지였으니까. 실제로 블로그에 올라간 설계 관련 글을 다 내리기도 했었다.
하지만 설계가 중요하다는 생각은 아직도 변함이 없다. 우리는 개발자로서 코드로 모든 것을 표현한다. 우리의 생각을 코드로 표현하기 시작해, 코드로 완결된다. 따라서 설계에 대한 고민과 학습은 매우 중요하다고 생각한다.
이런 학습을 통해 많은 사람이 수십년 간 고민해왔던 것을 단기간에 흡수하고, 코드를 바라보는 새로운 시각을 가질 수 있게 되었으면 좋겠다. 항상 가려웠던 부분을 시원하게 긁어줄 수 있는 학습이 되었으면 좋겠다. 이렇게 쌓인 기반은 새로운 기술, 패러다임이 나오더라도 좋은 시작점이 되어줄 것이라 믿는다.
올해 초 취업을 통해 심적인 부담을 덜었고, 생활 패턴도 어느정도 자리를 잡았다.
이제는 설계에 대한 갈증을 해결해보려고 한다.

❗️ 항상 염두에 두어야 할 것

• 항상 기본은 책임, 협력, 역할이다.
• 유연할 수록 좋은 것 x, 해당 도메인에 적합한 수준의 유연성 o
  • 미래의 존재할지도 모르는 모든 수정을 염두에 두지 말고, 현재 예상되는 수준에서의 수정을 고민하라.
  • 유연할수록 실제 코드와 런타임 동작 간의 간극이 커진다는 것을 의미.
    유연함과 명확함 사이에서 균형을 잘 잡아야한다.
• 설계란 항상 트레이드 오프가 존재하는 행위. 여러가지 설계 중에서 정답은 없다.
• 코드 수정보다 코드 추가가 낫다.

📋 학습 목표

• 내가 만드는 도메인의 수정 사항을 유연하게 받아들일 수 있는 설계를 위해
• 많은 프레임워크를 보면 유연성을 위한 다양한 설계가 적용되어있는데 이를 이해하기 위해
• 다른 개발자와의 소통을 위해
• 객체지향을 넘어선 새로운 패러다임을 좀 더 잘 이해하기 위해

✍️ 글 작성 목표

• 처음의 학습 동기와 목표를 잃지 않고 비정기적이라도 꾸준히 공부할 수 있도록 자극
• 학습했을 때의 생각과 고민을 잊지 않고 기록하기 위함.
  이 글은 독자에게 정보를 전달하는 글이기보다는 내 개인적인 기록에 가깝다. 하지만 독자와 소통하면서 틀린 부분이 있다면 수정하고, 이해가 되지 않는 부분이 있다면 같이 고민하면서 글을 발전시킬 수 있다면 좋겠다.

📚 참고할 자료

책

• 객체지향의 사실과 오해
• 오브젝트
• GoF 디자인 패턴
  친절한 책은 아니지만 객체지향에 대한 이해도가 높아질수록 새로운 면이 보이는 책