리펙토링강의 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에 대해 잘 알아야하지)
- interface, abstract을 잘 활용해야함
- Collection API를 분석하면 어떻게 interface와 abstract를 잘 쓸 수 있는지 파악 가능.
JAVA API DOC - ArrayList 보러가기(클릭)
스크린샷. 매우 잘 정리(상속, 인터페이스)되어 있는 ArrayList class
- 예외관리 정책 활용
- 예외에 대해 잘 정리를 하여 정책으로 만들어 정리
- 아래 [Effective Java] 서적의 내용을 참고하여 정책을 만들면 좋음
- 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