1. 클래스
2. 캡슐화와 은닉성
3. 상속과 추상클래스
4. 다형성
5. 생성자와 오버로드 / 오버라이드
6. 객체지향 프로그램의 설계원칙
클래스의 정의 - 객체를 정의해 놓은것. (붕어빵 틀)
클래스의 용도 - 객체를 생성하는데 사용.
그렇다면 객체는 무엇인가?
- 실제로 존재하는것, 사물 또는 개념 모든것이 객체.
객체의 용도는 각각의 기능과 속성에 따라 다름.
(기능 = 메소드) (속성 = 변수)
오버로딩 - 이름은 같지만, 매개변수는 다름
오버라이딩 - 이름도 같고 매개변수도 같아야함. 부모클래스에게 상속받는경우 사용.
- 다형성의 정의 : 여러가지 형태를 가질수 있는 능력
1.부모객체에 자식객체를 담을수 있음.
2.참조변수의 형변환
하나의 참조변수로 여러 타입의 객체를 참조할 수 있는 것.
즉, 조상타입의 참조변수로 자손타입의 객체를 다룰 수 있는 것이 다형성.
**반대로 자손타입의 참조변수로 조상타입의 인스턴스를 참조할 수는 없다.
ex) List list = new ArrayList();
- 인터페이스는 추상메서드만... 즉 메서드의 껍데기만 정의할 수 있다는 것이 본질입니다.
인터페이스는 KS표준 규격과 같이... 정형화된 규칙, 약속을 정의하는데 사용됩니다.
구현을 노출시키지 말고 기능만 선언적으로 외부에 알려라는 의미겠죠.(은닉)
IoC/DI 때문입니다 (Inversion of Control / Dependency Injection) 인터페이스로
서로 기능적으로 의존하고 의존 받는 클래스와 클래스의 관계를 유연하게 해주고 이 사이에서 의존적 관계를 컨트롤해주는 컨테이너를 삽입하기 때문이죠.
전략패턴이라고 하여 디자인 패턴 중에서도 가장 완성도 있는 패턴으로 유명합니다.
- 추상메서드는 미완성된 설계도입니다. 클래스는 클래스인데... 완성되지 않은 부분이 있는 것이지요.
추상클래스는 완성된 클래스로 가는 중간단계이고
- 캡슐화 은닉화
'객체 = 속성 + 기능'으로 이루어져있습니다.
속성은 보편적으로 이야기하는 필드 등을 이야기하구요..
기능은 메소드 등이라고 표현합니다.
그 '속성'에 해당하는 사항들을 private 키워드로 숨겨놓고,
'기능'에 해당하는 메소드를 public 키워드를 이용해서 접근하도록 하는것이 캡슐화입니다.
- 절차 지향과 객체 지향(P.155)
① 절차 지향 : 프로그램의 절차대로 프로그램이 진행된다
② 객체 지향 : 객체들을 한데 묶어 서로 상호작용하여 프로그램이 진행된다
⒜ 장점
1. 유지보수 용이 : 객체의 클래스를 알지 못하더라도 사용법만 알면 된다.
2. 코드 재사용 : 같은 동작의 코드를 다시 만들 필요없이 추가만 하면 된다.
3. 정보은닉 : 정보를 은닉하는 역할 이외에도 라이브러리의 업그레이드가 쉽게 해준다.
4. 디버깅 용이
⒝ OOP(Object Oriented Programming : 객체 지향 프로그래밍) 특징
1. 추상화(Abstraction) : 데이터와 기능을 추출하는 것(abstract 키워드)
2. 캡슐화(encapsulation) : 데이터와 기능을 묶어 하나로 만드는 것으로 사용자는 사용법만 인지
3. 정보은닉(information hiding) : 멤버변수에 대한 접근의 제한으로 은닉(접근제어지시자), 데이터의 인출과
저장을 분리(getting과 setting)
4. 상속(inheritance) : 상위 클래스와 하위 클래스로 구분하여 재사용성, 유연성 증가(exteds 키워드)
5. 다형성(polymorphism) : 상위 클래스 아래의 여러 하위 클래스로 연결되어(binding) 여러 형태를 가짐
(interface), 클래스의 같은 기능의 메소드를 여러형태로 구현(overloading, overriding)
※ 바인딩(binding) : 상위클래스, 하위클래스들끼리 연결된 형태
어플리케이션은 변경되지 않는부분과, 변경되는부분을 분리시킨다.
변경되지 않는 공통된부분을 묶고, 바뀌거나 확장의 가능성이 있는 부분을 캡슐화한다.
확장의 가능성이 높다면 외부와의 계약을 의미하는 인터페이스를 정의하여
구체 클래스 대신 인터페이스에 의존하도록한다
이렇게되면 수정에는 닫혀 있고 확장에는 열려 있는 구조가 된다(OCP-개방 폐쇄의 원칙).
객체지향 원칙
1. 바뀌는 부분은 캡슐화 한다.
2. 상속보다는 구성을 활용한다.
3. 구현이 아닌 인터페이스에 맞춰서 프로그래밍 한다.
4. 서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다.
5. 클래스는 확장에 대해서는 열려있지만 변경에 대해서는 닫혀 있어야 한다.(OCP)
6. 추상화된 것에 의존하라! 구상 클래스에 의존하지 않도록 한다.
7. 친한 친구들하고만 이야기 한다.(최소 지식 원칙)
8. 먼저 연락하지 마세요! 저희가 먼저 연락드리겠습니다. (수퍼클래스에서 모든 것을 관리하고 필요한 서브클래스를 불러서 써야 된다는 원칙입니다.)
-단일 책임 원칙(SRP)
첫 번째 원칙은 '단일 책임 원칙(SRP; Single Responsibility Principle)'이다.
이는 객체는 단 한 개의 책임(역할)만을 가져야 한다는 내용으로, 객체를 변경해야 하는 이유는 단 하나여야 한다는 원칙이다.
-의존 역전 원칙(DIP)
의존 역전 원칙(Dependency Inversion Principle)은 구현 클래스가 아닌 인터페이스 타입을 사용하라는 규칙이다.
-개방 폐쇄 원칙(OCP)
개방 폐쇄 원칙(Open-Closed Principle)은 특정 클래스(또는 모듈 등)는 그 클래스를 수정하지 않으면서 확장(extension) 가능해야 한다라는 원칙이다.
'Other > OOP' 카테고리의 다른 글
헤드퍼스트 디자인패턴 (0) | 2012.10.08 |
---|---|
interface 를 왜 사용하는가 (0) | 2012.09.14 |