본문 바로가기
CS/Computer Basic

[CS/Basic] 객체지향 프로그래밍의 특징과 설계원칙(SOLID)

by iosdevlime 2023. 2. 1.

자, 이번 포스팅은

 

지난번 객체지향 포스팅에서 미처 다루지 못했던

  • 객체지향 프로그래밍의 4가지 특징
  • 그리고 객체지향 설계 원칙(SOLID)

2가지 사항에 대하여 살펴볼 예정입니다.

 

이전에 다룬 객체지향에 대한 내용이 어렵지 않다면,

이해하고 숙지하는데 큰 어려움은 없지 않을까 하는.. 

 

 

객체지향 프로그래밍의 개념 (복습!)

 

[CS/Basic] 마침내, 객체지향 프로그래밍 (OOP, Object-Oriented Programming)

쉴새없이 달려온 프로그래밍 패러다임,, 마침내, 프로그래밍을 조금이라도 맛본 개발자들이라면 오다가다 자주 마주치는 '객제지향' 에 대해 다뤄보는 시간을 가져볼까 합니다. '객체(Object)' 란

iosdevlime.tistory.com

 

 

 

 


 

 

 

 

객체지향 프로그래밍의 4가지 특징

추상화, 캡슐화(은닉화), 상속성, 다형성

 

객체지향 프로그래밍은,

크게 추상화 / 캡슐화 / 상속성 / 다형성 을 가진 언어 패러다임입니다.

 

 

 

 

추상화 (Abstraction)

  • 인스턴스(객체)로의 실체화를 위해 공통된 속성과 행위를 추출하고 정의하는 것입니다.
    • Class란 인스턴스(객체)를 만드는 틀은, 객체의 공통된 특징만 취하고 있습니다.
    • 따라서, 불 필요한 부분은 무시하며 복잡성을 줄여 단순화를 지향합니다.
  • 자동차 설계도(Class)를 예시로 들자면 ? ➟ 공통된 특징을 집합화, 인스턴스를 생성
    • 자동차(Class) : 추상화 (틀)
      • 속성(프로퍼티) : 색상, 바퀴, 바디, 엔진 ...
      • 행위(메서드) : 전진하기, 후진하기, 충전하기 ...
    • 인스턴스(Instance, 객체) : 실체화 (산출물)
      • Audi / Volvo / Hyundai 

자동차 설계도(추상화)은 자동차(실체화)를 만들기 위한 공통된 특징이 포함되어 있다
자동차 설계도(추상화)은 자동차(실체화)를 만들기 위한 공통된 특징이 포함되어 있다

 

 


 

 

 

캡슐화 (Encapsulation)

  • 추상화를 목표로 속성과 행위를 마치 '캡슐'처럼 결합(집합화)하는 것입니다. 
    • 용어 그대로, 속성(프로퍼티)와 행위(메서드)를 하나로 묶어내는 특징입니다.
    • 여기서의 '캡슐'Class란 틀이 되며, 이는 재활용이 원활하단 장점이 있습니다.
  • 캡슐화를 바탕으로, 내부 정보를 노출시키지 않는 '정보 은닉'을 활용할 수 있습니다.  
    • 이는, 객체의 상태 및 속성 정보에 대한 외부간섭을 차단하는 것을 말합니다.
    • 밖으로 드러내지 않고, 감춰(hiding) 내부 정보를 접근, 제어할 수 있습니다.
  • 레스토랑에 온 고객이, 음식의 유통구조와 같은 모든 정보를 알 필요가 없는 것과 마찬가지입니다. 
    • '은닉화'를 하지 않는다면, 너무 많은 정보가 노출됨에 따라 사용자는 불편을 겪게 됩니다. 

고객은 사용된 재료, 맛, 향 등 필요한 정보만을 원할 뿐이다
고객은 사용된 재료, 맛, 향 등 필요한 정보만을 원할 뿐이다

 

 

(주의! 캡슐화와 은닉화(hiding)은 동일한 개념이 아닌, 캡슐화의 특징 중 하나입니다)

 

 

 


 

 

 

상속성 (Inheritance)

  • 클래스(Class)의 속성와 행위를 타 클래스(하위클래스)가 물려받아 동일하게 사용하는 것입니다.
    • 하위 클래스(Child Class)는 기존 클래스(Super Class)의 기능을 활용할 수 있습니다.
    • 이는, 재 사용성확장성이란 의미를 가지고 있습니다.

동물(부모클래스)의 특징을 ➟ 포유류, 양서류, 파충류(하위 클래스)는 재사용하거나 확장할 수 있음
동물(부모클래스)의 특징을 ➟ 포유류, 양서류, 파충류(하위 클래스)는 재사용하거나 확장할 수 있음

 

 

  • 상속(inheritance)의 프로그래밍 측면에서는 몇 가지 장단점이 존재합니다.
    • 장점
      • 재사용성으로 인해 불 필요한 코드가 감소
      • 확장성에 따른 새로운 개념의 하위 클래스를 창조
      • 기존 클래스의 정보에 대한 자유로운 활용 및 추가
    • 단점
      • 상속받은 하위 클래스가 있을 경우, 상위 클래스 정보의 변경이 어려움
      • 사용되지 않은, 불 필요한 하위클래스가 난립할 수 있음
      • 상속 자체가 잘못되어, 프로그램의 문제가 발생할 수 있음

 

 

 


 

 

 

다형성 (Polymorphism)

  • 기존 클래스와는 별도로, 상속받은 하위클래스에서는 다양한 형태로 기능을 재 정의합니다.
    • 기존의 속성과 행위는, 하위클래스에서 다른 방식으로 응답할 수 있습니다.
    • 해당 방식은 크게 오버라이딩(Overriding), 오버로딩(Overloading) 으로 나뉩니다.
  • 오버라이딩(Overriding)이란?
    • 상위 클래스의 행위(메서드)를, 하위클래스에서 필요에 의해 재 정의하는 것을 의미합니다.
    • 즉, 상속받은 하위클래스는 override 키워드를 메서드 앞에 붙여, 새로운 기능을 부여합니다.
// 상위 클래스 Car가 있고, 배기음 소리(exhaustSound)라는 메서드가 있음
class Car {
    func exhaustSound () {
        print("부앙~")
    }
}

var car: Car = Car()
car.exhaustSound() // "부앙~"


// 하위 클래스에서 exhaustSound를 재 정의한다면?

class Audi: Car {
    override func exhaustSound() {
        print("위잉~")
    }
}

// 위에서 선언된 인스턴스 'car'에 상속받은 하위클래스 Audi를 대입하고
car = Audi()

// exhaustSound 메서드를 실행하면?
car.exhaustSound() // "위잉~"

 

 

  • 오버로딩(Overloading)이란?
    • 동일한 이름을 가지고 있는 행위(메서드)가 존재할 경우,
    • 매개변수의 이름, 타입, 갯수의 차이에 따라 구별되며, 다르게 동작합니다.
func printsayHello() {
    print("Hello : 미국의 인사말")
}

func printSayHello(language: String) {
    print("안녕하세요 : \(language)")
}

func printSayHello(_ language: String) {
    print("aloha : \(language)")
}

// 위 3개의 메서드의 이름은 printsayHello로 동일하지만?

printsayHello() // Hello : 미국의 인사말
printSayHello(language: "한국의 인사말") // 안녕하세요 : 한국의 인사말
printSayHello("하와이의 인사말") // "aloha : 하와이의 인사말"

 

 


 

 

 

객체지향 프로그래밍의 설계 원칙

SOLID 라는 다섯 가지 원칙을 통해 객체지향적 설계를 지향

 

위에서 다룬 객체지향 프로그래밍의 4가지 특징을 바탕으로,

'SOLID'라 불리는 다섯 가지 원칙을 통해 프로그래밍을 설계합니다.

 

 

 

SOLID (객체 지향 설계 원칙)

  • S : 단일 책임 원칙 (SRP, Single Responsibility Principle)
    • 하나의 클래스(상위 혹은 하위)는 하나의 책임 원칙만을 가져야 합니다.
    • 만약 이를 지키지 않을 경우, 책임의 변경에 의해 코드에 악 영향을 줄 수 있습니다.
  • O : 개방-폐쇄 원칙 (OCP, Open/Closed Principle)
    • 상속성 및 다형성(특징의 확장)은 개방되어 있으나, 변경은 조심히 다뤄야 합니다.
    • 임의로 기능(특징)을 담당하는 코드를 수정하는 것은 지양합니다.
  • L: 리스코프 치환 원칙 (LSP, Liskov Substitution Principle)
    • 각각의 객체(하위 클래스)는 상위 객체의 정확성을 방해하지 않아야 합니다.
    • 객체(하위 클래스)의 특징이 변경(치환)된다 해도, 상위객체는 정상적으로 동작해야 합니다.
  • I : 인터페이스 분리 원칙 (ISP, Interface Segregation Principle)
    • 단일한 상위 클래스 인터페이스보단, 여러개의 상위 클래스로 분리, 활용해야 합니다.
    • 이는 변경에 따른 위험도를 낮추는 설계 원칙 중 하나입니다.
  • D : 의존관계 역전 원칙 (DIP), Dependency Inversion Principle)
    • 추상화, 즉 '틀'의 중요성에 대해 인지하고, 의존해야 합니다.
    • 하위 클래스에서의 구체화가 아닌, 상위 클래스 자체고 수준의 모듈이 되어야 합니다.

 

 


 

 

객체지향 프로그래밍의 장단점을 간략하게 정리하면서,

대 장정의 객체지향 파트를 마무리 하도록 하겠습니다!

 

  • 장점
    • 클래스(틀) 단위의 추상화, 모듈화를 통해 업무분담과 대규모 SW 개발이 적합
    • 클래스(틀) 단위의 수정이 용이하므로, 편리한 유지보수가 가능
    • 상속 및 다형성의 특징을 바탕으로 코드의 재 사용이 용이
  • 단점
    • 하위 객체의 수가 증가할 수록, 처리 속도의 문제 발생 우려
    • 객체지향 프로그래밍 설계 단계에서의 다수의 노력과 시간비용이 발생

댓글