OOP

해당 글은 객체 지향 프로그래밍 스터디에서 진행한 내용을 정리한 글입니다.

 

현재도 진행 중인 스터디이며 추가되는 내용이 있을 시 수정이 될 수 있음을 말씀 드립니다.

 

OOP가 나온 이유

---

OOP가 나온 계기

• 처음 프로그래밍이 탄생하면서, 절차지향 프로그래밍이 발전이 됐습니다. 왜냐면 뚜렷한 개념 없이 생각하는대로 코딩을 하는 방향이 만들어졌으니까요.
• 그 후 코드 중복을 제거하기 위해 함수라는 것으로 이를 해결하면서, 코드를 단순화를 완성할 수 있었습니다.
• 허나 함수의 경우엔 문제가 있습니다. SW 사이즈가 커지면서 전역 변수참조 영향이 생겼습니다. 이를 사이드 이펙트라 합니다.
• 그래서 OOP가 탄생했습니다. Low Coupling, High Cohesion(의존성을 줄이고, 응집도를 높이자)를 모토로하는 OOP는 일파만파 퍼졌죠.

OOP 키워드

• 클래스 : 청사진 혹은 Description입니다. 비슷하게 모인 attribute(속성)을 method로 관리하는 것을 지향합니다.
  • 속성이 모이니 High Cohesion이 지켜지고 attribute를 method로 관리하니 Low Coupling이 지켜집니다.
• 객체 : 클래스와 같은 청사진을 통해 메모리에 실체가 생기면 이를 객체라고 합니다.
• 생성자
• 소멸자

OOP 핵심 개념

• 추상화
  • OOP 컨셉이 현실을 SW로 설명하는 것입니다. 필요한 것은 남기고, 아닌건 버리면서 추상화를 합니다.
  • 예로 연주자 클래스를 만든다고 했을 때, '어떤' 연주자에서 '어떤(피아노, 하프, 기타 등 / 남성 여성 / 사는 지역)'은 속성이 될 수도 있죠. 이 연주자가 어떤 행동을 하는 것을 메소드로 표현이 가능합니다. '어떤 행동'은 '악기를 연주하다. 악보를 읽다.' 등이 될 수 있죠.
  • 이처럼 현실의 것을 SW로 설명하는 것을 추상화라 합니다.
• 캡슐화
  • 정보를 숨기고, 기능을 묶었다고 캡슐화라 합니다. 실제로 캡슐은 특정 병을 낫게하는 기능을 묶고, 그 성분들을 먹는 사람 입장에선 몰라도 되니 숨겼다고 표현이 되겠죠.
  • 즉, 정보 숨겨 ! 기능 묶어 ! 외부에서 접근 못하게 해 ! 이런거라 생각하면 됩니다.

C에 구조체가 있음에도 객체 지향 프로그래밍 언어가 아니라고 하는 이유는?
그 이유엔 접근 지정이 있습니다. C의 구조체는 접근 지정자가 public입니다. C++의 class는 private입니다.
그러므로 OOP 개념에서 attribute에 직접 접근한다는 건 OOP 개념에 위배되는 행동이기 때문에 메소드로만 접근을 해야합니다. Low Coupling을 지키기 위해서요.
그래서 필요한 메소드는 2가지로 Getter / Setter입니다. 조회를 하고 싶을 땐, Getter / 수정을 원할 땐, Setter를 사용합니다.

접근 지정 지시자
1. public : 모든 접근을 허용합니다.
2. private : 모든 접근을 허용 안합니다.
3. protected : 자식들의 접근만 허용합니다.

• 상속
  • attribute와 method를 자식에게 물려줍니다. 이로서 코드 재사용성을 줄일 수 있습니다.

생성자와 소멸자의 경우 오버라이딩이 되기 때문에 메모리를 덮어씁니다. 그렇기에 부모의 메소드를 모릅니다.

• 다형성
  • 하나의 변수로 여러가지 기능을 구현하는 기법입니다. 만약 다형성 개념이 없으면, 다형성 내부가 if / else 문으로 도배가 되겠죠.
  • 오버로딩 : 인자를 달리해서 다른 함수를 만드는 것입니다.
  • 오버라이딩 : 부모 클래스의 메소드를 자식 클래스에서 재정의 하는 것입니다.
• 위임
  • 상속은 너무 남발하다간 쓰지 않는 속성과 메소드를 받을 수 있기에 SW 무결성에 위배됩니다. 그렇기 때문에 원하는 것을 골라서 받을 수 있도록 위임이라는 개념이 있습니다.
  • 실제로 다중상속은 해석하기 난해하고 코드유지보수 측면에서도 안좋고, Coupling이 커지기 때문에 위임을 쓰는 것을 강조합니다.

OOP의 간단한 장점

• 거대한 프로젝트 할 때, 유지보수 / 확장성 / 유연성을 끌어올리기 위해 OOP가 사용되는데 이로서 시간, 규모를 아낄 수 있습니다. 또한 OOP의 좋은 점은 class description만 봐도 무슨 프로그램인지 알 수 있기 때문에 좋은데, 이를 더 끌어올리기 위해서 UML(Unified Modeling Language)가 존재합니다.
• 사실 UML의 경우엔 WaterFall 방식의 개발론에서 많이 쓰이는 방식인데, 최근엔 Agile 방법론이 도입되면서 위의 diagram이 필요가 없어졌습니다. Agile이 요구 설계에 힘 싣지 말고, 개발 / 리뷰에 힘을 싣는 방향이니까요.
• 그래도 어느정도 쓰이니 아는게 좋겠죠.

---

이상 OOP 였습니다. ^_^