1. 객체지향

• 객체지향 4가지 특징
  1. Abstraction(추상화)
     1. Object들이 공통적으로 필요로 하는 속성이나 동작을 하나로 추출하는 작업을 말함
     2. 세부적인 사물들의 공통적인 특징을 파악하여 추출하고, 필요없는 특성은 제거하여 하나의 묶음으로 정의함
     3. 추상적인 개념에 의존해 설계해야 유연함을 갖출 수 있음 → abstract(추상Class), interface(인터페이스)
  2. Polymorphism(다형성)
     1. 한 Object가 상속을 통해 기능을 확장하거나 변경하여 다른 여러 행태(object)로 재구성 되는 것을 말함
     2. 서로 다른 Class의 Object가 같은 동작 수행 명령을 받을 때, 각자의 특성에 맞는 방식으로 동작하는 것을 말함
     3. 한부모 밑에서 태어난 자식이나 쌍둥이가 똑같지는 않다는 것과 비슷함
     4. overload(오버로드) or overide(오버라이드)
  3. Encapsulation(캡슐화)
     1. 정보 은닉화로 불리며, 높은 응집도와 낮은 결합도를 유지할 수 있도록 설계함
     2. 데이터와 코드의 형태를 외부로부터 알 수 없게 함
     3. 데이터의 구조와 역할, 기능을 하나의 캡슐 형태로 만듬을 말함
     4. 결합도
        1. 어떤 기능을 실행할 때 다른 Class나 Module에 얼마나 의존적인지를 나타내는 지표를 말함
        2. 결합도가 낮게되면, OOP 설계의 의미가 없음! → OOP는 Object 간의 독립성을 강조하는 것을 말함
     5. 캡슐화의 목적은 접근 지정자를 private로 선언하여 Data를 보호하고, 보호된 Variable는 getter나 setter 등의 Method를 통해 간접적 접근을 허용함, 그리고 의도하지 않는 동작 오류를 방지하고 유지보수 효율도 높여줌
  4. Inheriatance(상속)
     1. 여러 개체들이 지닌 공통된 특성틀 부각시켜 하나의 개념이나 법칙으로 성립하는 과정(일반화)을 말함
     2. 기존 상위 Class의 기능을 가져와 재사용을 할 수 있고, 상속 받은 하위 Class에 새로운 기능도 추가 할 수 있음
        1. 코드 재사용 (기능확장)
           1. IS-A관계(is a relationship)
              1. 상속관계를 말함
              2. 상위 Class : 일반적 개념
              3. 하위 Class : 구체적 개념
              4. ex) 상위 Class : 동물 / 하위 Class : 포유류, 파충류
              5. ex2) 말은 동물이다. (말의 부모 Class는 동물임)
           2. HAS-A관계(has a relationship)
              1. 포함관계 or 구성관계를 말함
              2. Class가 다른 Class를 소유한 관계를 말함
              3. ex) 컴퓨터 안에는 CPU가 있음 (컴퓨터 Object가 CPU Object를 구성)
     3. 코드의 중복을 없애줌 → 상속관계를 맺으면, 부모 Class 의 속성들을 자동으로 물려받기에 자식 Class에서 다시 정의 할 필요가 없음!
• 객체지향의 5가지 설계 원칙(SOLID)
  • 응집도는 높이고 결합도는 낮추자는 고전 원칙을 객체지향의 관점에서 재정립한 것임
  1. SRP(Single Responsibility Principle - 단일 책임의 원칙)
     1. 어떤 Class를 변경해야 하는 이유는 오직 하나 뿐이여야 한다는 점
     2. SRP가 안지켜진 사례
        1. 변수레벨
           1. 하나의 속성이 여러 의미를 갖는 경우
           2. 어떤 곳에서는 쓰고, 어떤 곳에서는 안쓰는 속성이 있는 경우
        2. 메소드레벨
           1. 분기처리를 위한 if문이 많을 경우
  2. OCP(Open/Closed Principle - 개방 폐쇄의 원칙)
     1. S/W Entity(Class, Module,Funcion…)는 확장에 대해서는 열려 있어야 하지만 변경에 대해서는 닫혀 있어야 함
     2. 자신의 확장에 열려있고, 주변의 변화에 대해서는 닫혀 있어야 한다는 의미
     3. interface를 통해 구현하여 해결함
  3. LSP(Liskov’s Substitution Principle - 리스코프 치환의 원칙)
     1. 서브타입은 언제나 자신의 기반타입으로 교체할 수 있음
     2. 하위 Class의 instance는 상위형 Object 참조변수에 대입해 상위 Class의 instance 역할을 수행하는 데 문제가 없어야 함
     3. OOP 4대 특성의 상속, interface 원칙이 잘 지켜진다면 LSP는 자동으로 잘 적용됨(조직도, 계층도 관점에서의 상속이 LSP를 위배하는 문제가 생김)
  4. ISP(Interface Segregation Principle - 인터페이스 분리의 원칙)
     1. 클라이언트는 자신이 사용하지 않는 Method에 의존 관계를 맺으면 안됨을 말함
     2. SRP와 비슷하지만 interface를 통한 다른 해결책을 제안함
     3. ex) Class 사람 implements 군인이면 군인 김백골 = new 사람() 을 통해 군인 interface의 Method만을 사용하도록 제한 하는 것임
     4. 일반적으로는 ISP 보다 SRP를 할 것을 권장함
  5. DIP(Dependency Inversion Principle - 의존성 역전의 원칙)
     1. 고차원 Module은 저차원 Module에 의존하면 안됨을 말함
     2. 추상화된 것은 구체적인 것에 의존하면 안됨
     3. 구체적인 것이 추상화된 것에 의존해야함
     4. 자주 변경되는 Class에 의존하지 말자는 말로 요약이 될 수 있고, 자신보다 변하기 쉬운 것에 의존하지 말라는 의미임
     5. 해결방법으로 OCP와 비슷하지만, 구체적인 Class가 아닌, interface의 의존함으로써 DIP를 해결함
• 객체지향 패러다임
  • 적절한 Object에게 적절한 책임을 할당하여 서로 메시지를 주고 받으며 협력하도록 하는 것을 말함
  • 점점 증가하는 S/W 복잡도를 낮추기 위해 객체지향 패러다임을 대두함
  • 객체지향 패러다임 2가지 중요 포인트
    • Class가 아닌 Object에 초점을 맞춤
    • Object에게 얼마나 적절한 역할과 책임을 할당하는지