개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴

/*
   * 절차 지향
   * - 프로시저(procedure) 로 구성하는 기법 >> 절차 지향 (Procedural Oriented)
   * 객체 지향
   * - 객체는 프로시저를 실행하는데 필요한 만큼의 데이터를 가지며, 객체들이 모여 프로그램을 구성
   * 인터페이스
   * - 오퍼레이션 정의만 있고 구현은 없는 인터페이스 제공. 인터페이스와 클래스를 좀 더 충실하게 반영할 수 있도록 언어 차원에서 구현이 포함되지 않는 인터페이스가 사용되고 있다.
   * 객체의 책임과 크기
   * - 객체가 갖는 책임이 커질수록 절차 지향적으로 구조가 변질되며, 절차 지향의 가장 큰 단점인 기능 변경의 어려윰 문제(경직성 문제)가 발생
   *   객체의 크기가 작아 질수록 유연함을 얻을 수 있다. 단일 책임 원칙(Single Responsibility Principle; SRP)
   * 의존
   * - 한 객체의 코드에서 다른 객체를 생성하거든 다른 객체의 메서드를 호출
   * 의존의 양면성
   * - B라는 객체는 A라는 객체를 의존하고 있다. 만약에 A라는 객체가 변경되면 나를 의존하고 잇는 B객체에 영향을 준다.
   * 캡슐화
   * - 캡슐화 하여, 외부에서 접근하여 변경을 해서야 안되는것을 방지 할수 있으며, 이로인해 유연성을 얻을 수 잇다.
   * - Tell Don't Ask 데이터를 직접 접근하지말고 ( 직접 적근하면 절차지향적인 코드로 유도가 됨... ) 대신, 기능 실행을 요청.
   *   >  메서드에서 생성한 객체의 메서드만 호출
   *   >  파라미터로 받은 객체의 메서드만 호출
   *   >  필드로 참조하는 객체의 메서드만 호출
   *   객체를 생성하고 함수를 작성할때 그 객체내부에서 처리가 가능한 기능은 다 작성하는게 좋다. (연속된 get 메소드 호출 X, 임시 변수의 get 호출이 많아지면 X)
   *  
   * 객체 지향 설계 과정
   * - 제공해야 할 기능을 찾고 도는 세분화하고, 그 기능을 알맞는 객체에 할당한다.
   *   > 기능을 구현하는데 필요한 데이터를 객체에 추가한다. 객체에 데이터를 먼저 추가하고 그 데이터를 이용하는 기능을 넣을 수도 있다.
   *   > 기능은 최대한 캡슐화해서 구현한다.
   * - 객체 간에 어덯게 메시지를 주고 받을 지 결정한다.
   * - 과정1과 과정2를 개발하는 동안 지속적으로 반복한다. 
   */