오늘은 학원 3일차다.
코딩에 있어 가장 기초라고도 볼 수 있는 '객체-지향'
오늘은 이 개념에 대해 자세하게 배워보는 시간을 가져보았다.
객체-지향
객체-지향에는 총 3개의 구성이 존재한다
- 객체
- 클래스
- 메시지
클래스는 설계도고 객체는 실체라고 볼 수가 있는데 클래스는 데이터와 연산으로 이루어져있다고 한다.
클래스의 예시
클래스를 사람이라고 지정하게 된다면 그 안에 데이터와 연산이 필요하다
- 데이터: 이름, 나이, 성별, 직업, 국적, 주소 등등
- 연산: 걷다, 뛰다, 숨쉬다, 일하다, 게임하다, 운전하다 등등
이렇게 실습을 해보면서 클래스가 어떤 것인지, 그리고 그 클래스 안에는 어떤 게 존재해야 하는지에 대해 쉽게 알아볼 수가 있어서 좋았다.
간단한 실습(1)
여기서 간단한 실습을 하나 하고 넘어갔다.
내가 직접 클래스를 지정하고 그 안에 데이터와 연산을 넣어 정의하는 실습이었다.
- 클래스 이름: 기타
- 데이터 (Data): 종류, 연식, 가격, 일련번호, 지판, 프렛
- 연산 (Operation): 연주하다, 수리받다, 거래하다, 던지다, 부러지다
이렇게 기타를 예시로 데이터와 연산엔 어떤것들이 들어가야 하는지에 대해 적어보았다.
이렇게보니 객체의 속성이나 특성, 그리고 동작을 통해 데이터와 연산에 어떤 것들이 필요한지 한 눈에 알아볼 수 있어서 편리하였다.
객체-지향의 4대 특징
여기서 좀 더 자세히 들어가 특징에 대해 살펴보았는데
- 상속 (Inheritance)
- 추상화 (Abstraction)
- 다형성 (Polymorphism)
- 캡슐화 (Encapsulation)
이렇게 4가지의 특징으로 나눌 수가 있다고 한다.
상속
첫번째 특징인 상속은 같은 코드를 쓰지 않는다고 한다.
쉽게말해 코드를 재사용함으로써 프로그래밍의 효율성을 높일 수가 있다고 한다.
상위 클래스의 데이터를 하위 클래스가 물려받는다고 볼 수 있겠다.
추상화
세부 구현을 숨기고 쉽고 단순한 인터페이스만 노출시키는 기법이라고 한다.
핸드폰 아이콘이라고 생각하면 단순하겠다.
다형성
하나의 개체가 다양한 형태를 가질 수 있는 성질을 의미한다.
캡슐화
객체의 내부 정보를 보호한다.
객체-지향의 5대 설계 원칙
다음은 객체-지향에 있어 지켜야할 원칙에 대해 알아보았다.
- SRP: 단일 책임 원칙(Single Responsibillity Principle)
- OCP: 개방-폐쇄 원칙(Open-Closed Principle)
- LSP: 리스코프 치환 원칙(Liskov Subsitution Principle)
- DIP: 의존 역전 원칙(Dependency Inversion Principle)
각각 어떤 의미를 가지고 있는지에 대해 자세히 서술해보겠다.
단일 책임 원칙
객체는 단 하나의 책임만 가져야 한다는 뜻이다.
예를들어 관리부문에서는 총무, 경리와 같은 관리직무만
기술 부문에서는 품질관리만, 개발부문에 있어서는 개발부에서만
이런식이다.
개방-폐쇄 원칙
확장에는 열려있고 수정에는 닫혀있어야 한다라는 뜻이다.
기존 시스템을 수정하는 것이 아니라 확장을 하라는 이야기다.
리스코프 치환 원칙
자식 클래스는 최소한 부모 클래스의 기능을 수행해야 한다.
단일 책임 원칙과 비슷한 느낌의 원칙이다.
부모 클래스에서 부여받은 기능을 자식클래스에서도 사용할 줄 알아야한다라는 뜻이다.
그렇지 않다면 상속을 받지 말아야하기 때문이다.
인터페이스 분리원칙
자신이 사용하지 않는 인터페이스에 영향을 받아서는 안된다는 의미다.
예를들어 프린터만하는 회사에서 복합기를 임대한다면 더 높은 임대비용과 전기세를 감당해야 한다.
프린터만 임대한다면 사용하지 않을 기능들로 인한 추가 비용을 지불할 필요가 없다라는 것이다.
분리를 잘 해야 된다라는 생각이 든다.
의존 역전 원칙
클래스는 구체적인 대상보다 추상적인 대상에 의존해야 한다.
변하기 쉬운 구체적인 대상보다 변하지 않는 공동 규칙에 의존해야 한다라는 뜻이다.
의존 역전 원칙을 쓰면 부품 교체나 테스트가 쉬워지기 때문이다.
UML
다음은 UML에 대해 알아보았다.
UML은 통합 모델링 언어(Unified Modeling Language)로 객체-지향 분석과 설계 도구로 사용된다.
UML 구성요소
UML은 크게 3가지로 나뉜다.
- 사물 (Things)
- 관계 (Relationships)
- 다이어그램 (Diagram)
관계
여기서 또 관계의 종류에 대해 자세하게 알아보았다.
- 연관 관계(Association)
- 집합 관계(Aggregation)
- 포함 관계(Composition)
- 일반화(Generalization)
- 실체화 (Realization)
- 의존 관계(Dependency)
각각의 특징에 대해 사진을 통해 알아보도록 하겠다.
연관 관계
2개 이상의 사물이 서로 관련있는 상태를 뜻한다.
집합 관계
전체와 부분(Whole-Part)의 관계이며 이 둘은 독립적이다.
포함 관계
집합 관계와 마찬가지로 전체와 부분 관계이지만 이 둘은 서로 독립할 수 없고 생명 주기를 함께 한다.
일반화 관계
일반적인 사물과 구체적인 사물 간의 관계이다.
일반적인 개념을 부모, 구체적인 개념을 자식이라고 한다.
실체화 관계
사물이 해야하는 기능을 정의한 사물(인터페이스)와 그것을 구현하는 사물(구현체) 사이의 관계입니다.
의존 관계
이용자와 서비스 제공자의 관계이다.
이용자가 서비스를 이용하는 일정한 시간동안 연결이 유지된다고 한다.
간단한 실습(2)
여기서도 간단한 실습을 하나 진행해보았다.
UML에서 클래스 또는 객체간의 관계는 위에 써놓은 6가지로 분류되니 그 관계들을 직접 그려보았다.
연관관계
연관관계에는 기타와 앰프를 적어두었다.
이 둘은 연주를 위해서라면 서로가 서로를 필요로 하기 때문이다.
집합관계
집합관계에는 전체에는 밴드(Band)를 부분에는 드럼과 기타를 적어두었다.
전체와 부분의 관계이며 드럼과 기타는 서로 독립적이기 때문이다.
포함 관계
포함관계에는 전체에는 기타를 부분에는 넥과 바디, 기타줄을 적었다.
전체와 부분 관계이지만 넥과 바디, 기타줄을 서로가 없으면 독립될 수 없고 생명주기를 함께하기 때문이다.
일반화
일반화에는 부모를 기타, 자식을 스트랫과 텔레케스터를 적어두었다.
일반적인 개념인 기타를 구체적인 종류로 나눈 것이다.
실체화
실체화에는 인터페이스에는 오버드라이브와 퍼즈를 사물에는 멀티이펙터를 적었다.
오버드라이브과 퍼즈라는 이펙터(인터페이스)를 사용하기 위해서라면 그것을 구현하는 사물인 멀티이펙터(구현체)가 꼭 필요하기 때문이다.
의존 관계
의존관계에는 연주자와 악기를 적어두었다.
악기는 연주자가 없으면 소리를 내지 못하고 연주자도 악기가 없다면 연주를 진행할 수 없기 때문이다.
이렇게 관계 다이어그램을 내가 관심있어하는 주제를 통해 직접 그려보는 활동을 해보니 이해가 훨씬 빠르게 되는 거 같다.
코딩을 할 때 이런 다이어그램을 통해 작업을하게 된다면 전체 구조와 관계를 한 눈에 보기 쉬워질 거 같다.
그렇게 된다면 문제를 빨리 발견하게 되고 유지보수에도 큰 도움이 될 것 같다.
