ݺߣ

ݺߣShare a Scribd company logo

Tcpl 12장 파생클래스

•
•
재
재정 이

the c++ programming language presentation file

1 of 30
Download to read offline
The C++ Programming Language 12장 파생클래 스 모임명: 아꿈사 이재정 https://github.com/jjuiddong/TCPL
파생 클래스 ● Employee (노동자) ● Manager (관리자) 공통 정보 ● 이름 ● 입사 날짜 ● 부서 관리자 정보 ● 관리 하고 있는 직원정보
공통된 정보는 Employee 클래스로 묶고, 나머지 정보들은 파생해서 구현한다. Employee Manager
상속 1. 상속 받으면 부모 클래스로 부터 모든 정보를 얻게 된다. 단 public 상속일 때만. 2. 부모의 private 구역은 접근 할 수 없다. 3. protected, private 상속도 가능하나, 대부분 public 상속을 한다.
파생된 클래스의 생성자와 소멸자 1. 생성자는 부모 클래스가 먼저 호출되고, 파생 클래스가 호출된다. 2. 소멸자는 그 반대다. 단, 가상 소멸자 함수로 선언했을 경우만 그렇다.
Tcpl 12장 파생클래스
파생클래스 복사 다른 클래스 계통끼리 복사할 때 주의하자. 복사 손실이 발생 할 수 있다.
Tcpl 12장 파생클래스
클래스 하이어라키 클래스 계통은 방향성 비순환 그래프 구조라고 알려져있다.
Tcpl 12장 파생클래스
Tcpl 12장 파생클래스
Tcpl 12장 파생클래스
클래스 계통이 순환되면 컴파일이 불가능 하다.
가상함수 따라하기 클래스 별로 타입을 주어서 switch case 문으로 함수를 호출한다.
가상함수의 장점 유지보수가 수월하다. ● 프로그램 전체에 영향을 미치는 코드를 건드리지 않 고, 필요한 부분만 수정할 수 있다. 확장성 ● 인터페이스만 같다면, 어떤 클래스가 파생되더라도 기존 프로그램에 쉽게 붙일 수 있다.
추상 클래스 인스턴스를 생성할 수 없는 클래스 파생해서 구현해야 하는 클래스 인터페이스를 제공하기 위한 용도
클래스 계통 설계 하향식 구조 문제점 - 최상위 클래스가 커질수록 유연성이 떨어진다.
하향식 구조 설계
문제점: 1. BBwindow 는 Ival_box의 상위개념이 아니다. 2. BBwindow 와 Swing 등의 UI 라이브러리를 두개 이상 사용해야 한다면 복잡해 진다.
문제점: ● BBwindow, CWwindow, IBwindow, LSwindow 각각의 라 이브러리로 전환 될때 마다 거의 모든 프로그램이 리빌 드 된다. ● 두개 이상의 라이브러리를 동시에 사용 할 수 없다.
추상 클래스 활용 원칙 1. 인터페이스와 구현 세부사항은 떨어뜨리자. 2. 인터페이스에 데이타를 두지말자. 데이타가 있으면 의존성이 생긴다. 3. 구현 세부를 수정하더라도 Ival_Box 계열의 클래스는 컴파일되지 않게 하자. 4. 다중 UI 시스템이 동작되게 하자.
Ival_box interface int get_value() = 0; void set_value(int i) = 0; void reset_value(int i) = 0; void prompt() = 0; bool was_changed() = 0;
자~ 어떻게 할까요? It's Your Turn
조금만 더 생각해봐요
BBwindow, CWwindow 의 slider 역할을 하는 클 래스가 있을 때
최종본 개인적인 생각: 상속이 너무 많다. 다중 상속 때문에 클래스 계통이 복잡하 다. 여전히 컴파일 타임이 길어질 수 있다.
객체 생성 위치를 국한시키기 factory 클래스 상속으로 구현하지 않고, 다른 방식으로 구현할 수 있다는 것을 잠깐 눈요기로 보여준다. 이에 대한 자세한 내용은 뒤에 나올거라 생각한 다. 아니면 템플릿이 그 해결책이라고 생각하는 지도~
바른 프로그래밍을 위한 고수의 조언 1. 타입필드는 반드시 피할 것. 2. 복사손실(slicing)을 피하려면 객체의 포인터 혹은 참조 자를 사용해야 한다. 3. 깔끔한 인터페이스 제공에 목적을 두고 있다면 추상 클 래스를 사용하자. 4. 인터페이스를 최소화하려면 추상 클래스를 사용하자. 5. 인터페이스로부터 구현 세부사항을 차단하려면 추상 클 래스를 사용하자. 6. 사용자 코드를 건드리지 않은 채로 기존 함수의 구현코 드를 새로 추가하려면 관련 함수들이 가상 함수로 되어 있어야 한다.
7. 사용자 코드의 재컴파일을 최소화하려면 추상 클래스를 사용하자. 8. 구현 세부사항이 여러개가 될 수 있는 경우를 허용하려면 역시 추상 클래스를 사용할 것. 9. 가상 함수를 가진 다형성 클래스에는 반드시 가상 소멸자가 있어야 한다. 10. 추상 클래스에는 대개 생성자가 필요없다. 11. 겹치지 않는 개념들은 내부 표현 데이터도 반드시 분리해 놓도록 하자.
END

More Related Content

Tcpl 12장 파생클래스

  • 1. The C++ Programming Language 12장 파생클래 스 모임명: 아꿈사 이재정 https://github.com/jjuiddong/TCPL
  • 2. 파생 클래스 ● Employee (노동자) ● Manager (관리자) 공통 정보 ● 이름 ● 입사 날짜 ● 부서 관리자 정보 ● 관리 하고 있는 직원정보
  • 3. 공통된 정보는 Employee 클래스로 묶고, 나머지 정보들은 파생해서 구현한다. Employee Manager
  • 4. 상속 1. 상속 받으면 부모 클래스로 부터 모든 정보를 얻게 된다. 단 public 상속일 때만. 2. 부모의 private 구역은 접근 할 수 없다. 3. protected, private 상속도 가능하나, 대부분 public 상속을 한다.
  • 5. 파생된 클래스의 생성자와 소멸자 1. 생성자는 부모 클래스가 먼저 호출되고, 파생 클래스가 호출된다. 2. 소멸자는 그 반대다. 단, 가상 소멸자 함수로 선언했을 경우만 그렇다.
  • 7. 파생클래스 복사 다른 클래스 계통끼리 복사할 때 주의하자. 복사 손실이 발생 할 수 있다.
  • 9. 클래스 하이어라키 클래스 계통은 방향성 비순환 그래프 구조라고 알려져있다.
  • 13. 클래스 계통이 순환되면 컴파일이 불가능 하다.
  • 14. 가상함수 따라하기 클래스 별로 타입을 주어서 switch case 문으로 함수를 호출한다.
  • 15. 가상함수의 장점 유지보수가 수월하다. ● 프로그램 전체에 영향을 미치는 코드를 건드리지 않 고, 필요한 부분만 수정할 수 있다. 확장성 ● 인터페이스만 같다면, 어떤 클래스가 파생되더라도 기존 프로그램에 쉽게 붙일 수 있다.
  • 16. 추상 클래스 인스턴스를 생성할 수 없는 클래스 파생해서 구현해야 하는 클래스 인터페이스를 제공하기 위한 용도
  • 17. 클래스 계통 설계 하향식 구조 문제점 - 최상위 클래스가 커질수록 유연성이 떨어진다.
  • 19. 문제점: 1. BBwindow 는 Ival_box의 상위개념이 아니다. 2. BBwindow 와 Swing 등의 UI 라이브러리를 두개 이상 사용해야 한다면 복잡해 진다.
  • 20. 문제점: ● BBwindow, CWwindow, IBwindow, LSwindow 각각의 라 이브러리로 전환 될때 마다 거의 모든 프로그램이 리빌 드 된다. ● 두개 이상의 라이브러리를 동시에 사용 할 수 없다.
  • 21. 추상 클래스 활용 원칙 1. 인터페이스와 구현 세부사항은 떨어뜨리자. 2. 인터페이스에 데이타를 두지말자. 데이타가 있으면 의존성이 생긴다. 3. 구현 세부를 수정하더라도 Ival_Box 계열의 클래스는 컴파일되지 않게 하자. 4. 다중 UI 시스템이 동작되게 하자.
  • 22. Ival_box interface int get_value() = 0; void set_value(int i) = 0; void reset_value(int i) = 0; void prompt() = 0; bool was_changed() = 0;
  • 23. 자~ 어떻게 할까요? It's Your Turn
  • 25. BBwindow, CWwindow 의 slider 역할을 하는 클 래스가 있을 때
  • 26. 최종본 개인적인 생각: 상속이 너무 많다. 다중 상속 때문에 클래스 계통이 복잡하 다. 여전히 컴파일 타임이 길어질 수 있다.
  • 27. 객체 생성 위치를 국한시키기 factory 클래스 상속으로 구현하지 않고, 다른 방식으로 구현할 수 있다는 것을 잠깐 눈요기로 보여준다. 이에 대한 자세한 내용은 뒤에 나올거라 생각한 다. 아니면 템플릿이 그 해결책이라고 생각하는 지도~
  • 28. 바른 프로그래밍을 위한 고수의 조언 1. 타입필드는 반드시 피할 것. 2. 복사손실(slicing)을 피하려면 객체의 포인터 혹은 참조 자를 사용해야 한다. 3. 깔끔한 인터페이스 제공에 목적을 두고 있다면 추상 클 래스를 사용하자. 4. 인터페이스를 최소화하려면 추상 클래스를 사용하자. 5. 인터페이스로부터 구현 세부사항을 차단하려면 추상 클 래스를 사용하자. 6. 사용자 코드를 건드리지 않은 채로 기존 함수의 구현코 드를 새로 추가하려면 관련 함수들이 가상 함수로 되어 있어야 한다.
  • 29. 7. 사용자 코드의 재컴파일을 최소화하려면 추상 클래스를 사용하자. 8. 구현 세부사항이 여러개가 될 수 있는 경우를 허용하려면 역시 추상 클래스를 사용할 것. 9. 가상 함수를 가진 다형성 클래스에는 반드시 가상 소멸자가 있어야 한다. 10. 추상 클래스에는 대개 생성자가 필요없다. 11. 겹치지 않는 개념들은 내부 표현 데이터도 반드시 분리해 놓도록 하자.
  • 30. END