여러 언어에서 null 안전성을 주요 마케팅 쟁점으로 내세우면서 null 안전성이 관심을 많이 받고 있습니다.
자바에서도 null을 잘 다루어야 소프트웨어 결함을 줄이고 견고하게 만들 수 있는데 null의 위협에서 코드를 안전하게 지키는 설계 지침을 정리하고 안전하다고 확인하는데 도움이 되는 도구를 소개합니다.
여러 언어에서 null 안전성을 주요 마케팅 쟁점으로 내세우면서 null 안전성이 관심을 많이 받고 있습니다.
자바에서도 null을 잘 다루어야 소프트웨어 결함을 줄이고 견고하게 만들 수 있는데 null의 위협에서 코드를 안전하게 지키는 설계 지침을 정리하고 안전하다고 확인하는데 도움이 되는 도구를 소개합니다.
니름은 마이크로서비스를 위한 인터페이스 정의 언어(IDL) 컴파일러이자 원격 프로시저 호출(RPC) 프레임워크입니다. 스포카에서 서비스 지향 설계(SOA)를 적극적으로 도입하면서 쓰기에 적합하도록 구현되었습니다.
제품을 개선하기 위해서는 코드를 고쳐야 합니다. 그런데, 고친 코드가 행여 제품을 망가뜨리는 것이 아닐까 망설이고 고민할 때가 많습니다. 단위 테스트가 있다면 제품을 안전하고 빠르게 개선할 수 있습니다. 하지만 서비스 지향 설계로 제품을 만들다 보면 여러 개의 서비스들이 서로 통신하게 됩니다. 그리고 다른 서비스에 통신하는 기능도 단위 테스트를 작성해야 합니다.
서비스 간 단위 테스트는 까다로운 처리가 많이 필요합니다: 단위 테스트 안에서 요청을 흉내 내기, 실제 서비스를 띄워서 단위 테스트에서 테스트용 서비스에 요청하거나, 또는 요청과 응답을 흉내 내기, 요청한 내용을 역직렬화하고 응답할 내용을 직렬화 하기 등… 니름을 사용하여 서비스를 작성하면 서비스의 인터페이스와 구현을 분리할 수 있습니다.
요청이나 직렬화 등의 작업도 니름이 대신 처리하므로 추상화됩니다. 따라서 단위 테스트를 쉽게 작성할 수 있습니다. 서비스 지향 설계에서 니름을 사용하여 단위 테스트를 작성하면서 느낀 장점과 이것이 기존 방법들과 어떤 차이가 있는지 공유하고 싶습니다.
12. SRP : 단일 책임 원칙
한 클래스는 하나의 역할만 맡는다
클래스가 변경되는 이유는 유일해야 한다
13.
14.
15. 무엇이 좋아졌는가?
• 코드 변경의 영향이 미치는 범위 최소화
• 코드 응집성 향상
• 단위테스트에 유리
– InterestRate, ExchangeRate 객체는 Account 의
private 변수로, 각 클래스의 메서드는 public 으로
– 캡슐화와 테스트 용의성 둘 다 만족
16. SRP != (크기가 작은 클래스)
• 클래스의 크기는 작을수록 좋지만 여러 클래
스끼리의 교통정리를 해 주는 클래스도 필요
• 관련 클래스를 묶어 데이터 연관성
• 각 part 를 연결하는 whole 의 역할
• player -> ((inventory -> item), skill)
17. SRP(Single Responsibility)
단일 책임 원칙
OCP(Open Close)
개방-폐쇄 원칙
LSP(Liskov Substitution)
리스코프 교체 원칙
ISP(Interface Segregation)
인터페이스 격리 원칙
DIP(Dependency Inversion)
의존 관계 역전 원칙
22. OCP : 개방폐쇄 원칙
확장에 대해 열려있고 수정에 대해 닫혀있다
약속, 표준안을 만드는 것
interface, protocol, standard
핸드폰 24핀 커넥터
HTTP 표준을 rendering 하는 각종 browser 들
23.
24.
25. interface(표준)의 문제점
• 변경 비용이 비싸다
– interface 가 변경되면 모든 구현 클
래스에서 컴파일 에러 발생
– concrete class 이 뭔지 알기 어렵다
– BlueRay vs HD-DVD
• 충분히 안정된 후 interface 로
– 미리 바꾸지 않는다
– 첫 번째 총알 맞기
– 게임 하나가 완성된 다음에야?
• EPIC 의 Unreal Tounament (개밥먹기)
26. SRP(Single Responsibility)
단일 책임 원칙
OCP(Open Close)
개방-폐쇄 원칙
LSP(Liskov Substitution)
리스코프 교체 원칙
ISP(Interface Segregation)
인터페이스 격리 원칙
DIP(Dependency Inversion)
의존 관계 역전 원칙
28. LSP - 리스코프 교체(치환) 원칙
• 기반 클래스(Base Class)의 포인터나 참
조값을 사용하는 코드에서는 실제로 어떤
클래스인지 몰라도 쓸 수 있어야 한다
• 하위타입(subtype)은 그것의 기반 타입
(base type)에 대해 치환 가능해야 한다
• is-a 관계를 만족하는가?
• 바바라 리스코프(Barbara Liskov). 1988
38. 좀 더 실질적인 예제
bool Party::CanJoin(Pc& p) {
// do something
if (IsParty()) {
if (GetMember() < 12) {
return true;
}
} else { // 혈맹이라면
if (GetMember() < 140) {
// do something
41. LSP(교체가능) 정리
• concrete 클래스 자체에는 논리적 결함이
없어 보이더라도, 잘못 쓸 가능성이 있다
면 문제가 있다
– 수학에서는 (정사각형 is a 직사각형), 하지만
코드에서는 (정사각형 is not a 직사각형) 이
가능하다
– 실보다 득이 많다면, LSP(교체가능)원칙이 깨
지더라도 협약(convention)으로 해결할 수도
있다
42. stack(Java 와 C++)
java.lang.Object
extended by java.util.AbstractCollection
extended by java.util.AbstractList
extended by java.util.Vector
extended by java.util.Stack
template<class _Ty, class _Container = deque<_Ty> >
class stack {
void push(const value_type& _Val) { c.push_back(_Val); }
void pop() { c.pop_back(); }
_Container c;
};
43. SRP(Single Responsibility)
단일 책임 원칙
OCP(Open Close)
개방-폐쇄 원칙
LSP(Liskov Substitution)
리스코프 교체 원칙
ISP(Interface Segregation)
인터페이스 격리 원칙
DIP(Dependency Inversion)
의존 관계 역전 원칙
50. 너무 많은 걸 알고 있는 인터페이스
class Obj { // 레퍼런스만 관리
Attack
virtual int (Obj& o) {
ASSERT(0); // Actor 에서만 호출해야 함
return 0;
}
};
class Actor : public Obj {
virtual int Attack(Obj& o) { … }
};
std::map<int, Obj*> g_ObjDB;
g_ObjDB[1]->Attack(t);
51. 필요한 것만 알고 있는 인터페이스
class Obj { // 레퍼런스만 관리
};
class Actor : public Obj {
int Attack(Actor& o) { … }
};
std::map<int, Obj*> g_ObjDB;
std::map<int, Actor*> g_ActorDB;
g_ActorDB[1]->Attack(t);
52. ISP(인터페이스분리) 정리
• 같은 로직이 반복되면 up-class 하고 싶겠
지만 욕심내지 않는다
– 코드 재사용은 상속 대신 포함(aggregation)으로
• CTimerObject 대신
ITimerObject 와 CTimerHandler 활용
– 상속은 코드 재사용보다는 OCP(개방폐쇄)나
LSP(교체가능), DIP(의존역전)를 위해 사용
53. SRP(Single Responsibility)
단일 책임 원칙
OCP(Open Close)
개방-폐쇄 원칙
LSP(Liskov Substitution)
리스코프 교체 원칙
ISP(Interface Segregation)
인터페이스 격리 원칙
DIP(Dependency Inversion)
의존 관계 역전 원칙
60. • SRP(Single Responsibility) 단일 책임
– 클래스가 변경되는 이유는 유일해야 한다
• OCP(Open Close) 개방폐쇄 원칙
– 확장에 대해 열려있고 수정에 대해 닫혀있다
• LSP(Liskov Substitution) 리스코프 교체
– Base Class의 포인터나 참조값을 사용하는 코드
에서는 실제로 어떤 클래스인지 몰라도 쓸 수 있
어야 한다
• ISP(Interface Segregation) 인터페이스 격리
– 클라이언트는 자신이 쓰지 않는 인터페이스에 의
존하지 않는다
• DIP(Dependency Inversion) 의존 관계 역전
– 상위 모듈이 하위 모듈에게 의존하면 안 된다
62. • OCP(개방폐쇄)
– 인터페이스가 같은지?
– DrawShape를 호출하는 프로그래머 입장
• LSP(교체가능)
– 기반 클래스(Base Class)의 포인터나 참조값
을 사용하는 코드에서는 실제로 어떤 클래스
인지 몰라도 쓸 수 있어야 한다(정보은닉)
– DrawShape를 구현하는 프로그래머 입장
void DrawShape(const Shape& s) {
if (typeid(s) == typeid(Square))
DrawSquare((Square&)s));
else if (typeid(s) == typeid(Circle))
DrawCircle((Circle&)s);
}
63. • SRP(단일책임)
– 여러 책임이 섞여 있는 클래스를 책임별 분리
• ISP(인터페이스분리)
– 클라이언트가 클래스의 특정 기능만 이용한다
면 그런 기능의 부분 집합을 별도 인터페이스
로 추출
64. • OCP(개방폐쇄)
– 코드 추가만으로 기능 변경 가능한가
• DIP(의존역전)
– 변경의 주체가 누구인가
65. 현실은 시궁창
// 에라 모르겠다
// 해볼 수도 있겠으나 귀찮다. 일단 여기까지
// 구현의 편의를 위해 이렇게 한다. 시간이 없거든
// 작업중입니다 T_T
// 그래 나도 이러면 안되는 지 알어... 미안해...
// 원래는 lock 걸어야 하지만 이 정도면 괜찮을 듯?
한 번이라도 죽으면 lock 걸자. 07.10.xx
// 죽었다. lock 쓰는 걸로 바꾼다. 07.12.xx
// 사실 이렇게 짜면 안 되는데 이 클래스는 너무 고
치기 무서워서 못 건드리겠음
// 다시는 이런 일이 없어야 할 것임
69. 결론
클래스를 만들때는 고객의 입장에서 생각할 것
놀래키지 않는다
구조를 잡을때는 신중하게
실제로 써 본 뒤에 구조 잡기
안정화 단계란 영원히 오지 않을지도?
안정된 코드는 오래된 코드
언제가 “적당”한가?
라이브러리보다는 비즈니스 layer 가 중요
절대적인 법칙은 없다
71. Reference
• 실전 코드로 배우는 실용주의 디자인 패턴
• 소프트웨어 개발의 지혜 - 야스미디어
• zdnet - 객체지향 SW 설계의 원칙
– http://www.zdnet.co.kr/ArticleView.asp?artice_id=000000391
34727
– http://www.zdnet.co.kr/ArticleView.asp?artice_id=000000391
35552
– http://www.zdnet.co.kr/ArticleView.asp?artice_id=000000391
39151
– http://www.zdnet.co.kr/ArticleView.asp?artice_id=000000391
37043
• http://www.objectmentor.com/resources/publishedArticles
.html
• 실용주의 디자인 패턴 0장
• 애자일 프로그래밍 - 남기룡
72. 사진
• 높은 응집도, 낮은 결합도
– http://improf.egloos.com/2309582
– 실용주의 디자인 패턴
• 이미지 출처
– http://www.lostechies.com/blogs/derickbailey/archive/2009/02/11/solid-
development-principles-in-motivational-pictures.aspx
• 개발자 좀 살려주세요
– http://resistan.com/savethedeveloper/
• 사각형 집합
– http://middle.edupia.com/SchoolBook/seb/jd_seb1_content.asp?nTerm=2&nYear
=8&nConID=669&nCatID=250&nDaeNumber=5&target=jd_seb_right
• That’s not my job
– http://life-engineering.com/2008/04/28/thats-not-my-job/
• 자동차 사고
– https://www.youngsamsung.com/pblog.do?cmd=view&seq=459&memId=4&cate
goryId=49
• 내가 짰구나
– http://www.slideshare.net/wgshim/experience-report-agile-adoption-stories-
in-lg-electronics