오늘은 객체지향에 대해 공부를 해보았다. 오늘 공부한 내용은 크게 2가지이다.
처음으로 공부한 것은 객체지향의 4대 특성에 대해 공부를 했다.
객체지향의 4대 특성에는 캡슐화, 상속, 다형성, 추상화 4가지로 구성되어 있다. 공부를 하면서 간단하게 필기했던
내용을 적어볼 예정이다.
우선 캡슐화에 대한 설명이다.
캡슐화란 객체의 속성을 보호하기 위해서 사용 한다.
객체의 캡슐화는 현실 세계에서도 볼 수 있는데 컴퓨터 본체 안에 수 많은 부품이 있지만 전원을 켜기 위해서는 메인보드에 전기 신호를 직접 주는 것이 아닌 외부 케이스에 있는 전원 버튼을 통해서 상태 속성을 On/Off하도록 변경 한다.
다음은 Method 설계에 대한 설명이다.
1. 속성이 선언되었으나 이의 상태를 변경하는 method가 없다면 잘못 선언된 속성이다.
즉 자신이 가지고 있는 속성에 대해서는 해당 상태를 변경하는 기능을 제공해야 한다.
2. 실물 객체가 가진 기능을 모두 제공 해야 한다. 예를 들면 자동차의 렌탈, 반납, 주행거리 계산 등등
3. 각각의 Method는 서로 관련성이 있어야 한다.
차량의 렌탈이 있으면 반납, 자동차 등록증 등록이 있으면 해지 등 각 속성의 상대 되는 기능을 제공해야 한다.
4. 객체 안의 Method는 객체 안의 속성을 처리해야 하며 다른 객체를 전달받아 해당 다른 객체에 정의 된 속성을 직접 처리 하면 안 된다.
단 Method에 실행에 필요한 값들은 객체의 형태가 아닌 매개변수의 형태로 전달되어져야 한다.
다음은 Method 속성에 대한 설명이다.
Getter / Setter Method - 외부에서 내부 속성에 직접 접근 하는 것이 아닌 Getter / Setter Method를 통해서 접근하도록 적용
CRUD Method - 데이터 처리를 위한 기본적인 CRUD Method를 제공
Business Logic Method - 비지니스 로직 처리를 위한 Method를 제공
객체의 생명 주기 처리 Method - 흔히 destroy( ), disconnect( ) 등 quit( )등 소멸에 대한 method
객체의 영구성 관리 Method - 영구성 속성에 대한 변경이 필요한 경우 외부에서는 접근이 불가능 하도록 private로 선언하며 내부의 다른 Method를 통해서 사용 되도록 한다.
Method의 속성은 반드시 1개에 속할 필요는 없으며 여러 속성에 해당 될 수 있다.
캡슐화의 장점으로는 크게 2가지가 있다.
첫번째 객체 지향의 패러다임 중 하나인 추상화를 제공한다.
실제로 Method가 어떻게 동작하는지는 외부에서는 이해할 필요가 없으며 이를 단순 호출만으로 해당 기능을 실행 할 수 있고 이를 통해서 객체 단위로 프로그램 설계가 가능하다.
두번째 재 사용성 향상
한 객체에 관련된 속성 및 Method는 모두 캡슐화의 형태로 제공됨으로 객체의 모듈성과 응집도가 높아진다. 이를 통하여 재 사용성이 높아진다.
만일 절차적 프로그래밍에서 Method를 재사용한다면 함수가 참조하고 있는 전역변수 및 내부에서 호출하는 Method가 미치는 영향을 모두 체크 해야 하나 객체의 경우는 단일 객체에만 영향을 주기에 재 사용성이 높다.
앞선 이유로 인하여 유지보수의 효율성이 향상 된다.
다음은 상속에 대한 설명이다.
상속이란 객체지향에서의 상속은 속서으이 상속이 아닌 하위로 내려갈 수록 구체화 되는 것이다.
상속의 효가로는 크게 4가지이다.
1. 프로그램 구조에 대한 이해도 향상 - 최상위 클래스의 구조를 보고 하위 클래스의 동작을 이해 할 수 있다.
2. 재사용성 향상 - 상속을 이용하여 해당 클래스에 필요한 속성 및 메소드를 모두 정의 하지 않고 상속을 받아서 사용 할 수 있다.
3. 확장성 향상 - 일관된 형태의 클래스 객체를 추가 할 수 있어 간단하게 프로그램 확장이 가능하다. ex) 신규 유닛
4. 유지보수성 향상 - 각 객체마다 자신의 메소드를 정의 하고 있다면 코드 수정에서 많은 작업이 필요 하지만
상속을 사용한 경우 일관된 형태로 작성이 가능하다.
다음은 다형성에 대한 설명이다.
다형성이란 다형성은 하나의 개체가 여러 개의 형태로 변화 하는것을 말하며 이를 객체지향 에서도 유사하게 사용을 하고 있다.
다형성을 하기 위해서는 오버라이딩을 통해서 가능 하다.
다음은 추상화에 대한 설명이다.
객체지향에서의 추상화는 모델링 이다.
구체적으로 공통적인 부분 또는 특정 특성을 분리해서 재조합 하는 부분이 추상화 이다.
앞에서 배운 다형성 상속 모두 추상화에 속한다.
오늘배운 2가지 중 2번째 내용으로 객체지향 설계 5원칙 SOLID에 대한 설명이다.
객체지향 설계 5원칙 SOLID에 들어가기에 앞서 응집도와 결합도에 대해 먼저 설명하겠다.
좋은 소프트웨어 설계를 위해서는 결합도는 낮추고 응집도는 높여야 한다.
결합도 - 모듈간의 상호 의존 정도를 나타내는 지표로써 결합도가 낮으면 모듈간의 상호 의존성이 줄어들어 객체의 재사용 및 유지보수가 유리하다.
응집도 - 하나의 모듈 내부에 존재하는 구성 요소들의 기능적 관련성으로 응집도가 높은 모듈은 하나의 책임에 집중하고 독립성이 높아져
재사용 및 유지보수가 용이하다.
이제 본격적인 객체지향 설계 5원칙 SOLID에 대해 설명을 하겠다.
1. SRP (Single Responsibility Principle) 단일 책임 원칙
어떠한 클래스를 변경해야 하는 이유는 한가지 뿐 이여야 한다.
단일 책임 원칙의 절차지향 코드와 객체지향 코드이다.
왼쪽 코드가 절차지향 오른쪽 코드가 객체지향 코드이다.
2. OCP (Open Closed Principle) 개방 폐쇄 원칙
자신의 확장에는 열려 있고 주변의 변화에 대해서는 닫혀 있어야 한다.
상위 클래스 또는 인터페이스를 중간에 둠으로써 자신은 변화에 대해서는 폐쇄적이지만 인터페이스는
외부의 변화에 대해서 확장을 개방해 줄 수 있다.
이러한 부분은 JDBC 와 Mybatis, Hibernate 등 JAVA에서는 Stream( Input, Out) 에서 찾아볼 수 있다.
OCP 개방 폐쇄 원칙의 예시 그림이다.
3. LSP (Liskov Substitution Principle) 리스코프 치환 원칙
서브 타입은 언제나 자신의 기반(상위) 타입으로 교체 할 수 있어야 한다.
4. ISP (Interface Segregation Principle) 인터페이스 분리 원칙
클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다.
프로젝트 요구 사항과 설계에 따라서 SRP(단일책임원칙) / ISP(인터페이스분리원칙)를 선택한다.
5. DIP (Dependency Inversion Principle) 의존 역적 원칙
자신보다 변하기 쉬운 것 에 의존하지 말아야 한다.
오늘 배운 내용은 여기까지 이다.
객체지향에 대해서 대학교 수업에도 배워봤지만 아직 배울 것이 많다라는 것을 느꼈다,,,
그래도 공부를 하고 블로그 까지 작성했다는 점에서 뿌듯하고 나도 모르게 재미를 느끼고 있어 나쁘지 않았던거 같다.
다음 시간에는 디자인 패턴에 대해 공부할 예정이다.
그럼 20000!!