괴물 같은 스트럿 행동을 다루는 방법?

StackOverflow https://stackoverflow.com/questions/209516

문제

Struts 1.2.4를 사용 하여이 거대한 레거시 Java 웹 앱을 물려 받았습니다. 행동에 관한 구체적인 질문이 있습니다. 대부분의 페이지에는 정확히 하나의 동작이 있으며, ProcessExecute () 메소드는 끔찍한 괴물입니다 (요청 매개 변수를 기반으로 매우 길고 중첩 된 IF 문의 톤).

작업이 명령 패턴의 구현이라는 점을 감안할 때, 나는 이러한 작업을 사용자 제스처 당 하나의 동작으로 나누는 것으로 생각합니다. 그래도 이것은 큰 리팩토링이 될 것이며 궁금합니다.

  1. 이것이 올바른 방향입니까?
  2. 모 놀리 식 행동 내부의 혼란을 다루는 중간 단계 인 내가 취할 수있는 중간 단계가 있습니까? 액션 내부의 또 다른 명령 패턴일까요?
도움이 되었습니까?

해결책

이것을 다루는 나의 방법은 다음과 같습니다.

  • '한 번에 모든 것을하지 마십시오'
  • 당신이 아무것도 바꿀 때마다 당신이 찾은 것보다 더 잘 두십시오.
    • 조건부를 별도의 조치 구현으로 교체하는 것은 한 단계입니다.
    • 더 나은 방법 : 구현을 액션 클래스와 분리하여 프레임 워크를 변경할 때 사용할 수 있도록하십시오.
    • 새 명령 구현을 유지하십시오 물론 Struts에 대한 언급이 없으면 새로운 작업을 이러한 구현 주변의 래퍼로 사용하십시오.
    • 모든 데이터를 복사하지 않고도 전달하려면 Struts ActionForms에 인터페이스를 제공해야 할 수도 있습니다. 반면 - 일반적으로 많은 문자열 인 액션 폼 이외의 다른 물체를 전달하고 싶을 수도 있습니다 (다른 질문을 참조하십시오. Struts 1.2 Actionforms)
  • 부품을 최신 및 더 나은 기술로 마이그레이션하십시오. Struts 1.2는 그것이 나왔을 때 훌륭했지만 분명히 당신이 영원히지지하고 싶은 것은 아닙니다. 이제 더 나은 프레임 워크의 세대가 있습니다.

확실히 더 많은 것이 있습니다 - 죄송합니다. 여기 시간이 부족합니다 ...

다른 팁

내 마음 속에 행동은 전혀 코드를 많이 가져서는 안됩니다. 요청 및 응답과 직접 상호 작용해야합니다. 양식 또는 요청 매개 변수에서 일부 데이터를 가져 와서 해당 정보를 서비스 계층에 전달한 다음 일부 항목을 응답 객체에 넣거나 사용자 세션에 일부 데이터를 저장할 수 있습니다.

액션 수업과의 상속을 피하는 것이 좋습니다. 처음에는 좋은 생각처럼 들리지만 조만간 코드베이스를 강력하게 만드는 것보다 신발을 신고 있다는 것을 조만간 생각합니다. Struts에는 그대로 충분한 기본 작업이 있습니다. 새 작품을 작성하면 웹 계층에 코드가 있어야 할 코드가있을 수 있습니다.

그것은 단지 나의 개인적인 경험입니다.

나는 전에 이런 종류의 것을 다루었 다. 좋은 첫 번째 단계는 다른 기본 클래스를 액션과 원래 괴물 액션 클래스 중 하나 사이의 상속 체인에 삽입하는 것입니다 (Classa라고 부릅니다). 특히 한 번에 모든 것을 할 시간이 없다면. 그런 다음 기능 조각을 작은 병렬 작업 클래스 (ClassB, Classc)로 끌어 올릴 수 있습니다. 원래 Classa와 새로운 리팩토링 된 클래스 사이의 공통적 인 모든 것은 새로운 기본 클래스로 끌어 올릴 수 있습니다. 따라서 계층은 이제 다음과 같습니다.

Original Hierarchy:      New Hierarchy:

     Action                   Action
       |                        |
       |                      BaseA
  (old)ClassA                   |
                       +--------+----------+
                       |        |          |
                   ClassB (new)ClassA   ClassC
  1. 한 번에 하나의 방법을 가십시오
  2. 나중에 다시 플레이 할 수있는 몇 가지 테스트 사례를 기록하십시오. 여기에 예 (코드를 통해 가능한 한 많은 경로를 누르십시오. 즉,이 작업을 호출하는 페이지의 모든 사용자 제스처
  3. 더 작은 일을하는 작은 방법을 만들어 복잡성을 줄이는 방법을 리팩토링합니다.
  4. 이 작업을 수행 할 때 테스트를 다시 실행합니다

이 시점에서, 당신은 큰 거대한 성가신 방법의 리팩토링 버전을 가지고 있습니다. 지금 실제로 특정 조치를 만들기 시작할 수 있습니다.

새로 리팩토링 된 클래스를 기본 클래스로 사용하고 리팩토링 된 작은 방법을 사용하여 각 특정 작업을 하위 클래스로 구현할 수 있습니다.

이 작업을 마치면 클래스간에 공유되는 논리의 좋은 그림이 있어야하며 필요에 따라 해당 방법을 풀거나 밀 수 있습니다.

재미는 없지만 코드베이스에서 잠시 동안 작업한다면 시간과 두통을 절약 할 수 있습니다.

힘든 문제이지만 초기 웹 앱 개발의 전형적인 문제.

가장 먼저 어떤 논리가 비즈니스 행동을 구성하는지 생각하기 시작해야합니다. 어떤 논리가 "흐름"(즉, 사용자가 보는 것)을 구성하고 어떤 논리가 자신이 보는 것에 대한 내용을 얻는지를 생각해야합니다.

공장과 인터페이스의 경로를 내려갈 필요는 없습니다. 소급 구현은 훨씬 덜 유용하지만 ... 비즈니스 로직 및 데이터 검색 로직을 어떤 종류의 대표단으로 통합하고, 해당 논리의 성공/실패에 따라 페이지 흐름을 결정하기 위해 Struts 조치를 남겨 두십시오.

거기에서 당신은 몇 주가 걸리고 그것을 분쇄해야합니다

한 가지 긴 방법은 케이스가 매우 짧은 단일 스위치 문 (토큰 구문 분석 또는 그와 비슷한 것)이 아닌 한 결코 좋지 않습니다.

최소한 긴 방법을 설명 이름을 가진 작은 방법으로 리팩게 할 수 있습니다.

가능하다면 양식을 검사하여 수행해야 할 일을 인식하여 방법을 시작한 다음 다양한 옵션으로가는 방법을 시작할 수 있습니다. 중첩 된 if는 없지만 코드를 읽을 수없는 경향이 있습니다. 단지 

enum Operation {
  ADD, DELETE;
}

...

Operation operation = determineOperation(form);
if (operation == Operation.DELETE) { 
  doDelete(form); 
} else if (operation == Operation.ADD) {
  doAdd(form);
}

당신이 그렇게 멀리 갈 수 있다면 당신은 당신의 논리를 멋지고 깨끗하게 가지고 있고 당신이 원하는 리팩토링을 할 수 있습니다.

어려운 부분은 논리를 명확하게하는 것이며 단계적으로 그렇게 할 수 있습니다. 문제가 무엇인지 정확히 이해할 때까지 패턴을 선택하지 마십시오.

코드를 리팩토링하려는 경우 기존 코드에 대한 테스트를 먼저 작성해야하므로 리팩토링을 시작한 후에는 기능을 변경하지 않아야합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top