코드 냄새 94 - 너무 많은 수입품

클래스가 다른 클래스에 너무 많이 의존하면 결합되고 깨지기 쉽습니다. 긴 가져오기 목록은 좋은 지표입니다.

TL;DR: Don't import too much.



문제


  • 커플링
  • 단일 책임 원칙 위반
  • 낮은 응집력

  • 솔루션


  • 클래스 깨기
  • 중간 우발적 구현 숨기기

  • 샘플 코드



    잘못된




    import java.util.LinkedList;
    import java.persistence;
    import java.util.ConcurrentModificationException;
    import java.util.Iterator;
    import java.util.LinkedList;
    import java.util.List;
    import java.util.ListIterator;
    import java.util.NoSuchElementException 
    import java.util.Queue;
    import org.fermi.common.util.ClassUtil;
    import org.fermi.Data;
    //We rely on too many libraries
    
    public class Demo {
       public static void main(String[] args) {
    
       }
    }
    

    오른쪽



    
    import org.fermi.domainModel;
    import org.fermi.workflow;
    
    //We rely on few libraries
    //and we hide their implementation
    //So maybe transitive imports are the same
    //but we don't break encapsulation
    
    public class Demo {
       public static void main(String[] args) {
    
       }
    }
    

    발각



    린터에 경고 임계값을 설정할 수 있습니다.

    태그


  • 커플링
  • 파급 효과

  • 결론



    파급 효과를 최소화하기 위해 솔루션을 구축할 때 종속성에 대해 생각해야 합니다.

    처지







    더 많은 정보


  • Namespaces on Wikipedia

  • 학점



    Zdeněk MacháčekUnsplash의 사진






    다비데 벨로네 🌊 🗡


    @벨로네다비데






    너무 많은 작업을 수행하는 클래스의 지표는 SRP에 반하는 것으로 가져온 네임스페이스의 수입니다. 참조된 네임스페이스(C#의 "using"지시문)가 너무 많으면 클래스가 너무 많은 작업을 수행하고 있음을 의미합니다. 한 번에. 적을수록 좋습니다!


    오후 18:02 - 2021년 10월 11일











    Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.



    앨런 펄리스






    이 기사는 CodeSmell 시리즈의 일부입니다.


    좋은 웹페이지 즐겨찾기