최범균, 객체지향과 디자인 패턴(2회)

1장

1. 1 수정하기 안좋은 코드

메뉴 클릭에 따른 행동이 있을 때 이를 if / else 로 처리하게 되면 요구사항이 추가될 때마다 코드가 늘어남.

1.2 수정하기 좋은 코드
비슷한 동작을 찾자.
클릭, 보여주기

• interface 로 하고 implements.

1.3 소프트웨어란...
여러 요구사항이 계속 추가됨.

• 변화가능한 유연한 구조를 만들자.

2장 객체지향

1. 절차지향과 객체지향
2. I 절차지향
3. procedure 로 프로그램을 구성
4. 하지만 데이터가 많아질수록 감당 x

1.2 객체지향
객체 단위로 묶는다.

• 데이터 변화가 발생해도 해당

객체만 변화가 발생

2. 객차

21 객체의 핵심은 기능을 제공

• 소리크기 제어 객체
• 데이터 타입 안중요

소리 증가, 감소, 음소거 등의 기능

22 인터페이스와 클래스

• 객체가 제공하는 기능 = operation

즉 객체는 operation 으로 정의

• 객체가 제공하는 operation 의 집합 = 인터페이스
  (일종의 명세서나 규칙)
• 실제 구현은 클로니스가 한다.

2.3 메시지

• 오퍼레이션의 실행을 요청 = message
  = 메서드를 호출하는 것.

1. 객체의 책임과 크기.
2. 객체는 기능으로 정의
   = 객체마다 자신만의 책임이 있다.

• 객체의 책임을 결정짓는 것이 객체지향설계의 출발점
• 처음에는 필요 기능을 정리.

. 기능을 할당하는 게 가장 어려움. 다만 책임의 크기는 작을수록 좋다.

• 파일을 읽고 이를 암호화 한뒤 파일을 쓰는 경우
• 흐름제어, 파일 읽기, 파일쓰기, 암호화
• 기능이 많다 = 관련 데이터도 많다 = 절차지향식 구조

1. 의존
2. 한객체가 다른 객체를 생성, 호출 =

의존

• 부른 객체가 사용하려는 객체에 의존

• 파라미터로 받아도 의존임.

. A ← B ← c
(가 B에, B가 A에 의존하고 있다. A가 변경된다면 B, c 모두 영향

1. I 의존의 양면성

. 내가 변경되면 나에게 의존하고 있는 코드에 영향을 준다.

• 나의 요구가 변경되면 내가 의존하고 있는 타입에 영향을 준다.

1. 캡슐화.
2. 변경이 다른곳에 가하지 않게.

. 내부의 기능이 어떻게 구현하는지 감추는 것.

1. I 절차지향적 코드

. 데이터를 중심으로 작성

• 데이터 변화시 이를 사용하는 코드도 연쇄적으로 수정

5.2 캡슐화코드

• 요구사항 변경에도 변화없음.

예) 회원가입 만료를 계산할때 절차: 여성, vip 등 데이터에 집중

• 고쳐야할 곳 많다.

캡슐: member 클래스에 is Expired 메서드 기능 수정.

5.4 캡슐화 2개 규칙

• Tell, Don't ASK
  데이터를 묻지 않고 기능을 실행
• 만료일자를 가져와서 확인 x 만표확인 미서드를 불러 옴.
• 데미테르의 법칙
• 메서드에서 생성한 객체의 메서드 만 호출
• 파라미터로 받은 객체의 메서드만 호출.
• 필드로 참조하는 객체의 메서드만 호출.

member.get Some ().get Some x

• 결국은 기능중심.

1. 객체지향설계과정
2. 기능, 세분화, 객체에 할당
3. 최대한 캡슐화.
4. 어떻게 메시지 받을지 구상
5. 반복

3장 다형성과 추상타입.

1. 상속개요.
   Pass

1. 다형성과 상속.
2. 다형성 = 여러 가지 (poly) 모습 (morph)
3. 기능요청에 따라서 서로 다른 타입이 나옴.

. Turbo Plane extends Plane implements Turbo
= Plane 도 되고 Turbo 도 된다.

3. 추상타입과 유연함.
4. 추상화: 데이터, 프로세스 등을

의미가 비슷한 개념이나 표현으로 정의.
. FTP에서 파일 다운로드,소켓에서 데이터 읽기,
DB 테이블에서 데이터를 조회

• 로그 수집
  상세 구현은 알수없다.

1. I 추상타입과 실제 구현의 연결.
2. 추상클래스는 상속을 통해 연결.