실습 내용 저장소: https://github.com/Hyeon9mak/student-information-system
소프트웨어를 만들 때 항상 따라야 하는 절차
- 분석 : 소프트웨어가 어때야 하는지 요구사항을 모으고 교정해서 만듦새 결정
- 계획 : 개발이 얼마나 오래 걸릴지 판단
- 디자인 : 만든 것을 어떻게 합할지 결정
- 코딩 : 개발
- 테스트 : 동작 확인
- 배포 : 소프트웨어를 실행하고 사용할 환경에 적용
- 문서화
- 리뷰
XP와 같은 애자일 프로세스는 위에서 몇 가지 단계를 생략하는 것처럼 보일 수 있으나, 다른 방식으로 단계를 진행하고 있을 뿐, 절대로 생략한 것이 아니다!
객체끼리 메세지를 주고 받아라.
흔히들 하는 실수 - 객체를 직접 가져와서 명령을 수행시키는 것.
나는 여러분에게 현관을 잠그라고 말할 수 있다.
객체를 하나의 ‘방, 집’으로 생각하자.
방에 잠자고 있는 사람을 불러와서 “집에 다시 돌아가서 문 잠궈~” 라고 말하는게 정상은 아니다.
집에 있는 사람에게 “너네 집 현관문 잠궈~” 라고 말하는게 이상적임.
캡슐화
메세지를 보내는 쪽은 추상적인 개념에만 관심있다. 현관문이 잠기는 원리 따위 모른다.
현관문을 잠구는 원리는 집 주인만 알고 있다. 이것이 캡슐화(encapsulation)이다.
폴리모피즘
현관문 잠금 시스템이 자기식에서 전기식으로 바껴도 문을 잠구는 사람은 모른다.
어떤 코드를 대신해서 다른 코드를 넣어도, 클라이언트에서는 이를 알지 못하고
실제 동작에서도 관련이 없어야 하는 속성이 바로 폴리모피즘(polymorphsim)이다.
객체와 인스턴스
- 객체 : 청사진
- 인스턴스 : 청사진으로 만든 실체 각각의 인스턴스(화 된 객체)는 메모리에서 개별 영역을 할당 받는다. 이로 인해 인스턴스를 수정해도 다른 인스턴스에 영향을 주지 않는다.
상속이란 무엇인가?
문(Door)은 들어가거나 나가기 위해 사용되며, 열거나 닫을 수 있는 물건이다.
자동문, 엘레베이터 문, 은행 금고 문 등 모두 공통적으로 문(Door)의 속성을 가지고 있다.
이들은 여전히 열고 닫을 수 있는 문이지만, 각각은 약간의 추가적인 특별 속성을 가진다.
프로그래머는 문(Door)를 상속한 후, 추가적인 특별 속성만 명세 해주면 된다.
이것이 바로 상속이다!
TDD 단계
- 기능별 단위(Unit)로 TestClass를 생성 후, 명세(테스트 대상) 테스트 코드를 작성한다.
- 테스트가 실패하는 것을 확인한다. (테스트 할 명세가 없으므로 당연히 실패)
- 명세 대상 코드를 작성한다.
- 테스트가 성공하는 것을 확인한다.
- 꾸준한 리팩토링 진행! (리팩토링 또한 1번부터 반복)
TDD 단계의 장점이 뭘까?
- 버그 최소화
- TDD 자체가 다른 클래스에 의존하지 않는 분리된 디자인을 강요하기 떄문에 자연스럽게 시스템 디자인 향상
- 기능 문서화가 용이함
- 적응성. 이미 테스트를 통해 입증된 코드 이므로 다른 클래스를 망가뜨릴 염려가 없다.
- 피드백 수준이 매우 높다.
댓글남기기