Nebo - Test - Page 4
1장
-
1 수정하기 안좋은 코드
메뉴 클릭에 따른 행동이 있을 때 이를 if / else 로 처리하게 되면 요구사항이 추가될 때마다 코드가 늘어남.
1.2 수정하기 좋은 코드
비슷한 동작을 찾자.
클릭, 보여주기
-
interface 로 하고 implements.
1.3 소프트웨어란...
여러 요구사항이 계속 추가됨.
2장 객체지향
-
절차지향과 객체지향
-
I 절차지향
-
procedure 로 프로그램을 구성
-
하지만 데이터가 많아질수록 감당 x
1.2 객체지향
객체 단위로 묶는다.
객체만 변화가 발생
-
객차
21 객체의 핵심은 기능을 제공
소리 증가, 감소, 음소거 등의 기능
22 인터페이스와 클래스
즉 객체는 operation 으로 정의
-
객체가 제공하는 operation 의 집합 = 인터페이스
(일종의 명세서나 규칙)
-
실제 구현은 클로니스가 한다.
2.3 메시지
-
오퍼레이션의 실행을 요청 = message
= 메서드를 호출하는 것.
-
객체의 책임과 크기.
-
객체는 기능으로 정의
= 객체마다 자신만의 책임이 있다.
-
객체의 책임을 결정짓는 것이 객체지향설계의 출발점
-
처음에는 필요 기능을 정리.
. 기능을 할당하는 게 가장 어려움. 다만 책임의 크기는 작을수록 좋다.
-
파일을 읽고 이를 암호화 한뒤 파일을 쓰는 경우
-
흐름제어, 파일 읽기, 파일쓰기, 암호화
-
기능이 많다 = 관련 데이터도 많다 = 절차지향식 구조
-
의존
-
한객체가 다른 객체를 생성, 호출 =
의존
. A ← B ← c
(가 B에, B가 A에 의존하고 있다. A가 변경된다면 B, c 모두 영향
-
I 의존의 양면성
. 내가 변경되면 나에게 의존하고 있는 코드에 영향을 준다.
-
나의 요구가 변경되면 내가 의존하고 있는 타입에 영향을 준다.
-
캡슐화.
-
변경이 다른곳에 가하지 않게.
. 내부의 기능이 어떻게 구현하는지 감추는 것.
-
I 절차지향적 코드
. 데이터를 중심으로 작성
-
데이터 변화시 이를 사용하는 코드도 연쇄적으로 수정
5.2 캡슐화코드
예) 회원가입 만료를 계산할때 절차: 여성, vip 등 데이터에 집중
캡슐: member 클래스에 is Expired 메서드 기능 수정.
5.4 캡슐화 2개 규칙
-
Tell, Don't ASK
데이터를 묻지 않고 기능을 실행
-
만료일자를 가져와서 확인 x 만표확인 미서드를 불러 옴.
-
데미테르의 법칙
-
메서드에서 생성한 객체의 메서드 만 호출
-
파라미터로 받은 객체의 메서드만 호출.
-
필드로 참조하는 객체의 메서드만 호출.
member.get Some ().get Some x
-
객체지향설계과정
-
기능, 세분화, 객체에 할당
-
최대한 캡슐화.
-
어떻게 메시지 받을지 구상
-
반복
3장 다형성과 추상타입.
-
상속개요.
Pass
-
다형성과 상속.
-
다형성 = 여러 가지 (poly) 모습 (morph)
-
기능요청에 따라서 서로 다른 타입이 나옴.
. Turbo Plane extends Plane implements Turbo
= Plane 도 되고 Turbo 도 된다.
-
추상타입과 유연함.
-
추상화: 데이터, 프로세스 등을
의미가 비슷한 개념이나 표현으로 정의.
. FTP에서 파일 다운로드,소켓에서 데이터 읽기,
DB 테이블에서 데이터를 조회
-
I 추상타입과 실제 구현의 연결.
-
추상클래스는 상속을 통해 연결.
-
Log Collector CO = create(); CO. collect ();
이렇게 가능
즉 create () 가 생성하는 타입에 따라 달라진다.
(아래 클래스를 콘크리트 클래스라 부른다)
3.2 추상 E1 입자 교체의 유연함
. 콘크리트 직접 사용?
-
수정사항 발생시 if l else 계속추가
-
공통된 기능을 interface 화시키고 이를 관리하는 클래스를 따로 만들어
책임을 분리시킨다.
-
3 변화되는 부분을 추상화하기
-
변화되는 부분을 추상화
-
주로 if / else 구조로 등장
-
데이 터 형태에 따라 다른 결과 = 데이터 형태를 추상화
3.4 인터페이스에 대고 프로그래밍
-
program to interface
-
변화 가능성이 높은 곳에 인터페이스 사용
3.5 인터페이스는 인터페이스 사용자 입장에서 만들기
-
Data를 읽는 인터페이스
-
File Data Reader x
사용자: Flow Con 이므로 Bk Source 가 좋음.
(안 그러면 모든 소스가 file로 부터 오는줄 암)
3.6 인터페이스와 테스트
test 할때도 완성까지 기다려야 함.
-
인터페이스와 mock 을 활용하면 빠르게 테스트 가능
4장 재사용: 상속보단 조립.
1.1 상위클래스 변경 어려움
-
상속이란 의존.
그렇기에 아래로 변화가 내려 감
1.2 클래스 불필요 증가
-
조립을 이용한 재사용
-
조립은 다른 객체를 참조하는 방식
-
다른 객체를 조립해서 필드로
갖는다 = 다른 객체 사용
2.1 위임
. 내가 할 일을 다른 객체에게 넘김
5장 설계원칙, DI
-
Single responsibility principle
-
클리이스는 단 한 개의 책임을 가져야 한다
-
클래스를 변경하는 이유는 단 한개
1.1 SRP 위반시 문제
-
데이터를 읽는 책임과 보여주는 책임으로 구성시 데이터를 읽는 방식이 변경시 보여주는 방식도 수정됨.
1.2 책임이란 변화에 대한 것
-
책임의 단위는 변화와 관련
-
데이터 읽기 기능 변경이 데이터 보여주는 기능에도 영향을 끼치지 않음.
-
메서드 실행주체가 누구인가
-
클래스 사용자들이 서로 다른
메서드 사용시 그 메서드는 각각 다른 책임 속할 가능성이 높다.