코드 냄새 147 - 너무 많은 방법

Util 클래스는 프로토콜 수집에 좋습니다.

TL;DR: Don't add an accidental protocol to your classes



문제


  • 가독성
  • 단일 책임 위반
  • 나쁜 응집력
  • 하이 커플링
  • 낮은 재사용성

  • 솔루션


  • 수업 중단

  • 관련 리팩토링






    문맥



    우리는 우리가 찾은 첫 번째 클래스에 프로토콜을 넣는 경향이 있습니다.

    그건 문제가되지 않습니다.

    리팩토링만 하면 됩니다.

    샘플 코드



    잘못된




    public class MyHelperClass {
      public void print() { }
      public void format() { }
      // ... many methods more
    
      // ... even more methods 
      public void persist() { }
      public void solveFermiParadox() { }      
    }
    

    오른쪽



    public class Printer {
      public void print() { }
    }
    
    public class DateToStringFormater {
      public void format() { }
    }
    
    public class Database {
      public void persist() { }
    }
    
    public class RadioTelescope {
      public void solveFermiParadox() { }
    }   
    

    발각



    [X] 자동

    대부분의 린터는 메서드를 세고 경고합니다.

    처지


























    더 많은 정보



    Refactoring Guru

    태그


  • 응집력
  • 블로터

  • 결론



    클래스와 프로토콜을 분할하는 것은 작고 재사용 가능한 객체를 선호하는 좋은 방법입니다.

    학점



    사진 제공: Marcin Simonides on Unsplash


    너무 크거나 뒤틀리거나 복잡해서 유지 관리로 인해 더 나빠질 수 없는 코드는 없습니다.

    제럴드 M. 와인버그






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


    좋은 웹페이지 즐겨찾기