객체 지향 설계 및 시공 - 제 1 단위 요강

개요

제 1 단위 작업의 주요 내용은 상대적으로 일반적인 프로그래밍 예제이지만, 다항식 유도하지만, 내가인지 아키텍처를위한 프로그램을 작성하기 때문에 프로그래밍의 결과로, 직장에서 시간의 제한된 투자와 결합, 세 번 제로 이 세 가지 작업에 반영하기 위해 지금 부적절한 많은 문제를 발생합니다.

반사의 주요 포인트는 분석 후 직장에서 반영됩니다 다음 포인트로 나눌 수 있습니다.

• 코드 재 작성 문제

  여기에 재 작성 두 가지 측면을 포함한다 :
  다른 작업 사이의 재건을 첫째, 내가 한 번에 이어지는 코드 된 생각을 확장 적이 때 아이디어 작업의 작업의 현재 구현을 고려,하지만 때문에 새 작업을 게시 할 때, 우리는 반복이, 코딩 많은 시간을 낭비하고, 필요한 인프라를 발견하고 지금까지 기존 인프라에서, 따라서 기존의 디자인을 전복해야했다. 각 작업의 작업 내용을 알 수 있었다 때문에, 심지어 그들이 아이디어를 생각 할 수 있도록만을 필요할 수 있습니다 여러 작업 뒤에 GitHub의에서 볼 진행 한 후, 다음의 요구 사항을 충족하기 위해 반드시 코드의 직무 수행을하지 않는 확장에 대해 생각했다 소진 이상 사전에 준비한다.
  생각했던 처음이 아닌 진정한 발견의 시작이 기능이 발견 나중에 할 수없는 만나는 쓰기에 새로운 기능을 많이, 또는 쓰기를 추가 할 수 있습니다 때까지 세부 사항을 알고 싶어하기 때문에 두 번째는, 코드를 작성하는 과정의 광범위한 프레임 워크를 알려져있다 요구 사항, 다시 추가 보완을 한 후 이전 코드. 이 방법은 분기 기준으로 이전에 추가 할 수있는 기능에 해당하기 때문에 이러한 행동은 매우 위험하다, 플러스 시간 요소는 새의 추가 결과를 쉽게 추가 할 수있는 기능의 세부 사항의 일부를 잊고 될 수 있습니다 버그는 코드를 유지 보수의 어려움을 증가시킨다. 즉, 기능적 접근은 사고의 사전에 적절하게 잘 실패했습니다.

• 기능의 관계는 분명 문제입니다

  하나는 클래스의인지 적 오류로 작동합니다. 잘못된 클래스에서 오는 완전히 기능을 충족 할 수 있도록하는 기능을 작성하는 생각, 프로그래밍 모드의 "객관성"을 무시하고 해당 기능을 구현하기 위해, 또한 자신이 속한 클래스의 범위를 넘어 기능이나 생각을 쓸 시간이다 이러한이 함수를 호출하면이 함수의 준비의 일부입니다 준비와 그것의 실현의 클래스에 속하는 사고 등의 범위는이 준비에 다른 기능의 생각을 증가, 쓰기의 어려움을 증가 같은 기본 전제 조건을 무시하는 것입니다 및 경향 버그 간의 결합.
  둘째, 함수 호출 규칙 사이의 오류입니다. 큰 함수 호출 작은 기능, A가 B를 호출 피하려고하고, B는 사건 A의 함수를 호출 할 수 있습니다, 또는 함수의 극단적 인 복잡성 원 증가 할 것으로 개별 통화의 원칙을 채택하는 것을 시도해야 함수를 호출합니다.
  셋째,인지 적 오류의 기능 사이의 결합. 호출 할 수있는 상황을 무시해야 호출 된 함수는 조건 만 기존 조건에 근거하여 작성 후 설정하고 가정 생각 만해야한다. 호출하는 기능은 사전에 호출 된 함수에 필요한 환경을 만들어야합니다. 이 기능을 수행하는 낮은 결합 및 다른 요소의 기능을 유지할 수있다.

• 개별 함수의 완전성 시험을 무시하면서 퀴즈는 전체 프로그램을 테스트

  이 코드의 세 가지 작업은 국민, 대부분의 전체 코드 작성 테스트 프로그램에 따라 작성 후. 그러나 전체 프로그램에 대한 모든 기능은 시험의 난이도가 전체 프로그램을 테스트하는 생각 있도록 제한됩니다 자신의 구조 시험 데이터와 함께, 극적으로 증가한다 특정 가능성, 기능의 수를 곱한의 가능성이 그 자체가 잘못된 것입니다. 그러나 함수의 경우에서 비교적 쉽게 검사 할 함수의 기능을위한 필수 조건이다 왔으며, 비교적 쉽게 문제를 매우 유용 가능성을 감소 테스트 세트를 달성했다.

• 프레임 워크를 수립의 오류 처리

  나는 세 가지 작업을 작성하는 과정에서 오전, 그들은 따라서 결과, 직접 주제를 읽은 후, 특히 정말 쓰기 시작, 첫 번째 작업 준비, 이해에 적합한 프레임 워크를 설정하지 않은 여러 다시 쓰기 뒤에 코드를 물품. 첫째 : 생각할 수있는 현재의 구조를 구축하는 방법은 다음이다
  건축과와의 메인 클래스 사이의 관계를 통해 전화를 결정하기 위해, 전체 프로세스의 시뮬레이션을 실시, 가장 간단한 테스트 샘플 중 하나 작성. 이어서 테스트 케이스의 기록에 여러 가지 종류의 기본 구조를 가지 기능의 수를 결정한다. 이 코드 아키텍처의 구축 속도를 높일 수 있습니다,뿐만 아니라 직접 오버 핸드 발견 스키마 오류를 줄일 수 있습니다.

• 문제 활동을 토론

  나는 거의 과정에서 코드, 기본적으로 "숨막히는하지 행운"을 쓸 학생들과 토론을 포함하여 다른 사람과 의사 소통을하는 것이 활성화되어 있지 않은, 게시글 등 번호가 포럼을 참조하십시오. 이 발굴 작업, 토론과 교환 가치가 같이하지만, 사고의 충돌은 때때로 문제를 해결하기 위해 오랜 시간 동안 열심히 생각하는 경향이 있습니다. 이 작은 교환하기 때문에, 버그를 해결하기 위해 기회를 잃은 다른 아키텍처에서 배울 수있는 기회를 상실뿐만 아니라, 심지어 자동 평가 시스템을 같은 가치있는 도구를 사용하여 셔틀 버스를 잡으려고하지 않았다. 그리고 토론, 갑자기 급진적 인 아키텍처를 이동 변덕 다시 코드, 토요일 오후에 부합하지 않았다 목요일, 금요일과 토요일 밤에 하루 동안의 작업을 완료하는 세 번째 날까지 이어질 것입니다 작성된 덜 열정을 구동하는 데 실패 개혁. 결과는 최종 마감일은 또한 수정을 완료하지 못했습니다, 상상 할 수 있습니다, 이것은 단지 무력 겨우 지불 할 쓰레기 코드에 의해 측정 할 수 있으며, 그 결과는 매우 만족스럽지 못한 놀라운 일이 아니다 강한 편이다.

---

세 가지 작업의 구체적인 분석

처음

• 운영 요구 사항

  작업의 첫 번째 세부 사항은 비교적 간단하다, 가이드의 주요 내용은 해결의 간단한 다항식 함수
  > "식의 유도"- - "독서의 표현"으로 나눌 수 있습니다 구현 프로세스의 전체 코드> "유사 항목의 합병 "->"출력의 표현 "네 단계.
  전력 함수의 주요 기능 중 한 종류 만 지수 함수 용기는 멱 함수에 장착 될 수 있으며, 비교적 간단한 클래스 달성되기 때문이다.
  그 과정에서 읽기 형식적인 표현 설명 정규 표현식을 쓰기의 방법을 필요로한다.
  클래스 및 메소드 구현 아래와 같이
  

• 코드 결함

  이 코드의 한 가지 단점은 문제 "함수 관계가 명확하지 않다"위의 유죄이다. 예를 들어, 출력 기능은, 먼저 목록 전원 기능의 각 꽤 표현 저장된 정보와이 프로그램에로드 된 컨테이너 클래스 변수 인 파워 기능을 이해하지만 목록 출력 기능은 전원을 단순한 전화는 정말 함수 클래스는 after_deriva_print출력 전원 기능 클래스의 전체 책임에 해당하는 기능을 수행합니다. 그러나, 이러한 로직은 실제로 전력 함수, 즉 고려해야한다 상관 안 식, 즉 클래스 목록되어야 구조, 식 종류 기호는 멱 함수 사이에 접속되고, 무엇이어야하기 때문에 가능하지 않다에 구현 것을 고려해야한다. 그러나 작업을 작성하는 경우는, 사실, 심지어 코드를 증가 스토리지 클래스 ---- 목록 클래스의 경우를 고려하기 위해, 함수 변수 클래스로, 생각의 기능 사이의 결합을 증가 어려운 기록. 당신은 그러한 작은 문제가 이해할 보이지만, 다른 응용 프로그램 시나리오와 그들이 어색한 사람들에게 이상한 느낌을 줄 것이다 나의 두 번째와 세 번째 작업으로 생각하는 이런 종류의, 특히 클래스를 작성하는 생각 시작 때로는 수없는 함수 느낌 ---- 고려해야 할 중요한 것은 케이스의 준비에 어려움이 발생 선도, 너무 많은입니다.

• 코드 메트릭

  
  으로는 더 높은 값, 더 나은 나머지의 복잡성을 변수 (즉, 전원 기능) (CC)에 추가하여, 볼 수 있습니다.
  이것은, 위의 코드 결함 허용 (A)의 유죄이어야한다 또한 한편으로는 "함수 관계하는 것은 명확하지 않다"문제는, 함수의 복잡성을 선도하는 것은 더 어려워 높은된다.

초

• 운영 요구 사항

  두 번째 작품은, 요소 및 항목의 개념을 도입 기본적인 삼각 요소의 도입 동안. 따라서, 작업이 현저하게 개선되어 처음보다 구조의 복잡성.
  > "항목"- - 관계 "에 의해"> "인자"중첩 관계, 표현의 용어입니다 "와"관계의 핵심 요소가되고 이해 우선이가 "표현"이라는 것이다.
  처음 작업보다는 전체 프로세스는 많은 변화하지 않지만 내부 기능을 많이 추가합니다. > "출력 표현은"(사실, 전체 프로세스는 세 등의 작품입니다) - "유사한 항목의 합병"> -> "식의 유도"- 전체 프로세스는 여전히 "표현 읽기"입니다
  표현 읽기 양태는, 전처리 크게 같은 죄 같이, 판독 공정에 의해 단순화 될 수있다 (x)의 사인 변환, 전력 삼각 함수로 판독하여 충돌 회피, X로 표시로서 암시 멱 수있다 는 x ** 1, 그래서 일부는 덜 판단 될 것이다.
  제품의 유도 과정 이상의 유도 함수, 그것은 이러한 X ** 2와 가이드 포스트 기본 클래스 시크 변환 유형, 파워 클래스의 함수임을 유의해야한다 클래스 엔트리 유도 후해질 것이다.
  다음과 같이 코드 구조는 다음과 같습니다
  
  
  

• 문제점 분석

  양 DesigniteJava 다시 서서히 분석의 제 직접적인 결과
  
  
  • 첫 번째 질문은, 오히려 특별하지 위의 문제 중 하나에 속하지 않습니다. 즉 얕은 복사 문제입니다. 에서 문제가 발견 디버그, 해당 항목 (항목 유형)에서 trigoncanMerge기능, 그 기능은 두 가지 조건이 함께 충족 최적화 항목, 부울 값은, 그러나, 디버그 동안이 완료 될 때까지 실행 발견 반환 여부를 결정하는 것이다 않습니다 이 기능을 한 후, 항목의 표현은 어떻게 든 수정되며,이 함수의 시작 부분을 복사하는 데이 개 용어를, 그리고보기의 일부 작업이 판단 할를 통해 다음이 코드는했을 것이다 논리적 인 점은 문제가 없습니다 첫 번째 사본, 다음 작업은 입력 매개 변수에 영향을 미치지 않습니다. 그러나, 그 자체가 나의 판단과 함께 용기가 매우 혼란되어 내 항목 클래스 메서드에, 컨테이너는 두 개의 서로 다른 개체를했다, 그래서 요인에 사본을 수정되지만 같은 요인 케이스에 의해 관리 이 동작, 컨테이너 개체는 요소가 수정되는이 시간 ---- 다른 컨테이너 개체는 매우 위험하고 감지하기 어려운합니다.
    따라서,이 문제의 해결책이 같아야 그러한 예로서,이 프로그램 모델 등의 데이터 관리의 각 클래스를 복제하는 방법을 추가 Expression.clone호출 할 수 Item.clone있는 요소 내에서 호출 될 수있는 Constant.clone, sine.clone등등, 매우 기본적인에서 수 복제의 유형, 따라서 충돌 관리 요소의 문제를 회피.하지만이 연습의 안전에 대한 대가로 희생 할 수있는 시간이 아니다? 당신은 응용 프로그램의 성능이 저하 될 수 있습니다.
  • 두 번째 질문은 "아키텍처 설계"오류가 최선을 다하고 있습니다. 아키텍처를 작성하는 시간이 기능 항목 컨테이너 요소의 배열을 발견하는 데 실패 이후, 나는 유일한 방법 배열이 일정한 전면은 선택하지만, 일정한 전력 기능 뒤에, 삼각 배열은 또한 참으로 매우 혼란 방법입니다 I는 몇 가지 기능 사이 달성 항목 결과는 MergeInExpression, 항목의 위치에서 가능한 요인 측정 하였다 결합 때에도 항목에 병합 MergeInItem내 기능 블록의 일부 결과 복합체는 그러한 판단이 있었다 가 필요한 호의 조건의 여러 위치에 상황 요소가 고려되어야하기 때문에 그것은 매우, 부풀어있다.사실, 항목의 다른 유형 내에서 완벽하게 작업 위치 등 우리가 사용하고있는 방법으로, 일부 제약에 의해 확인 된 고려하는 네 튜플나는 전체 기능 및 기능 블록의 덜 명확한 구분하지만, 실제 작업 시간은 분명히 일부 기능은 원래 좋은 기능 블록에 예정되지 않은 것을 알 수 있지만 아키텍처처럼, 그것은 그래서뿐만 아니라 모든, 추상화한다 기능 블록을 작성하는 데 어려움이 감소되지만 전체 로직을 더 명확하게 될 것이다.
  • 또한 최선을 다하고 있습니다 세 번째 질문은 내가 가장 자주 최선을 다하고 질문에 "잘못을 배치하는 위치의 함수"입니다. 이 문제는 또한 "긴 stetement"의 DesigniteJava을 반영 할 수, 키 문제는이 혼동 "개체"다른 클래스의 특성, 방법이 가장 가까운 클래스를 달성하기위한 방법의 기능을 작성해야합니다,하지만 위해서하는 것은 급하게 추가 달성하기 위해 특별한 기능은 주저없이 차이가 무엇인지 현재 쓰기 자신의 위치 및 사고의 프로세스 중심 방식에 가장 도움이 중 하나에 배치되는 새로운 기능을 추가했습니다. 예를 들어, 작업 trigonCanMerge기능,처럼 삼각 함수는 Item 클래스 (항목 범주) 너무 너무 합병이 더 편리하지 않습니다 달성하기 위해 가야 삼각 함수의 측면에서 항목과 다른 요소들로 구성 될 수 있기 때문에 책임 것 모든 기능에 대응하지만, 다른 요소와 함께 엔트리로 다시 삼각 계수에서 항목을 완료 삼각 함수를 획득하기 위해 결합 될 수 있는가? 어쩌면이 중 일부는 다소 성가신 수 있지만 삼각 함수 클래스 클래스와 접촉의 논리적 방법을 달성하기 위해, 자신의 합병 삼각 함수가 더 자연스럽게 될 것입니다 구현.
  • 네 번째 문제는 발생 전술 한 "비 - 단일 함수 호출 관계"로 커밋된다. 이 문제는 노란색 원으로 표시 "복잡한 방법"의 DesigniteJava에 의해 반영 될 수있는 것은 가장 어려운 히트의 높은 복잡성이다. 절차를 명확히하기 위해 실패하면 호출, 더 복잡한 호출 관계로 이어질 작성됩니다 사이클 호출의 때로는 단계를 결정하기 위해, 당신은 때때로 높은 호출을 나타날 수있는 동일한 수준을 피하기 위해, 하위 또는 부하 직원 높은 수준의 기능에 종속 함수를 호출하려고한다 상황.

세 번째

• 머리말

  작업은 시간의 가장 완벽한 실패, 이유는 작업의 태도가 올바르지 않은 것입니다. 수요일과 목요일 급하게하지만, 코드의 광범위한 테스트를 수행하기 위해 더 많은 에너지를 소비한다, 코드를 작성했다, 나는 커버는 대부분의 샘플을 구성 할 수있는 상황을 언급 한 위의 "테스트 프로그램 인 매우 귀찮은 것이라고 생각 "오류 문제는, 코드의 양이 너무 크고, 너무 복잡한 상황, 그들 만의 시작의 전반적인 기능의 관점에서, 코드의 특성을 무시하여 원하는"블랙 박스 테스트 "대부분을 테스트하기 위해, 이러한 어려움이 매우 큰, 그것은 용이 사람들은 그를 제지하려고합니다. 하루 동안 I 목요일 밤, 금요일과 토요일은 손도 안 그래서 코드가 기록됩니다. 토요일 오후는, 갑자기 자신이 수정 될 몇 가지 큰 기능 블록을 이동하기로 결정, 그래서 자신의 인프라가 매우 이상하다 쓰기 전에 생각하지만, 시간이 제한되었다, 자신이 쓴 연속의 결과로, 쓰기 비효율적 인 코드 오후와 결합, 매우 성급한했다 6시간이 아키텍처가 완전히 완료, 수정, 심지어 준결승, 어떤 거의 코드 테스트 실시를 지불하지 않았다, 그것은 실패입니다.
  테스트 코드에 더 많은 에너지를 소비하는 미래를위한 싸움을하기 위해, 학생들이 다시 발생과 같은 그런 나쁜 일들을 방지하기 위해, 테스트에 많은 경험을 요구했다.

• 운영 요구 사항

  제 2 동작에 비해 작업이 가장 큰 차이는 중첩 구조의 지지체이고, 식 요인 내부 요인 나타나고 삼각 식은 요소 일 수있다. 어떤 구조의 복잡성 증가의 많은 의심하지 않습니다.
  이것은 많은 문제를 일으켰습니다.
  첫째, 귀하의 항목을 읽는 방법에 대해 설명합니다. 두 가지 방법이 있습니다, 하나를 읽을 수있는 방법의 문자 자동 장치 유형을 사용하는 것입니다 만, 이런 식으로 쓰기 어려운 매우 높고, 발생할 수있는 모든 경우를 문자를 추가 한 후 자신을 취소 할 필요는, 그것은 쓰기 누출 용이 어디서이 생각의 오류,하지만 코드 버그 탐지 및 코드 수정에 해로운도. 두 번째 방법은 내가 사용 여전히 두 가지 읽기 방법 ---- 정규 표현식에 대한 작업을 계속하는 방법이지만, 재귀와 정규 표현식 규칙을 만들 주문형의 대상이 그렇게 할 수없는,패배의 마법에 마법을 사용!핸들 재귀에 재귀를 사용합니다. 핵심 요소는 가호에, 요소 표현의 재귀 용어이지만 요인이 발현 될 수있다. 이어서 제 층 발현 인자 변형 단순히 표현 된 변경이 전체 표현은 상수의 발현을위한 내부 순환 항목으로 알 수있는 일정한 심볼이며, 이는 내부 처리 한 후, 처리 될 수있다 재귀의 열쇠.
  두 번째는 중첩 된 구조는 두 번째로 중요한 작업 장소 인 단순화하는 방법입니다. 빈약 한 인프라 내 상황은 다음과 같이 표시 할 수있는 항목은 다음과 같습니다 항목 -> 표현식 -> 항목 -> 식 ...-> 키, 사실,이 용어는 마지막 안에 중첩에 해당 항목하지만, 형태 자체가 등 유사한 항목의 합병 많은 작업을 제한, 키가 이것은 단지 하나 또는 두 개의 비 재귀 처리에 의해 원래의 형태를 얻을 수없는, 재귀 적으로 중첩입니다. 따라서, 재귀 적 방법의 설계에 중첩 된 재귀의이 종류를 제거 할 수있는 방법을 찾을 수 있습니다.
  나머지는 말할 필요도없이, 두 번째 작업 같은 많은 처리됩니다.
  아래의 구조는 프로그램의 제출 이후에 수정되지 않도록 인해 제출 된 작품의 품질에 매우 나쁜 :
  
  
  

• 문제점 분석

  몇 마디의 사람은 결과의 뒤에 실행 결과를 운영 첫 번째 빛 DesigniteJava는, 분석 하였다 말했다
  
  
  "방법 단지"를 차단하기 위해 여전히 많은 방법이 있지만 매우 높은 우선 모든 결과의 약간 이전 기간에 비해 향상된 만 만 아이템 (17)의 주위 (10)의 다른 상대적으로 균일 한 분포의 시공 방법의 복잡성. 이전 작업과는 달리 trigonMerge방법의 복잡성은 22로 증가하고, MergeInItem복잡성 (18)과 같다. 거기에 "긴 문장"하지만,하지만 긴 항목 생성자가 있지만, 그 기능은 상대적으로 기능을 혼란의 이전 방법보다, 말하기,뿐만 아니라 약간 변경, 상대적으로 간단하다.
  그러나이 문제는 제쳐 놓고, 그것의이 부분이 문제의 많은 부분과 동작을 한 번 더 반복 작업을 많이가, 여전히, 세 번째 작업에서 노출 된 가장 명백한 문제를 살펴 "빌드 관계 구조이다 오류 "문제 :
  첫째 명확한 facter 인터페이스는 조작 요소와 관련되어 factorset 인터페이스는 인터페이스를 구현해야합니다 엔트리 클래스와 클래스의 표현이다 컨테이너 요소에 포장되어 비 컨테이너 요소의 simpleFactor 실현, 일정한 인자 역률 함수, 삼각 함수 요인 방법.
  다음과 같이 세 가지가 내부적으로 정의 :
  
  
  
  이제이 세 가지 방법은 내부 인터페이스를 정의 아주 나쁜 것 같습니다. 이러한 인자의 클래스로 inMerge유사한 내부 위상을 달성하는 인자의 용기가 결합되어 있기 때문에 (내부 병합) 논리적 인터페이스 factorSet 배치해야에있어서, 후 잠시 후에 편리 번호로 결정그것은 쉽지 않을 수있다하지만 지금은 단순히 인자 인터페이스 클래스를 작성하는 방법과는 약간의 불법 생각합니다. 그리고 derive사실, 필요 사실 만 나중에 다운 타임의 변화를 달성하기 위해 운영 할 필요가 factorSet SimpleFactor 클래스와 클래스 내에서 다시 재 작성 없습니다.
  나머지 질문을 반복보다 더와 두 번째로, 여기에 따로 넣어.

버그 분석 프로그램

• 두번째 작업 : 상호 작업을 검출 문제를 칭량하고, 즉 조합 삼각 판정 부는 적어도 특별한을 결정할 때, 두 용어 추출 후 선도 공약수 특정 상황에서 잘 삼각 함수 계산의 다른 유형은 병합합니다 때문에.
• 세 번째 작업 : 작업은 매우 측정 된 크로스 감지 버그, 이유는 통관 위 말했다. 코드를 통해 스키마를 수정할 수 있지만 지금은 여전히 ​​버그는 여전히 알 수없는 테스트를 위해 뒷면에 어떤 코드입니다 전에 그러나 나중에 그는 말했다.

기타 정책 프로그램이 버그에 의해 채택 된 것을 발견

이 버그를 여러 번 프로그램이 활성화되지 않은 다른 사람을 확인합니다.
상기 방법은 주로 단지 테스트 데이터의 일부는 공지 된 표준 기능에 의해 구축 훌쩍 블랙 박스 테스트, 즉에서 사용되지만, 명백하게 이러한 구성 하에서 비효율적이다.
다른 방법은 학생들과의 교류를 포함,(실제로 밖으로 파티에 도달)다른 사람의 코드 테스트에 설명 된 테스트 데이터,(중요한 그럼에도 불구하고). 자동 평가 시험이 부족 다른 사람의 사용의 결과도 있습니다.(나는 폐인 이미)

응용 프로그램 객체 생성 모드

• 인터페이스는 인터페이스 유형이 명확하게 정의되어야한다 방법을 속한 사용해보십시오
• 기본적인 데이터 관리 방법 구현 복제 각 클래스에 대한 얕은 복사 문제에 대한

감정과 경험에 비해

사실, 감정과 경험이 문서의 시작 부분에 반영 거의 완료되었으며, 여기에 설명을 다시 :

• 서, 미리 시뮬레이션을 경유하여 메인 프레임의 개념의 구조를 결정하고 분기 기능의 수를 결정하는 다른 시료를 사용한다.
• 함수가 충족되도록 정의 된 경우 : 함수를 특정로 하나의 함수는 함수가 속한 클래스와 긴밀한 관계를 가지고 있어야로, 개별 통화의 원칙을 사용하려면 기존 조건의 범위를 넘어 생각하지 않으려 고.
• 코드 테스트는 오히려 전체 프로그램을 테스트하는 것보다, 기능 블록을 테스트하기 위해 수행되어야한다.
• 적극적으로, 여러 참조를 논의하기 위해 학생들과 함께 작업 후(손)아이디어, 충돌 사고와 이상 거물