본문 바로가기

개발이야기/리펙토링

Java refactoring 자바 리펙토링 하루만에 파해치기



리펙토링강의 3/10

  • OOP(Object Oriented Programming) 리펙토링
    • 중요한것 : operation(method) - interface등을 통해 전체 구조를 알 수 있기 때문
    • 더 중요한것 : 개발경험 - 개발경험을 통해서 다른 코드와 비교가 가능하기 때문(비교를 통해 불편&더러운 코드인 것을 파악)
      • Java가 1.0->2.0->...->8.0 버젼이 올라가면서 달라지는 것을 직접 개발하는 것도 개발경험
  • 리펙토링
    • 겉으로 드러나는 기능은 그대로
      - interface를 수정X @Override으로 메서드를 추가하여 구조변경을 하는게 중요!!
      • 코드 구조 변경 즉 기능추가X - like 자동차 튜닝
      • 가독성 높이고 유지보수 - 기존코드 절대 건드리면 안됨(특히 interface)
      • 오류해결은 리펙토링X
      • 기능추가 != 리펙토링
  • 리펙토링 관련 문제
    • 데이터스키마 별도 소프트웨어 계층으로 관리
    • 인터페이스를 바꾸면 안됨 최대한 그대로 유지
    • 설계변경이 필요한경우에는? 상속이나 Adapter pattern을 활용하는 게 좋음
      - Adapter용어를 쓰게 되면 [기존에 있는 코드에 확장하는 것이다] 라고 암시적으로 말한다고 보면 됨.
  • 디자인 패턴
    - 자주 발생되는 문제들을 해결할 때 일정하게 반복되는 솔루션
    - 다형성을 적극 활용
    • API중 클래스명 [업무명+디자인패턴명] (ex.WindowAdapter, DocumentBuilderFactory ...)
  • JAVA API에서 리펙토링 되어 있는 것을 볼 수있다
    • EX. Database 연결되는것 기존 api가 getConnection(url,id,pw) 이렇게 있었던 적이 있었음(Java low version). id, pw가 직접 입력 되는 것이 자바 버젼이 올라가면서 보안이 중요해지면서 getConnection(url,properties) 가 오버로딩 되게 되는 JAVA 리펙토링이 이루어지게 됨.
      - 똑같은 이름을 사용하여 거부감 없게 되었음
  • 각 디자인 패턴의 관계

그림. 디자인패턴 관계 그래프


    • 각 패턴에 대해서 상속관계에 대해 알면서 리펙토링을 해야한다.
      ex. 싱글톤을 모르면서 abstract Factory를 쓰는건 안됨.

    • 각 디자인 패턴에 대해서 명확히 알면서 수행해야한다.




실습예제 Book의 여러 종류가 있고 겹치는 코드가 있다면?

1. 안좋은예

(1) Book.java(interface)


(2) ChildBook.java(class)


(3) NewBook.java(class)


-문제점-

priceCode와 getPointPercent의 코드가 중복된다.


2. 좋은예 - 어떻게 해야할지 한번 고민해보고 펼쳐보자.




  • UML
    • Unified Modeling Language - 모델링 언어
    • UML을 통해 구조를 잘 파악해야하고, 업무를 함에 있어 의사소통의 창구로 잘 사용해야 한다.
      (그러려면 uml에 대해 잘 알아야하지)

스크린샷. 매우 잘 정리(상속, 인터페이스)되어 있는 ArrayList class


  • Java refactoring이라면 자바 API에 대해 잘 알아야 한다.
    • ex.Customer가 Book을 여러개 Rental한다고 가정한다면?
       Customer가 rental을 여러개 쓴다고 하자. 그러면 ArrayList를 써야할까? 아니면 Vector을 써야할까?
      • Vector과 ArrayList의 차이는 thread의 synchronize 차이가 있음. 그러므로 만약 Rental에 대해 접근이 동시에 이루어 지지 않게 의도적으로 쓴다면 당연히 Vector을 써야하는게 맞음.
    • 더 나아가서 기존에 만들어진 Java.Object API들(혹은 상속받은 super class의 method 들) 충분히 이용하는게 좋음.- 좋은 예시인거 같음!
      임의의 class에서 어떤 method가 Vector 변수를 문자열로 보여주는 코드를 만든다고 한다면 굳이 toString을 오버라이드(@Override)해서 새로 만들어야 할까?(비용이 생긴다.) 그냥 Vector을 return하는 것도 하나의 방법이다. 왜냐면 Vector에는 이미 toString이 선언되어 있고 쓸 수 있기 때문이다.(json, xml 등등 동작을 확장하는 리펙토링을 하더라도 부담없이 적용가능함)


교훈 : Java refactoring하고 싶으면 JAVA에 대해서 빠싹하게 알고 있어야 한다. 공부하자.


End of Document