Transcript 객체 지향 프로그래밍

2010 Object-Oriented Programming by Lacti
객체 지향 프로그래밍
(feat doodori2)
객체 지향 프로그래밍
• 내가 하는 이야기는 아니고 …
• Blog 2 Book 책 짱 좋음
– 그 중 이 책이 젤 좋음
객체 지향 프로그래밍
• 설계의 중요성
• 베스트 1위 직업 : 소프트웨어 아키텍트
http://bobbyryu.blogspot.com/2010/10/1.html
• 그러나 설계를 배우는 수업은 없다?
• 소프트웨어 공학 을 듣자.
목차 (스포주의)
1. 코드의 가치
2. C로 개발하면 안되나요
3. 공통점 묶기, 조금만 알기
객체지향의 원칙 (SOLID)
4. 다중 상속과 인터페이스`
5. 체계적인 코드 정리
6. 패턴은 단지 이름에 불과하다
2010 Object-Oriented Programming by Doodoori2
1. 코드의 가치
1. 코드의 가치
• 구구단을 출력하는 프로그램
– 5 단을 출력하세요
1. 코드의 가치
프로그램 1
printf(“%d
printf(“%d
printf(“%d
printf(“%d
printf(“%d
*
*
*
*
*
%d
%d
%d
%d
%d
=
=
=
=
=
%d\n”,5,1,5);
%d\n”,5,2,10);
%d\n”,5,3,15);
%d\n”,5,4,20);
%d\n”,5,5,25);
1. 코드의 가치
프로그램 2
int i;
for (i = 1 ; i <= 5 ; i++ ) {
printf(“%d * %d = %d\n”,5,i,5);
}
1. 코드의 가치
프로그램 3
class gugudan
{
public:
void run(int dan) {
int i=0;
for(i=1; i<= dan; i++) print_format (dan, i );
}
void print_format(int op1, int op2) {
printf(“%d * %d = %d\n”,op1,op2,op1*op2);
}
}
gugudan gugu;
gugu.run(5);
1. 코드의 가치
이게 뭐야 =_=
셋 다 하는 일은 똑같은데
class 문법도 가물가물 하고
코드만 길어지고
짜는데 오래 걸리고 ….
function만 잘 해도 되겠네요.
OOP 언어 말고 functional 언어나 하러 갈래요
LISP 졸라 짱 임. 안 써봤으면 말을 마셈 :P
1. 코드의 가치
그래서 세미나가 끝났다.
슬라이드 쇼가 끝났습니다. 끝내려면 마우스를 클릭하십시오.
슬라이드 쇼가 끝났습니다. 끝내려면 마우스를 클릭하십시오.
1. 코드의 가치
좀 더 그럴싸한 낚시가 있으면 좋을 텐데
1. 코드의 가치
요구 사항은 바뀐다.
끊임 없이 바뀐다.
추가도 되고 없어지기도 한다
1. 코드의 가치
그리고 고객 & 기획자들은
말하지 않은 사항까지
다 알아서 잘
구현해 줄 것이라 믿는다.
1. 코드의 가치
프로토 타입이 완성되고 나서야
– 왜 이런 건 안 되나요?
– 상식적으로 당연히 이래야 되는 거 아닌가요?
– 내부 구현은 모르겠지만 이랬으면 좋겠어요.
1. 코드의 가치
1. 코드의 가치
• 구구단을 출력하는 프로그램
– 5 단을 출력하세요
– n 단을 출력해주세요
– n 단의 범위를 1 ~ 100으로 한정해주세요
: 0 이나 음수는 에러를 내주세요
– 입력했던 단을 기억하고 출력하게 해주세요
– 출력하고 나면 다시 처음부터 기억해주세요
– 그냥 죽으세요 ㅇㅇ
1. 코드의 가치
• 유지보수 >>>>>>>>>>>> 개발
더
더
더
더
중요하고
많은 시간이 들어가고
많은 노력이 필요하고
높은 실력이 필요하다.
1. 코드의 가치
객체지향이 무엇인지 사전적으로 암기하기 보다는
왜 이런 모양의
코드 형태
가 만들어진 것일까?
2010 Object-Oriented Programming by Doodoori2
2. C로 짜면 안되나요
2. C로 짜면 안되나요
• 됩니다.
• C로 OS도 만들고요. 게임도 만들고요.
• 이건 사실 비밀인데
assembly로도 OS 만들 수 있어요.
• ’OS 구조와 원리 30일 완성’ 이란 책에서는
무려 binary 편집기로 OS 만든다는.. FF 0A 0D ….
2. C로 짜면 안되나요
• 그림은
메모장에서 그릴 수도 있고요
그림판에서 그릴 수도 있고요
포토샵에서 그릴 수도 있고요
일러스트에서 그릴 수도 있지요.
2. C로 짜면 안되나요
• 막간을 이용한 재능낭비현장.jpg
2. C로 짜면 안되나요
• 개발 방법의 기본
– 개발을 체계적으로 진행할 수 있는가?
– 개발하기 쉬운가?
– 관리하기 쉬운가?
– 확장이 쉬운가?
– 안정적인가?
• 여러 번 강조 하지만
C++ or OOP가 무조건 정답은 아니다
2. C로 짜면 안되나요
• C로 만든 String buffer
typedef struct _ST_STRBUF {
int m_nLen;
// string 길이
char * m_pStr; // string Pointer
} ST_STRBUF, * PST_STRBUF;
2. C로 짜면 안되나요
// a_nStrLen 만큼 a_pstStr 구조체를 초기화한다.
int mystr_new (ST_STRBUF* a_pstStr, int a_nSTRLen);
// 문자열 a_pStr을 a_pstStr의 문자열에 할당함
int mystr_assign (ST_STRBUF* a_pstStr, char* a_pStr);
// 문자열 a_pStr을 a_pstStr의 문자열 뒤에 덧붙임
int mystr_append (ST_STRBUF* a_pstStr, char* a_pStr);
// a_pstStr에서 문자 a_chFind를 찾는다
int mystr_find(ST_STRBUF* a_pstStr, char a_chFind);
// a_pstStr을 삭제한다
int mystr_delete (ST_STRBUF* a_pstStr);
2. C로 짜면 안되나요
int main ()
{
ST_STRBUF stStrBuf = {0,};
mystr_new (&stStrBuf, 256);
mystr_assign(&stStrBuf, “abc”);
mystr_append(&stStrBuf, “def”);
mystr_find(&stStrBuf, ‘a’);
mystr_delete(&stStrBuf);
return 0;
}
2. C로 짜면 안되나요
int main ()
{
ST_STRBUF stStrBuf = {0,};
mystr_new (&stStrBuf, 256);
// mystr_new 를 제대로 호출 해주지 않으면
// 아래 모든 함수는 정상 동작을 하지 못할 것이다.
mystr_assign(&stStrBuf, “abc”);
mystr_append(&stStrBuf, “def”);
mystr_find(&stStrBuf, ‘a’);
mystr_delete(&stStrBuf);
return 0;
}
2. C로 짜면 안되나요
int main ()
{
ST_STRBUF stStrBuf = {0,};
mystr_new (&stStrBuf, 256);
mystr_assign(&stStrBuf, “abc”);
mystr_append(&stStrBuf, “def”);
// mystr_assign 으로 문자열을 할당해주지 않으면 잘못된 동작을 수행함
// 문자인지 문자열인지도 문제 !!
mystr_find(&stStrBuf, ‘a’);
mystr_delete(&stStrBuf);
return 0;
}
2. C로 짜면 안되나요
int main ()
{
ST_STRBUF stStrBuf = {0,};
mystr_new (&stStrBuf, 256);
mystr_assign(&stStrBuf, “abc”);
mystr_append(&stStrBuf, “def”);
mystr_find(&stStrBuf, ‘a’);
// 메모리 해제 시점도 항상 문제
mystr_delete(&stStrBuf);
return 0;
}
2. C로 짜면 안되나요
• C++로 만든 String Class
Class CMyString {
public :
int Assign(char * a_pStr);
int Append(char * a_pStr);
int Find(char a_chFind);
CMyString (int a_nSize);
~CMyString ();
private:
int m_nLen;
char * m_pStr;
};
2. C로 짜면 안되나요
int main ()
{
CMyString str(256);
str.Assign(“abc”);
str.Append (“def”);
str.Find (‘a’);
return 0;
}
2. C로 짜면 안되나요
• 일단 코드 자체가 명료해졌다.
• 앞선 문제점들을 class 내부에서 해결
• 잘못된 동작을 수행할 가능성이 줄어듦.
2. C로 짜면 안되나요
• C는 기존 프로그래밍의 단점을 혁신적으
로 보강해 나온 언어였다.
• C++ , Java 역시 기존 C 언어 등 구조적
프로그래밍이 가지는 단점을 보완하면
서 더 큰 프로그램을 개발하는데 적합한
개념과 여러 가지 언어적 지원이 덧붙여진
연구와 경험의 산물
2. C로 짜면 안되나요
• 이후 내용에 대해서는
cpp 기준으로 설명될 수 있도록
최대한 노력하겠지만
• 나는 cpp 도 java 도 헷갈리는
PHP 웹 프로그래머 이므로...
• 대부분의 예제가 java로 되 있어서 귀찮아
넘어가기 전에 용어 설명
•
•
•
•
Struct { (다를)이 항 자료 집합 }
Class { struct + function (method) }
Instance
Keyword : 색깔 나는 글자
(in programming language)
• public , private (protected)?
• function , method
• virtual, abstract, interface ,
(pure abstract class )
무엇이든 물어보세요
• 나 말고 google 에 ...
• 내가 여기서 짖고 있는 이유
• 바보 같은 질문은 없다
• 知之爲知之 不知爲不知 是知也
• 세미나 끝나고 시험 봄
2010 Object-Oriented Programming by Doodoori2
03. 공통점 묶기, 조금만 알기
3. 공통점 묶기, 조금만 알기
• 보통 객체지향에 대해서 공부를 하면
– 추상화
– 캡슐화
– 상속
– 다형성
– 정보은닉
• 중요한 개념이지만,
그 개념을 필요로 하게 된
이유에 대해서 이해하려고 해야 한다.
3. 공통점 묶기, 조금만 알기
• 책에서는 공통점 묶기, 조금만 알기
– 필요에 의한 상속
– 필요에 의한 다형성
– 필요에 의한 캡슐화
• 이 책에서는 쉽게 설명하려 노력했지만...
• SOLID 원칙 이라는 것이 있다.
2010 Object-Oriented Programming by Doodoori2
03++. 객체지향의 원리 SOLID
객체지향의 원리 SOLID
• SRP(Single Responsibility Principle)
– 단일 책임의 원칙
• OCP(Open-Closed Principle)
– 개방-폐쇄 원칙
• LSP(Liskov Substitution Principle)
– 리스코프 교체 원칙
• ISP(Interface Segregation Principle)
– 인터페이스 격리 원칙
• DIP(Dependency Inversion Principle)
– 의존 관계 역전 원칙
개방-폐쇄 원칙 (OCP)
• 확장에 대해서는 열려 있고
• 변경에 대해서는 닫혀있다
Ex 정통부에서 휴대폰 충전기 24핀을 발표


충전기를 여러 기기들이 쓰는 확장에는 Open
충전 핀은 공통적으로 변하지 않도록 Close
개방-폐쇄 원칙
•
프로그램 (Client) 에서 파일로 부터 입력 받는 시스템
개방-폐쇄 원칙
•
•
•
•
프로그램 (Client) 에서 파일로 부터 입력 받는 시스템
사용자 입력으로 받기도 하고
코드 내에 string으로 집어 넣기도 하고
pipe 라인으로 .. 등등
개방-폐쇄 원칙
•
•
•
입력 input stream 으로 통일
여러 input 방식의 확장에는 열려 있고
encode() read() 라는 기능은 고정 (폐쇄) 되어 있다.
개방-폐쇄 원칙
• 주의점
– 시스템이 지저분해 지기도 한다
– 공통 영역 크기의 문제
– 한번 통일된 Interface 는 변경하기 힘들다
– 구체적인 행위를 파악하기가 어렵다
단일 책임의 원칙 (SRP)
• 하나의 클래스는 하나의 책임만을 가진다
• 높은 응집도 낮은 결합도
단일 책임의 원칙 (SRP)
• 문제점을 파악하기도 좋고
• 문제점을 해결하기도 쉽고
• 새로운 구현을 하기에도 좋다
• 여러 책임을 가진 class는 확장 & 변경에
큰 어려움이 있다.
단일 책임의 원칙 (SRP)
• Ex. 수륙양육자동차
 자동차와 보트를 동시에 상속했다.
 이걸로 더 나은 자동차? 보트?
단일 책임의 원칙 (SRP)
• MMORPG
– 탱커는 몸빵하고
– 딜러는 딜을 하고
– 힐러는 힐을 해야 한다.
• 수륙양육자동차
– 자동차와 보트를 동시에 상속했다.
– 이걸로 더 나은 자동차? 보트?
단일 책임의 원칙
실제로 서비스 되고 있는 코드의 사례
Online 문제풀이를 시작한다
Function start()
{
//
//
//
//
//
//
//
//
//
//
//
}
1. 사용자의 입력 값을 검사하고
2. 입력값에 해당하는 시험정보를 가져오고
3. 사용자가 문제 풀이 관리자인지 확인하고
4. 입력받은 시험ID가 유효한 확인하고
5. 해당 시험이 유료 시험은 아닌지 확인하고
6. 유료 시험이라면 결제한 사람인지 확인하고
7. 시험을 풀다가 중단한 적이 있는지 확인하고
8. 중단한 적이 있으면 이전 data를 load 하고
9. 종료한 적이 있는 시험이면 결과보기로 이동시키고
10. 문제 데이터를 읽어서 보여줄 형태로 변환 하고
11. 사용자에게 적절한 UI 를 통해 보여준다.
단일 책임의 원칙
• 다음은 SRP를 따르지 않은 클래스의 예제이다.
–
–
–
–
Car는 자신의 연료탱크를 스스로 채운다.
CreditCard는 요금을 부가하는 방법을 알고 있다.
CreditCardProcessor는 Http 요청을 하는 법을 알고 있다.
Comment는 메일을 보낸다.
– 쿠키를 만드는 클래스가 있는데
– 쿠키가 사람에게 먹히냐 먹냐
– cookie.eat();
단일 책임의 원칙
웹에서 찾은 또 다른 예제
단일 책임의 원칙
웹 검색에서 찾은 또 다른 예제
단일 책임의 원칙
• 아 설명하기 참 어렵네 =_=
• 소프트웨어 설계에는 두 가지 방법이 있다.
– 한 가지는 분명히 결함이 없도록 단순하게 설
계하는 것이고
– 다른 한 가지는 분명한 결함이 없도록 가능하
면 복잡하게 설계하는 것이다
잠깐 정리
정리 하자면,
• 객체지향의 원칙
– 개방 폐쇄의 원칙
– 단일 책임의 원칙
나머지 3개는 조금 있다가 다시 합시다
객체지향의 원리 SOLID
• OCP(Open-Closed Principle)
– 개방-폐쇄 원칙
• SRP(Single Responsibility Principle)
– 단일 책임의 원칙
• LSP(Liskov Substitution Principle)
– 리스코프 교체 원칙
• ISP(Interface Segregation Principle)
– 인터페이스 격리 원칙
• DIP(Dependency Inversion Principle)
– 의존 관계 역전 원칙
목차 (어디까지 왔나)
1. 코드의 가치
2. C로 개발하면 안되나요
3. 공통점 묶기, 조금만 알기
객체지향의 원칙 (SOLID)
4. 다중 상속과 인터페이스`
5. 체계적인 코드 정리
6. 패턴은 단지 이름에 불과하다
목차 (어디까지 왔나)
1. 코드의 가치
2. C로 개발하면 안되나요
3. 공통점 묶기, 조금만 알기
객체지향의 원칙 (SOLID)
4. 다중 상속과 인터페이스`
5. 체계적인 코드 정리
6. 패턴은 단지 이름에 불과하다
2010 Object-Oriented Programming by Doodoori2
04. 다중 상속과 인터페이스
4. 다중 상속과 인터페이스
• 상속은?
– 부모의 기능을 물려받기 위한다는 개념
• 다중 상속은?
– 부모가 여럿 이란 건가?
– 상속 받은 걸로 모자라서 호적도 갈아엎음?
– 그럼 다이아몬드 꼴은...
아빠랑 엄마가 근ㅊ…?!!
단일 책임의 원칙이 깨지게 된다 !
4. 다중 상속과 인터페이스
• Java 에서는
– 다중상속을 허용하지 않고
– 단일 상속으로 하나의 책임을 가지되
– Interface로 여러 기능을 구현하고
확장할 수 있도록 하였다.
4. 다중 상속과 인터페이스
• interface개념으로 확장해서 봐야 함
– C++ 에서는
interface 라는 keyword가 없으므로
그냥 class로 쓴다.
– virtual 로 수습하기.
• JAVA 가 C++ 보다 OOP 철학에 가깝다
는 근거 중 하나로 자주 언급됨.
4. 다중 상속과 인터페이스
• JAVA 진영
– JAVA는 OOP의 진리임. 우월한 언어임
– C++는 돼지 목에 진주 목걸이라
– JAVA는 platform도 안 따짐. MS 빠돌이 즐
• C++ 진영
– JAVA는 JVM없으면 안 돌아가고 졸 느림.
– 기존 C 코드와의 호환
– 19 금 http://q.poolc.org/freeboard/20608
4. 다중 상속과 인터페이스
• 나는 JAVA 편 ㄲㄲ
– java 문법은 다 까먹은지 오래.
• 하지만 java에서도
C 스타일로 짜는 사람이 대부분...
• 결론은, 도구가 문제가 아니라
쓰는 인간들이 문제 너님이 문제
4. 다중 상속과 인터페이스
• Interface 란?
– 경계면, 접점, 공유[접촉] 영역
– Class 들이 만나는 방법
– 음.. 그러니까 함수에 대한 구조적인 약속?
4. 다중 상속과 인터페이스
• Abstract Class는 ?
– Interface는 함수 구현을 하지 않는다.
(only 선언)
– 함수 구현이 들어가면 abstract class라 함
– 혹은 상수가 아닌 내부 변수
4. 다중 상속과 인터페이스
class 수능점수
{
public:
virtual int get_total_score();
private:
int 언,수,외,탐1,탐2,탐3,탐4;
}
4. 다중 상속과 인터페이스
class 언수외 : public 수능점수
{
virtual int get_total_score() {return 언+수+외;}
}
class 언수외탐 : public 수능점수
{
virtual int get_total_score() {return 언+수+외+탐;}
}
class 언수외탐3 : public 수능점수
{
virtual int get_total_score() {return 언+수+외
+max(탐);}
}
4. 다중 상속과 인터페이스
• 외부에서는 get_total_score() 라는
method로 통일해서 호출 가능함.
• interface를 미리 정리해두고 각각 항목을
구현하는 것이 분업에는 큰 도움이 됨.
• 솔직히 좋은 예제는 아님
2010 Object-Oriented Programming by Doodoori2
03#. 객체지향의 원리 SOLID
객체지향의 원리 SOLID
• SRP(Single Responsibility Principle)
– 단일 책임의 원칙
• OCP(Open-Closed Principle)
– 개방-폐쇄 원칙
• LSP(Liskov Substitution Principle)
– 리스코프 교체 원칙
• ISP(Interface Segregation Principle)
– 인터페이스 격리 원칙
• DIP(Dependency Inversion Principle)
– 의존 관계 역전 원칙
리코스프 교체 원칙 (LSP)
• 자식 타입들은 부모 타입들이 사용되는 곳
에 대체될 수 있어야 한다.
• 상속받는 자식 클래스는 부모 클래스의 책
임을 넘지 않는 것이 좋다.
• 자식 클래스 마다 쓰임새 사용법이 다 다
르다면 억지로 상속받지 말라.
리코스프 교체 원칙 (LSP)
• Storage
– FileStorage
• OpenFile() / CloseFile()
• SaveFile()
– DBStorage
• Connect()
• Insert() / Update()
리코스프 교체 원칙 (LSP)
void save_data(storage *storage)
{
if() //storage 가 FileStorage 라면,
{
// 파일에 쓰고
} else { // storage가 DBStorage 라면
// DB에 저장하고
}
}
리코스프 교체 원칙 (LSP)
void save_data(storage *storage)
{
storage.save(); // Coool !!
}
리코스프 교체 원칙 (LSP)
의존 관계 역전 원칙 (DIP)
• 추상화된 부모 클래스는
자식에 의해 구체화 되는 것이 좋다.
• 부모 = new 자식();
• LSP랑 유사한 이야기.
의존 관계 역전 원칙 (DIP)
• High-level modules should not depend
on low-level modules. Both should dep
end on abstractions.
• Abstractions should not depend upon d
etails. Details should depend upon abst
ractions.
http://en.wikipedia.org/wiki/Dependency_inversion_principle
의존 관계 역전 원칙 (DIP)
class Storage
{
public:
int save();
};
의존 관계 역전 원칙 (DIP)
FileStorage :public Storage
{
public:
int save();
private:
…
};
DBStorage :public Storage
{
public:
int save();
private:
…
};
의존 관계 역전 원칙 (DIP)
int main()
{
Storage *st = new FileStorage();
st.save();
Storage *st2 = new DBStorage();
st2.save();
}
의존 관계 역전 원칙 (DIP)
• LSP를 지키지 않는 코드라면
– 구체 클래스에 특화된
메소드를 이용하기 위해
형변환을 하게 된다.
– virtual 쓰면 안 그래도 되던가?
인터페이스 격리 원칙 (ISP)
• 텍스트
2010 Object-Oriented Programming by Doodoori2
05. 체계적인 코드 정리
5. 체계적인 코드 정리
•
•
•
•
부끄러운 줄 알아야지
1년 후 다시 본다는 믿음으로 코드를 작성
다른 사람의 코드를 보면 그냥 화남
막상 본인이 짠 코드 본인이 못 알아 봄
– 뭐 이렇게 개떡같이 짰어?
맨 위에 @author doodoori2 라고 써있는걸
확인
• 잘못 짠 코드는 언젠가 네 발목을 잡는다.
5. 체계적인 코드 정리
•
지저분한 코드
새로운
요구사항 발생
요구사항
적용 어려움
급조한 코드
5. 체계적인 코드 정리
깨끗한 코드
새로운
요구사항 발생
요구사항
적용 쉬움
동일성 있는 수정
5. 체계적인 코드 정리
• 책에서는 이렇게 악순환과 선순환으로 설
명하고 있지만…
• 막상 현실에서는…
– 우선 좋은 코드가 없다 (전제가 글러먹음)
– 기초 설계가 소화할 수 없는 스펙 변경
– 요구사항 적용이 어려움
– 개발자는 여러 명. 통일성 따위
5. 체계적인 코드 정리
• 다른 개발자들에게
API를 제공한다는 마음으로 개발 하라
• 남이 봐도 쉬운 코드를 만들어라
• ‘역사적’인 이유를 만들지 말아라
• 자신의 코드만 보지 말아라
• 기존의 코드와 통일성 있는 코드를 작성하라
• 커뮤니케이션 하라
• 항상 ‘1년 뒤에 이 소스를 본다면?’ 이라 생각
하라
• 리팩토링 하라 << 상사를 설득하라
5. 체계적인 코드 정리
• 컴퓨터는 생각보다 빠르다
• 겁나 빠르고 효율적이지만 남들이 전혀 이해하지 못하
는 코드는 나쁜 코드다.
• 다른 개발자의 실력을 비난 할 것이 아니라
본인의 커뮤니케이션 능력에 문제가 있는 것
• 좋은 구조로 개발하고 테스트를 통해 병목 지점을 개
선하는 것이 훨씬 바람직하다.
– 프로파일링 ?
프로그램을 여러 번 돌리면서 어디에서 집중 부하가 많이
걸리나 그런걸 하는거죠. 메모리 접근 횟수 이런걸 따지거
나 특정 부분을 따지거나 지역적 특성을 따지는 거죠.
– 스트레스 테스트
5. 체계적인 코드 정리
• 주석 이 없는 코드가 좋은 이유
2010 Object-Oriented Programming by Doodoori2
06. 패턴은 단지 이름에 불과하다
6. 패턴은 이름 붙여진 것일 뿐
• GoF (Gang Of Four) 아저씨들의
Design Patterns 에서 처음 논의된다.
– 하다 보니 이런 문제점이 자주 나오더라
– 그럴 땐 이런 방식으로 해결하는 게 좋더라
– 이런 방식을 패턴이라고 부르는 건 어떨까?
Design Pattern !!
6. 패턴은 이름 붙여진 것일 뿐
• 팩토리(Factory) 패턴
• 추상 팩토리(Abstract Factory) 패턴
• 팩토리 메소드(Factory Method) 패턴
• 템플릿 메소드(Template Method) 패턴
• 빌더(Builder) 패턴
• 싱글턴(Singleton) 패턴
• 프로토타입(Prototype) 패턴
• 어댑터(Adaptor) 패턴
6. 패턴은 이름 붙여진 것일 뿐
• 옵저버(Observer) 패턴
• 이터레이터(Iterator) 패턴
• 컴포지트(Composite) 패턴
• 스테이트(State) 패턴
• 스트래티지(Strategey) 패턴
• 프록시(Proxy) 패턴, 플라이웨이트(Flyweight) 패턴
• 커맨드(Command) 패턴
• 데코레이터(Decorator) 패턴 `
6. 패턴은 이름 붙여진 것일 뿐
• Singleton
– 딱 한 번만 생성되어야 하는 녀석
– 적절히 쓸 일이 많다
•
•
•
•
•
•
•
thread-pool
dialog box
cache
preference-configuration
registry-configuration
logging object
device-driver
6. 패턴은 이름 붙여진 것일 뿐
• class 내부에 Instance 포인터를 저장
• 모든 코드에서
getInstance() 함수 호출해서 사용
• getInstance() 함수 호출 시
생성되지 않았으면 생성해서 저장
생성된 녀석이 있으면 그 녀석 반환
• 딱 한번만 생성되도록 !!
6. 패턴은 이름 붙여진 것일 뿐
class onlyOne
{
private:
static onlyOne *onlyOneInstance ;
public :
static onlyOne* getInstance() ;
}
// 문법이 틀릴 수 도 있지요
6. 패턴은 이름 붙여진 것일 뿐
int main()
{
onlyOne *a, *b, *c;
// 여기서 생성
a = onlyOne::getInstance();
// 여기는 걍 쓴다
b = onlyOne::getInstance();
c = onlyOne::getInstance();
// 결국 a, b, c는 같은 하나의 객체를 가르킴. (공유)
}
6. 패턴은 이름 붙여진 것일 뿐
onlyOne* onlyOne:: getInstance()
{
if(onlyOne:: onlyOneInstance == null)
{
onlyOne::onlyOneInstance = new onlyOne();
}
return onlyOne::onlyOneInstance;
}
6. 패턴은 이름 붙여진 것일 뿐
#include <iostream>
#include <string>
}
};
using namespace std;
CResourceManager
CResourceManager::_instance;
class CResourceManager {
int main(int argc, char* argv[]) {
private:
CResourceManager& manager =
CResourceManager() {}
static CResourceManager _instance; CResourceManager::Instance();
cout << manager.Get("hello")
<< endl;
public:
return 0;
static CResourceManager&
}
Instance() {
return _instance;
}
string Get(string name) {
return name + ":" + name;
// 헝가리안 표기법
6. 패턴은 이름 붙여진 것일 뿐
• 위 위에 코드 복사해서 실행하면 아마도
동작 안 할 것 같음.
• 생성자도 private 으로 해서
막 생성 못하게 하고
• templete을 활용한 singleton.cpp 참고
http://doodoori2.poolc.org/code/cpp/singleton.h
6. 패턴은 이름 붙여진 것일 뿐
• Factory Pattern
어떤
생성 자체를 추상화
해야 할일이
있어요.
– 기본적으로
사용하는
인터페이스는
–
–
–
–
–
똑같은데
문제는 내부적으로 library를 써가지고 왔다갔다
하는 코드는 다른 코드로 되있잖아요
그러면
쓰지마 이자식아
그럼 이런 연결 코드를 추상화하는 객체를 만들거
에요
무슨말인지 못알아듣겠어
그런식으로 객체를 만들어내는 함수를 추상화해
가지고 실제로 그걸 구견하는 concrete를 다른
사람에게 맡기는 거죠
interface ConnectionFactory {
public Connection create();
}
class DBWorker {
public DBWorker(ConnectionFactory f);
}
class PoolCConnectionFactory extends ConnectionFactory {
public Connection create() {
// 이상한 짓
// 군입대
// 제대
return null;
}
}
class MySQLConnectionFactory extends ConnectionFactory {
public Connection create() {
return new MySQLConnection();
}
}
new DBWorker(new MySQLConnectionFactory());
6. 패턴은 이름 붙여진 것일 뿐
• State
6. 패턴은 이름 붙여진 것일 뿐
• 나머지 패턴은 알아서 공부합시다
• 사실 별로 공부할 필요도 없고
• 이런 책 하나 곁에 두고
심심할 때 마다 읽어주는 게
프로그래머의 미덕
6. 패턴은 이름 붙여진 것일 뿐
• 팩토리(Factory) 패턴
– 객체 생성은 객체 생성 전문가에게
• 추상 팩토리(Abstract Factory) 패턴
– 관점의 차이가 곧 객체 생서의 차이
• 팩토리 메소드(Factory Method) 패턴
– 필요한 것은 알아서 만들자
• 템플릿 메소드(Template Method) 패턴
– 순서를 정리하면 시점이 보인다.
• 빌더(Builder) 패턴
– 복잡한 조립은 전문가에게 맡기자
• 싱글턴(Singleton) 패턴
–
오직 하나뿐인 그대
• 프로토타입(Prototype) 패턴
– 너의 쌍둥이가 필요해
• 어댑터(Adaptor) 패턴
– 수정할 수 없는 너무 안정적인 당신
6. 패턴은 이름 붙여진 것일 뿐
• 옵저버(Observer) 패턴
– 무슨 일이 생기면 바로 알려줘
• 이터레이터(Iterator) 패턴
– 한가지 탐색법만 기억하라
• 컴포지트(Composite) 패턴
– 복합구조도 접근법은 하나
• 스테이트(State) 패턴
– 난 기분에 따라 행동이 달라져
• 스트래티지(Strategey) 패턴
– 골라쓰는 알고리즘
• 프록시(Proxy) 패턴, 플라이웨이트(Flyweight) 패턴
– 공유되는 정보와 대리인
• 커맨드(Command) 패턴
– 행동만 따로 떼어보자
• 데코레이터(Decorator) 패턴
– 꾸미는 방법도 가지가지
6. 패턴은 이름 붙여진 것일 뿐
• 끗
• 결론은 책을 사라
• 있어 보인다고 막 따라 하다간 짤린다.
• 선배님들의 정말 훌륭한 가르침이죠.
7. 후기
•
•
•
•
•
•
•
최재영
김용태
강냉이
장승호
박지범
박건도
이성수
:
:
:
:
:
:
:
제육 사줘
아 이거좀 봐줘요 에러나
아닙니다.
잘잤어요
배고파
목말라
아 재밌어요.
• 좋은 세미나다