{"push_id":633026754,"size":31,"distinct_size":0,"ref":"refs/heads/master","head":"aaefd1b2272a744a502370b68453e3221c10bc66","before":"4fd871ab5af4c1a68c4f82f306817533e59a10a7","commits":[{"sha":"236a47429b51a71b72e9e73f7ea2aa92271b092c","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"3.1.1 예외처리 기능을 갖춘 DAO\nDB 커넥션등의 제한적 리소스를 사용하는 경우 예외발생 시 해당 리소스를 반환하도록 하는 예외처리 로직 적용","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/236a47429b51a71b72e9e73f7ea2aa92271b092c"},{"sha":"6f579967f61c0e862b260cd35bc156a1557869ce","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"3.2.2 분리와 재사용을 위한 디자인패턴 적용\n- preparedStatement 부분을 분리하기 위한 전략 패턴 적용\n- StatementStrategy interface 생성\n- StatementStrategy interface를 구현하는 deleteAll의 구체 Class 생성","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/6f579967f61c0e862b260cd35bc156a1557869ce"},{"sha":"1cd0d89d536502afc05b52efc1dd4e850a0e9ea3","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"3.2.2 분리와 재사용을 위한 디자인패턴 적용\n- UserDAO에서 구현된 전략패턴으로 PreparedStatement 객체를 생성 반환받도록 로직변경\n\n[문제점]\n- 전략패턴의 관점에서 UserDAO의 DeleteAll이라는 문맥안에 이미 사용할 구체적인 전략이 결정되어 있기때문에\n전략패턴으로의 효용성이 떨어진다.\n\n[해결방법]\nDeleteAll의 전체적인 문맥을 별도의 클래스로 분리하고 UserDAO가 해당 전략패턴을 사용하는 Client로 변경하자.","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/1cd0d89d536502afc05b52efc1dd4e850a0e9ea3"},{"sha":"aae14045d8445223e226f646807cd6f853a2c680","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"3.2.2 분리와 재사용을 위한 디자인패턴 적용\nDI 적용을 위한 클라이언트/컨텍스트분리\n- DeleteAll의 모든 처리과정을 별도의 Method로 분리\n- DeleteAll에서는 사용할 전략을 선택하여 해당 메소드로 전달하는 역할만 하자\n\n[Key] 분리된 메소드는 Jdbc의 CUD를 처리하는 공통의 단계를 가지게 되었고 그중 PrepatedStatement 처리\n과정을 별도의 전략으로 분리하였다.","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/aae14045d8445223e226f646807cd6f853a2c680"},{"sha":"d693544ad617d44f5523d59a883d51ac2cd7cbb7","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"3.3.1 전략 클래스의 추가정보\nUserDAO의 add 메소드 역시 전략패턴의 형태로 변경\n- add Method를 위한 전략 구체 클래스 AddStatementStrategy 생성\n- add Method를 해당 전략을 생성하여 Context Method를 호출하는 로직으로 변경\n\n[장점] add, deleteall 과 같은 메소드에서 공통 부분을 별도의 ContextMethod로 분리하고 \n각각의 변경되는 부분은 별도의 전략 구체클래스로 분리하여 코드가 간결했졌다.\n\n[단점] Method가 추가될 때마다 별도의 구체클래스가 생성되어야 하고\nadd의 경우 추가정보를 받아 저장하기 위한 filed와 생성자가 추가되었다. ㅜㅜ","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/d693544ad617d44f5523d59a883d51ac2cd7cbb7"},{"sha":"50f7cda3d4ef726ad719435ed53dc08c9add6d6c","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"3.3.2 전략과 클라이언트의 동거\n별도의 클래스 파일로 분리한 전략 구체클래스를 UserDAO 메소드의 Local Class로 전환\n- AddStatementStategy 클래스를 add Method 내부로 이동\n- add의 파라미터 user를 final로 선언하여 Local Class에서 Access 가능\n- local class의 user filed와 생성자 제거\n- 기존에 생성한 테스트들 돌려보고 문제가 없으면 AddStatementStategy 클래스 파일을 삭제","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/50f7cda3d4ef726ad719435ed53dc08c9add6d6c"},{"sha":"b00925a95b82e3072aa10b687d57511613ae774f","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"3.3.2 전략과 클라이언트의 동거 (2)\nLocal Class에서 보다 간결한 Anonymous Local Class로 전환\n[Anonymous Local Class]\n- new 인터페이스명() { 클래스본문 }","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/b00925a95b82e3072aa10b687d57511613ae774f"},{"sha":"92bc9f3343296ed1803a0a5c9ca3a2ae020b8d6e","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"3.3.2 전략과 클라이언트의 동거 (3)\n\nRefactor의 inline을 이용하여 별도의 변수로 Assign한 stateMenetStrategy를\njdbcContextWithStatementStrategy 메소드의 파라미터로 직접전달.\n\nDeleteAll Method도 익명내부클래스로 변경\n\n테스트 수행 후 문제가 없으면 DeleteAll을 위해 생성했던 DeleteAllStatementStrategy 클래스파일 삭제","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/92bc9f3343296ed1803a0a5c9ca3a2ae020b8d6e"},{"sha":"4397481d9bb2b4f501162e40e4fb987f28708f5d","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"3.4.1 JdbcContext의 분리\nJDBC의 일반적인 작업 흐름을 갖고 있는 jdbcContextWithStatementStrategy Method를\n별도의 Class로 분리하여 다른 DAO에서도 사용 가능하도록 변경\n- JdbcContext Class 생성\n- jdbcContextWithStatementStrategy 명칭 변경\n- UserDAO : JdbcContext Field 생성\n- UserDAO : JdbcContext Field 에 대한 Setter 생성\n- UserDAO : deleteAll, get에서 JdbcContext Field로 Method Call 하도록 변경\n\n[테스트] 실행\n- 당연하게도 오류가 난다\n- 추가된 JdbcContext Field에 객체를 설정해 주는 부분이 없다.\n\n[다음할일]\nJdbcContext를 DI 받도록 설정","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/4397481d9bb2b4f501162e40e4fb987f28708f5d"},{"sha":"73fce34c17c20081bc35403240f873e061f6766b","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"3.4.1 JdbcContext의 분리\n빈 의존관계 변경\n- JdbcContext Bean 설정\n  ' private dataSource를 위한 Property 설정\n- userDao에서 jdbcContext Bean을 DI하기 위한 property 설정\n\n[테스트] 설정 후 테스트를 수행하자..","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/73fce34c17c20081bc35403240f873e061f6766b"},{"sha":"de853f49d464f0f7bd2482be70e4add4565e7154","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"3.5.2 편리한 콜백의 재활용 : 콜백의 분리와 재활용(1)\n콜백의 경우 prepareStatement에 들어가는 query를 제외하고는 재사용이 가능할것 같다.\n- 별도의 excuteSql 메소드로 해당 부분을 분리\n- deleteAll에서 변경되는 부분인 query를 파라미터로 excuteSql 호출","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/de853f49d464f0f7bd2482be70e4add4565e7154"},{"sha":"33de3e6c33c1b73ffec3cf22ee03ae3e5d4c360f","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"3.5.2 편리한 콜백의 재활용 : 테플릿과 콜백의 결합\nexcuteSql은 쿼리식만 주면 실행이 되는 범용적인 함수로 UserDAO에서 분리하여\nJdbcContext로 이동.","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/33de3e6c33c1b73ffec3cf22ee03ae3e5d4c360f"},{"sha":"ad6caf07b95ab6644660e836feb49a0e3fa3ce72","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"[addtional] UserDAO 잔여 메소드 처리 : add\ndeleteAll와 동일하게 Callback 부분을 별도의 메소드로 분리하여 \njdbcContext의 메소드로 넣어보자.\n\n[차이점]\nuser 객체를 파라미터로 받아서 prepareStatement에 값을 셋팅하는 부분이있다.\nOOP에서는 파라미터의 개수가 다를 경우 overloadding이 되기 때문에 \n동일한 메소드명 executeSql을 사용한다.\n\n[문제점]\nJdbcContext Class에 추가된 excuteSql 메소드에 User Class 객체를 인자로 받음으로\nJdbcContext Class가 User Class를 의존하는 구조가 되었다.\nJdbcContext는 범위적으로 사용하기 위해 별도로 분리하였는데 이러한 의존성이 생긴다면 범용적이지 않다.","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/ad6caf07b95ab6644660e836feb49a0e3fa3ce72"},{"sha":"1fcd5983d44f61a2cf4bbd6f9d02fa087146fca6","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"[addtional] UserDAO 잔여 메소드 처리 : add(2)\nUser 객체를 받는게 아닌 setting 값을 가변인자의 형태로 받아 보자\n- 가변인자로 params를 받아 set해 주도록 변경\n- 호출하는 쪽에서는 쿼리문과 적용할 인자들로 호출\n\n[문제점] 인자가 String가 아니라면 어떻게 하지??","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/1fcd5983d44f61a2cf4bbd6f9d02fa087146fca6"},{"sha":"55d2e7611dc0de301a20e1e6e01b994ba58ef518","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"[addtional] UserDAO 잔여 메소드 처리 : add(3)\n- 인자를 String이 아닌 Object로 처리\n- Object의 유형에 따라 파라미터를 설정해 주도록 코드 변경\n\n[TODO] ResultSet 반환값이 있는 나머지 두개 메소드를 처리해 보자.\n- Context가 Method와 약간 다르다.","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/55d2e7611dc0de301a20e1e6e01b994ba58ef518"},{"sha":"2e6b87209f41deb810b489d7cca333c127b59a69","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"[addtional] UserDAO 잔여 메소드 처리 : getCount(1)\n- JdbcContext의 각 메소드의 이름을 행위에 맞도록 변경해 주었다.\n- 기존의 전환한 메소드는 delete나 add와 같은 Update Method\n\n[Tip] Refactor의 Change Signature를 사용하자. 변경 후 테스트는 필수","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/2e6b87209f41deb810b489d7cca333c127b59a69"},{"sha":"e9afbb5acbba0f130b37b381e1c4983655295732","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"[addtional] UserDAO 잔여 메소드 처리 : getCount(2)\ngetCount 템플릿 콜백 로직 전환\n- deleteAll이나 add와 같이 템플릿 콜백을 사용하도록 변경\n\n[문제점] get의 경우 update와 달리 추가로 요청마다 변경되는 부분이 있다\ngetCount의 경우 아래의 부분\nrs.next();\nreturn rs.getInt(1);\n이러한 변경이 있을때 사용한 방법이 무엇이였는지 생각해 보자.","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/e9afbb5acbba0f130b37b381e1c4983655295732"},{"sha":"c8f1062bc4be319e3bd2f5f580f06b6b621a6c7e","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"[addtional] UserDAO 잔여 메소드 처리 : getCount(3)\n변경되는 부분을 별도의 전략패턴으로 변경\n- ExtractStrategy Class 생성\n- UserDAO에서 전략 구체클래스를 익명 클래스로 생성하여 전달하도록 변경\n\n[주의] Interface의 리턴타입 Generic으로 처리함.","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/c8f1062bc4be319e3bd2f5f580f06b6b621a6c7e"},{"sha":"c388f734c6115bd502079c0092ebff911971cf46","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"[addtional] UserDAO 잔여 메소드 처리 : add(3)\ngetCount와 유사하나 Query를 위한 인자가 있음\n인자가 있는 것을 처리하는 excuteSelectSql을 오버로딩하자.\n\n[문제] \n- 전략 구체 클래스가 UserDAO에 있다 이 부분의 해결방법을 고민해보자\n- JdbcContext에 SELECT와 UPDATE 두개의 Context를 가져가다 보니 새로운 중복이 생겼다 이것도 해결해보자","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/c388f734c6115bd502079c0092ebff911971cf46"},{"sha":"051ced7365a8d4e14f3cfa9211efb46e0a9a02c6","author":{"email":"0c47981363204001f9a532b2804a69d9a6f27ad2@gmail.com","name":"mykumi"},"message":"[addtional] 소스정리\nUserDAO의 모든 데이타처리 부분을 JdbcContext을 주입받아 처리하도록 변경되었다.\n더이상 사용하지 않는 참조나 메소드등을 제거하자.","distinct":false,"url":"https://api.github.com/repos/UCJung/javalab/commits/051ced7365a8d4e14f3cfa9211efb46e0a9a02c6"}]}