현재 임원으로 일하는 RMI 클라이언트에서 일하고 있습니다 (제가 일하는 회사의 다른 부서에서 개발 됨). 다른 팀은 인터페이스를 소유하고 있지만 IMO는 지나치게 복잡하며 불필요한 (IMO) 복잡한 예외 계층 구조뿐만 아니라 여러 다른 유형이 앞뒤로 전달됩니다.RMI 인터페이스 디자인 원칙
나는 이것이 불필요한 복잡성의 문제라는 것을 여러 번 염두에 두었습니다. 나중에 통합 할 때 문제의 원인이 될 수 있지만 많은 견인력을 얻지는 못합니다. IMO는 불필요하게 많은 양의 코드 공유로 이어질뿐만 아니라 우리가 공유하는 모든 다른 클래스는 감시해야하는 추가적인 버전 요구 사항 집합입니다.
내 주장을 뒷받침하는 데 사용할 수있는 모든 리소스/인수를 아는 사람이 있습니까?
다른 방법으로 내가 잘못된 트리를 짖고 있다고 누가 설득 할 수 있습니까?
우선 내가 말한 것은 RMI의 경우 잘못된 디자인에 추가적인 경고가있을 수 있지만, 설명 된 문제는 RMI뿐만 아니라 일반 Java 인터페이스를 비롯한 모든 인터페이스 구성 요소에도 해당된다고 말할 수 있습니다. 공연.
세부 정보를 모르는 상태에서 나는 내 경험을보고 추측 할 수 있습니다. 이러한 불필요한 인터페이스 복잡성은 종종 구성 요소에 대해 정의 된 무효 또는 불충분 한 비즈니스 요구 사항과 관련이 있습니다. 그렇다면 미래에는 다른 부서의 사람들이 인터페이스를 자주 수정하여 새로운 기능을 따라 잡아야 할 것입니다. 이는 일반적으로 구성 요소 사용자에게 고통의 원인이됩니다. 물론 인터페이스의 변경은 시간이 지남에 따라 자연스럽지 만,이 경우 심층적 인 재 설계가 발생할 수 있습니다.
또한 일반적으로 지나치게 복잡한 인터페이스는 작성자가 구현 세부 사항을 노출한다는 것을 의미합니다. 말할 필요도없이, 이것은 구현의 진화, 다른 기술로의 전환 또는 최적화만으로 인해 불필요한 인터페이스 변경을 초래할 수 있습니다.
마지막으로 사용자에게 필요한 것 이상을 제공하는 것은 사용할 의도가 없거나 존재하지도 않는 기능을 사용할 수있는 직접적인 방법입니다. 앞으로 사용자가 예기치 않은 방식으로 인터페이스를 호출하게 될 수도 있습니다. 그것은 구성 요소의 유지 보수를 지옥으로 만듭니다.
간단한 인터페이스의 핵심 인수는 구성 요소의 명확한 비즈니스 정의, 구현 유연성 향상, 유지 관리 용이성입니다. 그리고 그 이익은 구성 요소 개발자와 사용자 모두에게 이익이된다는 것을 기억하십시오.
잘못된 트리를 짖지 않고 다른 부서에있는 경우 원하는 변경 사항을 얻는 데 어려움을 겪을 수 있습니다. 모든 전투에서 승리 할 수는 없습니다 :-(
"좋은 싸움과 싸우고 싶다."나는 할 일이 있다면 인터페이스의 정리 된 버전으로 선물 할 것을 제안합니다. 하지만 그 외에는 그냥 놓아 둬야 할 수도 있습니다.
당신이하고있는 일을 성취하기위한 데이터가 필요합니다. 용서받지 못하는 3에 동의합니다. 좋은 싸움이고, 짖지 않는 것입니다. 잘못된 나무 - 탄약이없는 깨끗한 코드의 제안을 제시하면 귀가 먹을 수도 있고 더 심해질 수도 있습니다. "내 말은 당신의 말보다 큽니다"와 같은 종류의 경연 대회를 시작할 수 있습니다 - 생산적이지 않습니다.
그냥 내 제안;
,시작 비효율적 인 인터페이스
시작 (기업 제재 위키 위키에 넣어 코드 리뷰, 문서화에 버그, 또는 관련된 다른 티켓 항목 또는 포인트를 문서화 -하지 않습니다 지금 당장 문제를 해결하십시오.) 지금 당장 문서화하십시오. 아직 판단을 내릴 때가 아니며 단지 데이터를 수집하는 것입니다.
당신이이 2에서 충분한 데이터를 가지고때문에 비효율적 인 설계 결정의 손실 또는 오용되는 프로그래머의 생산성에 사건을 - 그것은 비용 포함될 때 주장하는 것은 매우 어렵습니다.
도움이 되길 바랍니다.
감사! 현재 작업중인 프로젝트를 도와주었습니다. – Bigbohne