왜 OOP인가 [1]

글을 시작하기에 앞서, 이 글이 OOP에 대한 지식적인 정보를 위한 글이라기 보다는,
왜 기업들은 OOP 기반의 개발을 지향하는지에 대한 탐구와 사유의 글임을 알려드립니다.

• 앞선 1부 글에 이어지는 내용입니다. (링크)

왜 OOP인가.

• 항상 왜?를 달고사는 사람인지라, OOP라는 말을 들어오면서 가졌던 의문을 이제는 본격적으로 탐구해 볼 준비가 된 것 같아 정리해보고자 한다.
• (물론 아직 부족한 점이 많기에, 혹여 고수분들이 보게 되시거든 댓글로 지식을 더해주시면 참 행복할 듯 하다...)
• 1부에 이어 2부에서는 OOP는 어떻게 비용을 절감시킬 수 있는가에 대한 내용을 이어가보고자 한다.
  
  

OOP는 어떻게 비용을 절감시킬 수 있는가

• OOP의 비용절감 '킥'은 캡슐화와 다형성(+추상화)이다.

• OOP를 해야 개발자들이 편하다. (코드의 재활용성, 코딩과정의 간편함, 디버깅이 용이함)

• 개발자들이 편하다는 것은 곧 핵심적인 업무에 시간과 체력을 집중할 수 있다는 것이므로
  비용절감이라고 볼 수 있다.

OOP를 탐구하면서 '빌런을 막기 위해 만들어진 제어장치'라는 느낌을 계속해서 받았다.

• 여러 CTO분들이 공통적으로 말씀하시는 "잘하는 사람을 뽑는 것보다, 못하는 사람을 뽑지 않는 것이 중요하다."와 같은 맥락에서 접근할 수 있을 것 같다.
• 기획단에서 그린 밑그림을 함께 완성해나가는 과정에서 빌런이 활개칠 수 없도록 가이드라인을 여러겹으로 제공하는 느낌이랄까..
• 다른 시점에서 접근해보자면 주어진 가이드라인의 의도를 파악하고 코딩을 한다면 빌런이 되지 않을 수 있다!라고도 해석할 수 있겠다.

OOP의 밑그림(설계도)을 잘 그리는 방법을 알아보자.

공부하며 많이 듣는 말: '출제자의 의도를 파악해야한다.'

• 개발에 이를 접목시켜보자면, '이 코드를 작성한 사람의 의도를 파악해야한다.'라고 해석할 수 있다.
• OOP의 경우에는 그 의도를 밑그림(설계도)에 담을 수 있다.

밑그림(설계도)은 클래스에 그린다.

• 클래스를 구성하는 필드, 메서드에도 의도를 담을 수 있고,
• 접근제어자( private으로 꽁꽁 싸매기) 등을 통해서도 가능하며,
• 더 나아가 추상클래스와 인터페이스에도 담을 수 있다.

  HOW(어떻게) OOP를 할 수 있는지, 그 방법에 대해서는 종류가 다양하지만 모든 방법의 바탕에는 SOLID 원칙이 있다.

마지막으로 기술한 'OOP의 초석이 되는 SOLID 원칙'에 대한 내용은 3부에서 계속됩니다..
(링크)