OOP의 실제 예를 연구하자
배경화면용: 네덜란드
OOP의 실제 예를 연구하자
학교나 책에서 배우는 OOP는 개념만 있어서 당최 현실에서는 어떻게 쓰이는지 모를것이다.
다형성:
즉 단순한 변수가아닌 data를 유연한 객체화시킨다
https://ko.wikipedia.org/wiki/%EB%8B%A4%ED%98%95%EC%84%B1
옵저버 패턴은 callback임
코딩설계 예
재귀함수는 언제 써야하는가?
1. 일반함수로 쓸수없을때, (필수)
2. 일반함수의 경우 코드가 너무 중복되어 중첩의 중첩이 일어날경우
(선택이지만 가독성에 따라 재귀 권장)
3. 그 중첩의횟수를 몰라서 일반화를 할필요가있을때 재귀 (필수)
OOP 실제례
1.
A Class가 B Class를 통해서 실제적으로는 C Class에게 일을 시킨다고보면,
A 입장에서 B만 바라보고 method call하는게 좋을지 - OOP 모듈화/은닉 관점
B.C.()식으로 C를 노출시킨후에 C의 Method를 바로 호출하는게 좋을지 - dependency 분리 차원
어떤게 나을지 의문인경우가 있다
생각의 결론: c의 method호출이 1회라면 b를 통해서 가고, 2회이상이라면 c를 노출하는게 나아보인다.
2. 인자냐 생성자냐
a와 아주먼 b모듈을 연결할때
1. a의 객체를 함수 1, 함수 2... 함수n을 통과하며 계속해서 parameter를 넘겨주며 b까지 가는경우
2. b에서 역으로 올라가서 a를 가져오는법
3. 생성자를 이용해서 b를 생성시키는 b.caller() 그리고 그 caller에 미리 넘겨주는법
으로 나눠진다.
선택은 상황에 따라서 잘~
해법:
자 어느상황이 있냐면 이것은 모든 module과 OOP에 적용되는데
설계시에는 변화는것과 변화지 않는것을 구분해야한다.
즉, 그 value를 동적으로 가져와야하냐, 아니면 (값이변화지않기때문에) 정적으로 한번가져오면 끝이냐인것이다.
그래서 예들어, 값이 변화지 않기 때문에 정적으로 한번가져오면 끝이라면,
생성자를 통해서 미리 값이 준비하는것이 효율적이라 할수있다.
이런식의 규칙이없다면 코드는 이렇게도 호출하고 저렇게도 호출하고 중구난방인 일관성도없는 코드가 될수있다.
3.
getter setter
하나만 있을경우 권장
eg.
1 get (set할수없음)
2 set만( get라수업음)
3. 둘다는 보통필어없고
set시 조건검사 및 errer handling필요할때,
setter만들어야함
setter생기면 field는 무조건 private
4. 객체냐 값이냐
a -> b -> c class가 있을때 a에서 c로 객체또는 값을 던져주고싶을때, 값이좋을까 객체가 좋을까. 객체를 이용해서 값을 여러개 생성해야한다며 객체가 좋고,
단 하나의 값만 사용한다면 값이좋다. 왜냐 passing과정에서 b는 그 객체를 알필요없기때문이다. 의존성감소!
쓸데없이 class객체를 편하다고 팍팍 넘기지 말란말이다~!
5.
interface를 써야할때,
1. 다형성, 다형성이라고 해서 다 해야하는게아니라 동적이고 더 유연함과 capsule화를 가져가고싶을때
2. 다중상속을 구현하고싶을때
3. layer의 분리를 두고싶을때
- api노출,
- 각 layer간 개발자 다름 (code은닉, code개발속도차이시 연결느슨)
외부 정보
기존 클래스에 메서드를 확장하기
https://blog.hongminhee.org/2012/06/30/26202408156/
꼬리말 - 노른자집 Music Player 설명서 | 살아있는 추천 글 보기 | 블로그 인기글보기 | 전체글보기
'IT > IT 일반' 카테고리의 다른 글
[긴급] 아이폰 사용자 정보도 탈취하는 몸캠 피싱 발견! (0) | 2017.05.17 |
---|---|
인기있는 카톡 프사 랭킹 Top 7을 알아보자! -1 (0) | 2017.05.16 |
카톡 - 여자는 ‘분위기’, 남자는 ‘자연스러운 외모’ - 2 (0) | 2017.05.16 |
Mobile 관련 정보를 모아봄 (0) | 2017.04.28 |
Web 작업 UI 디자인 레벨 관련 정보 모음 (0) | 2017.04.27 |
인터넷 커뮤니티 이용 팁 (0) | 2017.02.05 |
폰트: TrueType글꼴 OpenType글꼴 (0) | 2017.02.03 |
사내 프레임워크 만들지 말자 - 4* (0) | 2017.01.26 |
사내 프레임워크 만들지 말자 - 3 (0) | 2017.01.26 |
사내 프레임워크 만들지 말자 - 2 (0) | 2017.01.26 |