위로 아래

객체지향

객체 : 객체는 클래스에 정의된 인스턴수 변수의 집합이다. 객체에는 클래스변수나 메서드가 포함되지 않는다.
 객체는 오직 인스턴스 변수들로만 구성되어 있다.

 

객체지향

  1. 프로그램은 모두 객체로 만들어져 있고, 객체들 간의 메시지를 주고 받는 상호작용으로 이루어진다
  2. 작은 문제를 해결하는 독립된 객체를 먼저 만들고 조립하는 개발 방식
  3. 재사용이 가능한 객체들을 많이 만들어 놓는 것이 중요
  4. 객체지향은 단순히 class나 object를 쓰는 문제가 아니라, 객체들의 관계를 잘 설정해야 한다.
  5. 초기 설계에 에너지가 많이 들어가서 설계 방법이 많이 발전했다. 대표적으로 SOLID가 있으며, 이를 지키면 시간이 지나도 변경이 용이하고 유지보수와 확장이 쉬워진다

 

객체지향의 특성

  1. 캡슐화
    1. 필요한 메소드만 외부로 노출하고, 그 외 기능은 접근하지 못하게 내부에 캡슐처럼 보관하는 것.
    2. 안정성도 보장되고, 코드가 깔끔해지기 때문에 사용성에서도 좋다.
  2. 상속
    1. 객체의 일부분만 재사용하는 방법
    2. 조금씩만 다른 객체도 새로 만들 필요 없이 부분만 재사용해서 코드의 반복 작성을 피할 수 있다.
  3. 추상화
    1. 공통적인 부분을 모아서 상위 개념으로 새롭게 이름 붙이는 것
  4. 다형성
    1. 같은 uint 메소드를 사용하지만 각자 정의된 방식이 있다면 각자의 방식대로 동작할 수 있게끔 하는 것

 

SOLID 객체지향 설계법

SRP (Single Respinsibility Principle) 단일 책임의 원칙

  1. "한 클래스는 하나의 책임만 가져야 한다."
  2. 변경이 필요할 때 수정할 대상이 명확해진다.
  3. 복잡한 객체지향 프로그래밍 속에서, 서로 다른 클래스끼리 서로 미치는 영향의 연쇄작용을 줄일 수 있다.
  4. 시스템이 커질수록 서로 더 많은 의존성을 갖게 되는데, 그럴 때에도 변경 요청이 오면 딱 1가지만 수정해도 되기 때문에, 규모가 커질수록 효과가 크다.

 

OCP (Open-Close Principle) 개방-폐쇄 원칙

  1. "확장에 대해서는 열려 있고, 수정에 대해서는 닫혀 있어야 한다"
  2. 관리가 용이하고 재사용 가능한 코드를 만드는 기반.
  3. OCP를 가능케 하는 중요한 매커니즘은 추상화와 다형성.
  4. 클래스를 설계할 때 변할 부분과 변하지 않을 부분을 명확히 구분해서, 변할 수 있는 부분은 추상화하여 상속하는 클래스가 의존할 수 있게 해야한다.
  5. 기존의 코드는 수정하지 않으면서, 요구사항이 있을 때 새로운 동작을 추가하여 애플리케이션의 기능을 확장할 수 있다.

 

LSP (Listov Substitution Principle) 리스코프 치환 원칙

  1. "서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다"
  2. 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
  3. 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다.
  4. 상속을 잘 활용하고 있다면 LSP가 잘 지켜지고 있는 것이다.
  5. 예시 : 박쥐는 포유류의 역할을 할 수 있다

 

DIP (Dependency Inversion Principle) 의존 역전 원칙

  1. 추상화된 것은 구체적인 것에 의존하면 안 되고, 구체적인 것이 추상화된 것에 의존해야 한다.
  2. 구현 클래스에 의존하지 말고, 인터페이스에 의존할 것.
  3. 구현체에 의존하면 변경이 어려워지니, 인터페이스를 적극 활용해야 한다.
  4. 의존성 주입 (DI, Dependency Injection) : 외부에서 두 객체 간의 관계를 결정하고 주입하는 것

 

ISP (Interface Segregation Principle) : 인터페이스 분리 원칙

  1. "클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안 된다"
  2. 인터페이스를 최대한 세부화하여, 꼭 필요한 인터페이스만 상속한다.
  3. SRP가 클래스의 단일 책임을 강조하면, ISP는 인터페이스의 단일 책임을 강조한다.

 

 

디자인 패턴

디자인 패턴

  1. 객체 지향 프로그래밍 설계 시 의사소통 수단의 일종.
  2. 협업 개발 시 말로 설명하는 하는 것보다 패턴 기반으로 설명하는 것이 직관적이다
  3. 개발 시 발생하는 문제들은 이미 선임들이 해결했던 문제들이고, 그 해결책을 디자인 패턴으로 정리해놓았다. 자주 발생하는 문제들을 피하기 위해 사용되는 패턴.
  4. 결국 패턴보다는 간결한 코드베이스가 가장 중요하다. 패턴에 의존하지 말고, 효율적인 방법을 좇다가 패턴이 필요할 때 써야 한다.
  5. 23개의 패턴이 수록된 GoF가 가장 유명하다.
저작자표시

티스토리툴바