[SW 공학] 객체지향과 좋은 코드

객체지향

• 현대 소프트웨어 개발에 있어서 가장 중요한 되는 개념

• 스크립트 언어나 함수형 언어를 접하게 되더라도, 그리고 구조적 언어를 통해 개발을 하게 되더라도 객체지향은 꼭 알고 지나가야 하는 개념이다.

• 프로그래밍 언어의 기초 문법을 익히고 나서 소프트웨어를 구조적으로 작성하기 위해 배우는 첫번째 단계

• 불완전성의 관리 관점에서 보면 객체지향은 갈수록 대형화 되어 가는 소프트웨어를 작은 단위로 축소시켜 주는 역할
• 하위 타입에 대한 은폐를 통해서 작성해야 할 코드의 양을 줄이면서도 수정 및 확장이 용이한 소프트웨어 구조를 만들어 줌.
• 상속을 통해서는 중복된 코드가 발생하는 것을 막고, 인터페이스와 타입의 개념을 통해서는 내부 구현에 대한 은폐를 가능하게 해줌.
• 변수 대신 객체를 바꿈으로써 조건문/제어문을 사용하는 대신 직접 행위를 변경할 수 있게 함.

객체지향 3대 특징

캡슐화

• 객체의 필드(속성), 메소드를 하나로 묶고, 실제 구현 내용을 외부에 감추는 것
• 정보의 손상과 오용 사전 방지.
• 다른 객체와의 독립성 유지로 전체적인 코드 유지보수 및 변경에 유연

상속

• 상속이란 기존 클래스를 재사용하는 것
• 개발시간 절약, 중복 코드 감소 및 유지보수에 용이해짐

다형성

• 하나의 타입에 여러 객체를 대입함으로써 다양한 기능을 이용할 수 있도록 하는 것
• 구체적으로는, 부모 클래스 또는 인터페이스의 타입 변환, 오버로딩과 오버라이딩

효율적이며 좋은 코드란?

1. 코드가 명확하고 단순하여야 한다.

2. 각 모듈 및 객체는 최소한의 기능만을 하도록 세분화한다.

3. 재사용성이 높아야 한다.

4. 유지보수가 적거나 쉬어야 한다.

5. 리소스의 낭비가 없거나 최소화하여야 한다.

좋은 코드란, 가독성, 간결함 등 여러 방면이 있겠지만, 디자인 패턴에서는 설계적 관점에서의 좋은 코드를 말한다.
즉, 확장과 수정에 용이하여 설계 이후에도 추가적인 유지 보수에 비용이 적게들어가는 코드를 말한다.

객체지향적으로 생각하면, 추구해야할 설계 방향은 다음과 같다.

객체 간 응집도는 높이고, 결합도는 낮게.
요구 사항 변경 시, 코드 변경을 최소화 하는 방향으로.

SOLID 원칙

1. SRP (Single Responsiblity Principle, 단일 책임 원칙)

   • 클래스나, 함수는 단 하나의 책임(기능)만을 가져야 한다.
   • 클래스, 함수가 비대해지면 이를 분리시킬 필요가 있다.
   • 산탄총 수술
   • 하나의 책임이 여러 개의 클래스로 분산되어 있는 경우
   • 요구 사항이 변경될 시, 분산된 책임을 가지고 있는 모든 부분을 살펴야 한다.

2. OCP (Open-Closed Principle, 개방-폐쇄 원칙)

   • 기존 코드 변경에는 닫혀있고, 추가나 확장에는 열려있어야 한다.
   • 자주 변경될 수 있는 내용은 수정하기 쉽게 설계해야 하고,
   • 자주 변경되지 않을 내용은 수정에 영향받지 않게 설계해야 한다.

3. LSP (Liskov Substitution Principle, 리스코프 치환 원칙)

   • 자식 클래스는 부모 클래스에서 가능한 행위를 수행할 수 있어야 한다.
   • 파생 클래스를 만들 때, 이게 정말 올바른 상속의 관계를 갖는지 생각해봐야 한다.
   • ex.) Rectangle, Square 클래스

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

   • 의존 관계를 맺을 때, 변화하기 쉬운 것 보단 변화하기 어려운 것에 의존해야 한다.
   • 변화하기 쉬운 것 = 구체적인 것 (클래스, 서브 클래스 인스턴스)
   • 변화하기 어려운 것 = 추상적인 것 (추상 클래스, 인터페이스)
   • {인터페이스 or 추상클래스} {변수 명} = {서브 클래스 인스턴스}` 꼴이 되어야 한다.
   • 의존성 주입 (Dependency Injection) 기술

5. ISP (Interface Segregation Principle, 인터페이스 분리 원칙)

   • 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다.
   • 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시킴으로써 꼭 필요한 메서드들만 이용할 수 있게 한다.
   • 다시 말해, 인터페이스를 클라이언트에 특화되도록 분리시키라는 설계 원칙이다.