common-lang의 패키지 변경을 피하기위한 래퍼 클래스

우리는 6 개의 다른 모듈에서 common-lang 의존성과 그 클래스를 사용하고 있습니다. 새로운 의존성은 패키지 변경 즉, org.apache.commons.lang.StringUtils에서 org.apache.commons.lang3.StringUtils로 변경됩니다. 따라서 우리는 완전한 코드 기반을 리팩토링해야합니다.
위의 문제를 피하기 위해 우리는 내부적으로 org.apache.commons.lang.StringUtils를 호출 할 프로젝트 고유의 StringUtils 클래스를 작성하기로 결정했습니다. 이후에 패키지 구조가 변경되면 단일 클래스 만 변경할 수 있습니다. org.apache.commons.lang3.StringUtils에서

모든 방법은 여기에 래퍼 클래스를 만들 수있는 가장 좋은 방법이 될 것입니다 무엇 정적 메소드 common-lang의 패키지 변경을 피하기위한 래퍼 클래스

입니까? class StringUtils extends org.apache.commons.lang3.StringUtils을 수행하고 모든 항목을 비워 둘 수 있습니까? 래퍼 메소드/클래스를 작성해야 할 클래스가 있습니다.

출처

2017-05-02 Mahesh Kurade

왜 두 가지를 모두 지킬 수 없습니까? – shmosel

그러면 프로젝트가 불필요하게 많은 제 3 자 의존성에 의존하게됩니다. 또한 개발 팀이 클래스 패스에서 둘 다 사용하기 때문에 클래스 중 하나를 사용할 가능성이 있습니다. –

가장 간단한 방법은 전체 프로젝트에서 으로 패키지 org.apache.commons.lang을 검색/대체하는 것입니다. 다음 번에 이러한 변경이 발생하면 비슷한 변경 사항을 적용하는 것이 좋습니다.

왜 이렇게 꺼리는 지 잘 모르십니까?

출처

2017-05-02 21:09:31 JnRouvignac

변경 사항이 발생하면 도우미 클래스를 만드는 것이 최소한의 영향을 줄 것이라고 생각합니다. 또한 내가 하나의 클래스를 수정해야하기 때문에 내 시간을 절약 할 다른 라이브러리로 바꾸고 싶다면 –

완전한 코드베이스가 아닐 것입니다. 저는 이것이 많은 ifs와 buts이지만 실제로는 필요 없다고 생각합니다. YAGNI와 Occam의 면도칼은 당신의 친구입니다. 그냥 글로벌 검색/교체하고 이동하십시오. 앞으로 더 많은 변화가 필요하다면 결국 어떻게해야 할 지 알게 될 것이지만 예기치 않은 상황을 계획하지 마십시오. – JnRouvignac

common-lang의 패키지 변경을 피하기위한 래퍼 클래스

답변

관련 문제