4월 9일 ~ ...

주요 내용

설계

설계를 몇 퍼센트 미리 해놓고 몇 퍼센트를 개발 중에 할 것인가?

이름과 주석, 배치에 대한 코드 작성 규약은?

오류 조건을 처리하는 방법, 보안 문제를 해결하는 방법, 클래스 인터페이스에 사용될 규약, 재사용된 코드에 적용될 기준, 성능은 얼마나 고려할 것인지 등등...
구체적인 코드 작성 방법을 정의했는가?

언어에 의해 프로그래밍에 제약을 받기보다는 언어를 활용해 프로그래밍할 방법을 찾아봤는가??

협업은 어떻게 진행할 것인가?
짝을 지어서 코딩할 것인가?

모든 소프트웨어 설계 기법의 목표는 복잡한 문제를 간단한 문제로 나누는 것

인간은 하나의 복잡한 부분보다, 여러 개의 간단한 정보를 더 빠르게, 바르게 잘 이해한다.

뛰어난 설계의 특징

1. 복잡성 최소화 ("재치 있는" 설계는 피한다. "간단"하고 "이해하기 쉬운" 코드를 작성)
2. 유지보수의 편리함 (유지보수 개발자를 위해 고려한 설계 / 개발자를 청중이라고 생각)
3. 느슨한 결합 (프로그램의 각 부분 사이의 연결을 최소화)
   / 추상화, 캡슐화, 정보 은닉 등을 이용
4. 확장성 (내부 구조를 해치지 않고 시스템의 기능 개선)
5. 재사용성 (시스템의 일부를 다른 시스템에 사용할 수 있도록)
6. 높은 팬인(fan-in) (시스템이 특정 클래스(유틸리티 클래스)를 잘 활용하도록 설계)
7. 낮은 팬 아웃(fan-out) (특정 클래스가 다른 클래스를 적게 사용)
8. 이식성
9. 간결성
10. 계층화
11. 표준 기법들

정보 은닉

사실 지금까지 배운 내용으로는 잘 이해가 안 되는 부분이다.

정보 은닉은 실무에서 그 가치가 분명하게 증명된 몇 안 되는 이론적인 기법 중 하나.

"이 클래스에서 무엇을 숨겨야 하는가?"

ID 를 int 대신, IdType으로 선언하는 것.

변경될 것 같은 영역을 찾아라.

변경의 효과가 한 루틴, 클래스, 패키지에 제한되도록 불안정한 영역을 고립시켜라.

변경될 가능성이 큰 영역

• 비지니스 규칙 : 법과 계약내용등이 변경되는 경우
• 하드웨어 의존성
• 입력과 출력
• 표준을 따르지 않는 언어 기능
• 어려운 설계 및 구현 부분
• 상태 변수
• 데이터 크기 제약 : 배열의 크기 = 100 X // [MAX_VALUE] 처럼 상수 사용 O