GUI 코드에 대해 기억해야 할 것은 이벤트 중심적이며 이벤트 중심적 코드는 항상 무작위로 구성된 수많은 이벤트 처리기처럼 보일 것입니다. 이벤트가 아닌 코드를 클래스에 삽입하려고 할 때 정말 혼란스러워집니다. 물론 이벤트 핸들러를 지원하는 것처럼 보이며 이벤트 핸들러를 작고 작게 유지할 수는 있지만 추가 지원 코드가 떠 다니면 GUI 소스가 부풀어지고 지저분 해 보입니다.
그렇다면 이것에 대해 무엇을 할 수 있으며, 어떻게 리팩토링하기 쉽게 만들 수 있습니까? 글쎄, 나는 때때로 리팩토링에 대한 나의 정의를 때때로 내가하는 일에서 내가 코딩 할 때 지속적으로하는 일로 바꿀 것이다. 왜? 리팩토링을 사용하면 코드를 더 쉽게 수정할 수 있기 때문에 다른 방법은 아닙니다. 여기서 의미를 변경하도록 요청하는 것이 아니라 코드를 다르게 보려면 약간의 정신 미용을 수행하도록 요청합니다.
내가 가장 일반적으로 사용하는 세 가지 리팩토링 기술은 Rename , Extract Method 및 Extract Class 입니다. 하나의 다른 리팩토링을 배운 적이 없다면이 세 가지 코드를 사용하여 코드를 깨끗하고 체계적으로 유지할 수 있으며 질문 내용에서 거의 동일한 리팩토링을 거의 사용하는 것처럼 보일 것입니다. GUI 코드를 얇고 깨끗하게 유지하십시오.
세계에서 GUI와 비즈니스 로직을 최대한 분리 할 수 있지만 GUI 코드는 중간에 폭발 한 코드처럼 보일 수 있습니다. 내 조언은 GUI를 올바르게 관리하는 데 도움이되는 추가 클래스 또는 2 개가 없어지는 것이 아니라 MVC 패턴을 적용하는 경우 반드시 View 클래스 일 필요는 없다는 것입니다. 중급 클래스는 사용자의 관점과 매우 유사하므로 편의를 위해 클래스를 병합해야하는 경우가 많습니다. 이것에 대한 나의 취지는 모든 시각적 논리를 관리하기 위해 GUI 특정 계층을 추가하는 것이 실제로 아프지 않다는 것입니다.
그러므로 나의 충고는 :
- GUI가 View (또는 중개 계층)에 연결되는 방법을 호출하고 정의하는 것 외에는 GUI 바로 뒤에는 아무것도하지 마십시오.
- 모든 뷰 관련 사항을 GUI 클래스 당 단일 클래스 또는 GUI 클래스 당 단일 클래스로 분류하려고 시도하지 않는 것이 좋습니다. 대안은 GUI 로직을 관리하기 위해 작고 관리하기 쉬운 클래스를 많이 만드는 것입니다.
- 메소드가 4-5 줄의 코드보다 조금 더 크게 보이기 시작하면 이것이 필요한지 여부와 클래스를 의미하더라도 메소드를 간결하게 유지할 수 있도록 메소드를 추출 할 수 있는지 확인하십시오. 더 많은 방법으로.
- 클래스가 실제로 크게 보이기 시작하면 복제 된 기능을 모두 제거하여 시작한 다음 다른 클래스를 추출 할 수 있도록 메소드를 논리적으로 그룹화 할 수 있는지 확인하십시오.
- 한 줄의 코드를 작성할 때마다 리팩토링을 고려하십시오. 작동하는 코드 줄을 얻는 경우 기능 복제를 피하기 위해 리팩터링 할 수 있는지 또는 동작을 변경하지 않고 조금 더 좁힐 수 있는지 확인하십시오.
- 불가피하게, 특히 시스템의 일부 또는 다른 부분이 약간 부풀어 오르기 시작한다는 느낌이들 것입니다. 특히 리팩토링을 무시할 때 더욱 그렇습니다. 잘 짜여진 코드 기반이 있어도 할 수있는 일 이 더있는 것처럼 느낄 수 있습니다. 이것은 소프트웨어 작성의 현실이며, 더 많은 것이 "더 나은"일을 할 수 있다고 항상 느끼게되므로 전문적인 업무 수행과 금도금 사이의 균형을 잡아야합니다.
- 깔끔하게 코드를 작성하고 유지할수록 코드의 부풀어 짐이 줄어 듭니다.