객체 지향 (Object Oriented)

대학시절 C언어를 공부하면서는 객체 지향에 대한 이야기는 전혀 듣지 못 했다. (대략 2004년? 2008년?)
그래서 개발을 제대로 시작한 2017~2018년 당시 객체 지향에 대해 후배에게 뚜까 맞았다. (아니 이것도 몰라요?)

• 내가 생각하는 객체 지향

  애초에 객체라는 말 자체가 일상생활에서 사용하지 않는 단어이다. 이 말 뜻부터 이해할 필요가 있다.
  사전적 뜻으로는 객지에 있는 몸이다. 프로그램 단어로는 Object를 우리말로 객체라고 한 것이다.
  난 이것이 생각보다 좋은 번역이라 생각한다. 실제로 Class와 Object가 존재하고, Class는 형태를 Object는 실체화로 생각하고 있다.
  때문에 몸이라 할 수 있는 Class를 별도의 공간에 정의해 놓은 후, 이것을 불러와 Object화 시켜 사용하는 것이 가장 기본적인 사용방법으로 정의가 되는 것이다.
  따라서 Class는 그 물체(Object)가 지닌 성질(Data) 및 기능(Method) 담고 있는 그릇으로 생각하고 있다.

• 강의에서의 객체 지향

  사람이 물체를 보는 시각에 대한 정의를 프로그래밍으로 옮겨 놓은 개념.
  인간이 사고하는 방식에 가까운 프로그래밍.
  객체간 상호작용을 할 수 있어야 한다.
  인간 친화적

감성적 접근은 나쁜 것인가? 꼭 그렇지만은 않다고 생각한다. 이론적으로 잘 이해하지 않는 부분에 대해 감성적으로라도 이해를 한다면 그건 이해 못하는 것보다는 낫다고 본다. 단, 이론적 부분에 대한 내용은 암기를 해야 한다는 숙제가 남아있게 된다 (내가 그렇다 🫣)

그럼 이제 객체 지향에 대한 감성적 접근을 보았으니 프로그래밍으로써의 이론적 접근을 해보도록 하자.

객체지향 프로그래밍 (Object Oriented Programming)

단순히 이야기 하자면 객체 지향이라는 개념을 이용한 프로그래밍이다.

여기서 짚고 넘어가야 할 부분은, 객체 지향이 절차 지향의 상위호환은 아니라는 점 이다!

객체 지향 프로그램을 위해서는 아래와 같은 특성을 잘 알 필요가 있다.

캡슐화

• 객체 내 데이터나 기능을 정의하고, 이에 대한 접근 제어가 가능해야 한다.

  대부분의 Class 코드는 이렇게 이루어져 있다.
  Python 에서는 _ 이나 __으로 Public Private 등을 나누었었다.
  C# 에서는 직접적으로 명시하고 있다.

• 용어
  • 클래스 필드: 클래스 데이터 (변수) (Python 에서의 Class Attribute)
  • 클래스 메서드: 클래스 내 함수 (Python 에서의 그것과 같음)

상속

• 부모/자식의 관계를 두어 자식은 부모 클래스의 필드나 메서드가 사용 가능해진다.
• 자식은 부모에게 물려 받은(?!) 필드나 메서드 외 다른 필드나 메서드로 추가가 가능하다.
• 부모는 자식만이 정의한 필드나 메서드는 사용 할 수 없다. 이는 자식끼리도 마찬가지.

  아래 추상화와 같이 잘 쓰이는 특징.
  LB 자동화나 QA 자동화에서 장비 제어 관련 SDK 나 트래픽테스터 제어 프로그램 개발에서 자주 사용된 개념이다.

추상화

• 여러 객체에 대한 본질적인 부분에 대한 공통화가 가능하다.

  위에 이야기한대로 상속과 추상화는 같이 사용되는 경우가 많다.

다형성

• 하나의 클래스로 필드나 메서드에 따라 여러 형태로 존재될 수 있다.

  추상화와 같이 많이 쓰던 내용. 추상화는 Python 에서 abc클래스에 abstract 데코레이터를 사용하여 정의 했었다. 이때 method는 빈 method로 정의하고 이를 상속받는 자식클래스에서 필히 구현해야 했다.

분명...

실제 개발에서는 위 내용을 숨쉬듯이(?) 하고 있었다. 하지만 설명하라면 좀 애매한 부분이 많았다. 약간 정리되는 느낌이다.

SOLID 법칙

보면 좋은 내용: Unity 디자인 패턴 및 솔리드 원칙으로 코딩 스킬 업그레이드

단일 책임 원칙 (Single Responsibility Principle)

• 클래스(객체)는 단 하나의 책임만 가져야 한다.

  대부분의 Class 는 추상화 과정에서 하나의 책임을 갖게 되기는 하다. 이것은 method 또한 되도록 하나의 기능을 수행할 수 있도록 하는 것이 좋았다.

개방 폐쇄 원칙 (Open Closed Priciple)

• 확장에 열려있어야 하며, 수정에는 닫혀있어야 한다.

  버그가 아닌 이상은 자연스럽게 이렇게 되기는 한다.

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

• 자식 객체는 언제나 부모 타입으로 교체될 수 있어야 한다.

  다양성의 특징과 연관된 내용이다. 라고 한다. 잘 이해되지 않기도 한다. 나중에 다시 보자.

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

• 하나의 큰 인터페이스보다 용도에 맞는 인터페이스를 잘게 분리해야 한다.

  인터페이스의 개념이 명확하지 않다(내가). 보통은 외부에서 내부로 들어가는 표면을 인터페이스라고 한다. IT 에서는 많이 사용하는 개념.
  C# 에서의 인터페이스는 꼭 구현해야 할 구조 및 규약로 이해하면 된다. java에도 있고, 객체지향언어에는 대부분 있는 개념. python에서는 abstract 데코레이터가 그 역할을 했다.

의존 역전 원칙 (Dependency Inversion Principle)

• 고수준의 모듈은 저수준 모듈의 구현에 의존해선 안 된다.

  추상화 되었거나 부모 클래스를 상속받는 자식 클래스가 있는 경우, 부모 클래스의 필드나 메소드가 자식 클래스에 의해 변질되서는 안된다는 것...이다? 딱히 의식한 적은 없는데 너무 당연하게 했던 것 같다.

값 타입과 참조 타입

값 타입

Stack 에 데이터가 직접 담기는 타입

• 깊은 복사 혹은 DeepCopy

참조 타입

Stack 에는 메모리 주소가 담기는 타입

• 실질 데이터는 Heap에 담긴다.

• 얕은 복사 혹은 ShallowCopy