Unit1_task1
작업이 비교적 간단하고, 직접 I 분할 항목 정규식을 사용하고 튜플에 의해 최종적으로 이진 그룹에 데이터를 저장, 추출 및 계수의 각 항목의 개수를 설정하고,
횟수, 정렬 마지막 인접한 항목을 병합의 수준은 (조작이 익숙하지 않기 때문에 나는 여기의 HashMap,의 HashMap을 사용하지 않았다). 상기 방법의 collectpoly위한
간단한 최종 식 printPoly 용어 메소드를 출력하는, 상기 방법은, Collections.sort를 사용하기 위해 compareTo와 대등 인터페이스 용어 클래스를 달성하는 것이다
정렬 toString 메소드는 단일 열로 변환하는 방법 printPoly 주요부이다.
그러나 입력 클래스 의 OPE 배급 복잡성은 주로 프로그래밍을 처리 지향 할 수없는 여전히 마음에서, 입력 처리 내부로 작성 너무 많은 기능과 표현에 높은 여전히
핸들에 해당하는 클래스에 의해하지 생성 된 특정 상황, 다루는 저를 주도하지만, 방법에 의해 처리뿐만 아니라, 높은 복잡성 클래스로 이어질 수있는 적절한 기능을 만듭니다.
Unit1_task2
에프
두번째 작업 유도 삼각 발현은 증가하지만, 첫번째 작업 및 본질적인 차이 I 직접 제 코드에 기초하지가 듀얼 데이터를 저장 클래스 용어
쿼드로 기가 여전히 쿼드 ArrayList를 복수 저장하는 데,이 때이 직접 작업 1은 정수 달리 여기서, 원 숫자 인해 HashMap의 값을 사용하지
이 리드는 두 HashMap에 더 많은 불편을 필요로합니다. 이번에는 시간은 주로 형식을 식별에 소요되는 고려 후, 내가 직접에 큰 일반 캡처 그룹을 사용
직접 액세스 시간 및 각 계수가 필요합니다.
새로운 방법 및 작업 1 parseItem 체크 방법을하는 방법에 비해, 검사 방법은 올바른 형식 여부를 확인하는 데 사용되는 새로운 parseItem 방법이 시간을 예정인
공식적인 프리젠 테이션 지침, 해결에 큰 규칙을 사용하여 코드가 더 복잡 주요 추출 방법과는 별도로이 기능 때문에.
내가 collectItems 구현 배치를 유도하고 단순화 때문에 여기 아니, 높은 디자인의 복잡성과 반지와 내 collectItems parseItem 방법의 복잡성을하고 있습니다 볼 수 있습니다
방법에 대응하는 기능을 달성한다.
재귀 유도에 관한 세 번째 작업을 고려하면, 더 이상 변수 그룹을 사용하여 데이터를 저장 까다로운 일이 될 수 없다, 나는 개인적으로 다시 task2 다시, 이번에는 유도 재귀 함수를 사용하여
(여전히 사고의 프로세스 중심 방식에서 해제하지) 방법, 작업 (자연과 계란) 어떤 영향력이있을 것이다 그래서 세 번째 구현 의외로 간단하다.
Unit1_task3
첫 번째 질문은 형식이 우리 앞에 그래서 세 번째 작업은 중첩 된 표현 요소, 다이쇼 (大 正)에 리드를 더 이상 사용할 수 있습니다뿐만 아니라 서식 문제는 내가 작업에서 발생
가장 어려운 문제. 중첩 된 괄호의 표현을 허용함으로써, 더 이상 판사에게 읽고있는 동안은, 가장 원시적 인 방법을 사용할 수 있습니다, 대형 일반 형식을 구문 분석하는 데 사용할 수 없습니다. 두 개의 추가 기능을 구현하는 방법
표현은 "+"에있어서 배수 "*"포괄적 인 표현은 두 식 사이에 0 또는 1, 또는 널있을 경우 접속되어 구현에 접속되고, 상기 방법은 변성 확인에 관한 것이다
단일 표현의 단순화, 그것은 비교적 간단한 형식의 준수 여부를 먼저 확인 (예, 여기에 내가 부분 단순화 된 taks2 식의 모양이다) 단순화와 라인에서 수행하는 경우,
인자 발현을 결정할 때의 오판을 방지하기 위해, 논리식 브래킷 적법성을 확인하는 checkbrackets 방법은, 다른 기능의 역할 task2에서 동일하다.
주로 diffsin 이러한 두 가지 기능 혼자 질문의 형식을 판별 할 수 없습니다 밖으로 분리하는 것, 그것은 단지 추구에서 선두로 포맷 조화를 결정할 수 있기 때문에 diffcos의 복잡성,
발현 박리 층, 그리고 마지막으로 기본 항목, NO, 리턴 널에 속하는 것인지를 판정한다.
task2 때문에 나는 그렇게 유도 규칙에 많은 문제가 아니라 누가 골칫거리가 도출되지 task3 대부분의 생각,하지만 층의 레이어 후, 계정에 확장 task3를 취할 것
중첩가 발생 포맷 해결 문제를 괄호? 난 정말 아직 너무 어려.
방법은 형식을 결정하는 가장 큰 실수는, 둘 다 긍정과 부정적인 측면에서 종합적인 판단 될뿐 아니라 잘못된 형식의 사용을 무시하고, 상영 할 수있는 적절한 형식을 구성하는 방법에 대해 생각해야
반복되는 코드를 작성, 코드 재사용 율, 방법의 높은 복잡성로 이어지는, 큰 실수의 판단 형식에 표시 저를 주도, 제외 입력합니다.
S2 : 자기 버그 분석 및 버그 발굴 방법
작업 1과 task2 단계에서, 어떤 버그 그럼에도 task3 나를 인도도 언급 한 프로그램의 구조의 분석에 위 task3 강한, 중앙 버그 발생의 테스트 및 상호 운용성 테스트에 나타나지 않습니다
코드 형식의 복잡성을 분석하는 것은 그것의 주요 문제에 I 선도, 다른 방법 형식의 판단과 커플 링의 높은 복잡성 똑바로, 그리고 때문이다, 그 중 일부는 결정되어야한다
나는 잘못된 형식이 식별되지이었고, 일부는 제대로 해결해야한다, 나는 버그에서 확인 된 테스트 및 상호 운용성 시험에서 아주 강력한 잘못된 형식으로 확인했다. 개요
모양은 두 가지 이유 때문에, 하나의 개별적 코드 재사용의 낮은 속도의 결과로, 모듈 형식을 결정 밖으로 추출되지 않고, 변경은 상대적으로 문제가되어, 다른 기능들과 결합하는 제 2 포맷 식별 과정도 상기 가이드
각 형식 인식 응용 프로그램을 안내 시나리오는 문제가 있습니다.
그런 다음 발굴의 버그입니다. 나는 보통 첫번째 어려운 문제를 다른 사람이이 문제를 매우 해결하기 위해 만약 내가, 정착 다른 사람의 수단 봐, 처리에서 발생했습니다 기반으로하고있어
뛰어난 핸들링, 자연스럽게 경험에서 배우고 자신의 마음 짧은 보드를 만들 수 있다는 것을, 다른 사람은 길고 복잡한 처리, 그것은 코드의이 부분에 관해서 이렇게 촬영 한 경우, 다른 손을
발생할 수있는 매우 문제에.
그때 발생하는 높은 복잡도 경우 순환 종속성에 대한 의존성 및 복잡도 분석 코드는, MetricsReloaded 플러그를 사용하여이 섹션의 번호를 확인한 후,
코드의이 부분에 초점 보면, 높은 복잡성을 방법을 위해, 어떤 누락 상황이 있는지 확인하기 위해 지점 문에서 모습을 초점을 맞추고 있습니다. 이러한 버그가 가장 어려운 히트 등장한다.
S3 : 응용 프로그램 개체 생성 모드
task2에서 공장 패턴에 부딪 쳤습니다,하지만, 지금 표시가 일부 코드를 단순화 않는 공장 패턴을 사용하여 내 프로그램에서 연습. 이 방법은 재구성 된 경우
도 증가 코드 재사용 율은, 그래서뿐만 아니라 쉽게 수정, diffcos (), diffpow ()이 클래스의 파생을하는 diffFactor가 (), diffAdd (), diffmult ()를 생성 생성) (diffsin 고려하지만,
더 읽기 이러한 프로그램, 그리고 더 나은 캡슐화.
S4 : 우수한 콘트라스트 및 코드 아이디어
일부 우수한와 코드 후, 내 가장 큰 느낌은 내가 자신의 코드 스타일이 프로그램의 준비에 큰 차이가, 내 생각은 여전히 찬성 바이어스되는 프로세스 지향하는 것이 아니라 객체 지향
내 기존의 처리 수단이 매우 다르다 왜냐하면, 나는 종종 사건의 끝에서 "주"로 이어질 코드 결합 높은 방법이 항상 행의 수, 심지어 클래스 라인 라인 제한에서 제한을 초과하거나,
이것은 내가에 반영해야 할 것입니다, 과정 중심의 사고에서 갱스터 코드 변경을 통해 빨리 가능한 멀티 읽어보십시오.
개인적인 감정과 경험에 의해 이어, 객체 지향이 과정은 정말 어려운, 더 가까이 우리의 실제 미래의 일에 대한 우리의 프로그래밍 수준의 시험이지만, 또한,이 과정에 더 많은 시간을 할애해야한다.
OO 코드를 작성할 때 또한, 우리는 여러 가지 방법이 오히려 문제가 발생하는 것보다 달성하기 위해 몇 가지 주요 카테고리를 만들어 좋은 일반적인 생각은, 새로운 방법을 만들 것을 처음에서 이는 매우입니다한다
코드는 쉽게 커플 링의 높은 수준으로 이어질하고, 필요 패치, 버그로 인해 방법을 수정할 계속이 매우 많은 시간이 소요됩니다.