[5주차] (오형석, 김수환, 권용현) #1
Comments
[1장 오브젝트와 의존관계]객체지향설계 DAO의 분리객체지향 설계는 미래의 변화에 대비할 수 있어야 한다.
public void add(User user) throws ClassNotFoundException, SQLException {
Connection c = getConnection();
...
}
public User get(String id) throws ClassNotFoundException, SQLException {
Connection c = getConnection();
...
}
private Connection getConnectionO throws ClassNotFoundException, SQLException {
Class.forName("com.mysql.jdbc.Driver");
Connection c = DriverManager.getConnection(
"jdbc:mysql://localhost/springbook", "spring", "book");
}
: 변경사항에 대한 검증
테스트를 통해 기능이 유지되는지 검증할 수 있다.
public abstract class UserDao {
public void add(User user) throws ClassNotFoundException, SQLException {
Connection c = getConnection();
}
public User get(String id) throws ClassNotFoundException, SQLException {
Connection c = getConnection();
}
public abstract Connection getConnection() throws ClassNotFoundException, SQLException;
public class AUserDao extends UserDao {
public Connection getConnection() throws ClassNotFoundException, SQLException {
// A 프로젝트 DB connection 생성코드
}
}
public class BUserDao extends UserDao {
public Connection getConnectionO throws ClassNotFoundException,
SQLException {
// B프로젝트 DB connection 생성코드
}
}
상속을 통해 슈퍼클래스의 기능을 확장하기 위한 디자인 패턴
서브클래스에서 구체적인 오브젝트 생성방법을 결정하게 하는것
dao의 확장오브젝트는 변한다. 변화에는 특징이 있다. 변화 마다 각기 대응 방식이 다르다
public class UserDaoTest {
public static void main(String[] args)
throws ClassNotFoundException, SQLException {
ConnectionMaker connectionMaker = new AConnectionMaker();
// A 프로젝트에서 사용하는 db연동
UserDao dao = new UserDao(connectionMaker);
// 구현 클래스 결정 -> 객체 생성
}
}프로젝트 마다 사용하는 db가 다름 -> 같은 문제가 발생
클래스간의 관계를 설정하는 방법
객체지향 설계를 위한 여러가지 방법 개방 폐쇄 원칙
높은 응집도와 낮은 결합도
전략패턴
제어의 역전 (IoC : Inversion of Control)낮은 결합도를 활용하여 테스트, 유지관리를 더쉽게 하기 위한 설계 원칙
팩토리 : 객체 생성 방법을 결정 -> 객체를 반환
public class DaoFactory {
public UserDao userDao() {
ConnectionMaker connectionMaker = new AConnectionMakerO; UserDao userDao = new UserDao(connectionMaker);
return userDao;
}
}
public class DaoFactory {
public UserDao userDao() {
return new UserDao(connectionMaker());
}
public AccountDao accountDaoO {
return new AccountDao(connectionMaker());
}
public MessageDao messageDaoO {
return new MessageDao(connectionMaker());
}
// ConnectionMaker를 생성하는 코드
// 중복을 피하기 위해 따로 메소드를 구현
public ConnectionMaker connectionMaker(){
return new AConnectionMaker();
}
}
프로그램의 제어 흐름 구조가 뒤바뀌는 것
스프링의 IoC
싱글톤 레지스트리와 오브젝트 스코프
객체의 인스턴스를 한개만 생성되게 하는 패턴
스프링은 싱글톤 패턴으로 객체를 생성하고 관리한다.
멀티 스레드 환경에서 여러 스레드가 동시에 접근 할 수 있다.
객체가 생성되고 존재하고 적용되는 범위 싱글톤 스코프
그 외의 스코프
의존관계 주입
A ----> B : A가 B에 의존하고 있다. B의 변화가 A에 영향을 미친다. ex)
IoC를 적용하여 객체지향적인 설계, 디자인 패턴, 컨테이너에서 동작하는 서버 기술을 사용한다. 의존관계 검색과 주입
정리
스프링을 사용한다고 좋은 객체지향 설계와 깔끔하고 유연한 코드가 저절로 만들어지는건 절대 아님 |
[토비의 스프링 2장] 테스트테스트란 무엇이며, 그 가치와 장점, 활용 전략, 스프링과의 관계를 살펴본다.
테스트 코드를 작성해야 하는 이유는 뭘까?
웹에서 테스트를 하기 위해서는 모든 레이어의 기능을 다 만들고 나서야 테스트가 가능하고, 실패의 원인이 테스트 코드가 아닐 가능성도 존재한다.
단위 테스트를 이용함으로써 어느 부분에서 문제가 생기는지 상대적으로 명확하게 판단 가능 **그래도 단위 테스트를 사용 하더라도 사람이 확인을 해야되는 거잖아...? **->JUnit 프레임워크가 해결해준다
만들어진 모든 코드는 빠짐없이 테스트로 검증된다!
추가하고 싶은 기능을 구현 전에 먼저 테스트 코드로 구현한다.
테스트에서 사용될 정보나 오브젝트( 보통은 @beforeeach와 같은 메서드를 이용해서 제공한다) _⭐️스프링 컨테이너를 띄우지 않아도 되는 테스트라면 띄우지 않는 것이 가장 좋다._⭐️ public class UserDaoTest {
UserDao userDao;
@BeforeEach
public void setUp() {
ApplicationContext applicationContext = new GenericXmlApplicationContext("spring/applicationContext.xml");
this.userDao = applicationContext.getBean(UserDao.class);
...
}
...
}@ExtendWith(SpringExtension.class) // (JUnit5)
@ContextConfiguration(locations="/spring/applicationContext.xml")
public class UserDaoTest {
@Autowired ApplicationContext applicationContext;
UserDao userDao;
@BeforeEach
public void setUp() {
System.out.println("applicationContext = " + applicationContext);
System.out.println("this = " + this);
this.userDao = this.applicationContext.getBean("userDao", UserDao.class);
...
}
...
}
여기서 궁금했던것: 어노테이션 없어도 어차피 배포용 데이터베이스를 건들지 않는데 어노테이션의 쓸모?
(extra: 테스트 코드를 돌리다 보면 클래스 단위로 돌릴때 실패하던 테스트 코드가 메소드 단위로 돌리면 성공하는 경우가 있는데 이때 문제가 @DirtiesContext 안적어줘서 그럴 수도 있음)
|
|
템플릿 ? 변하는 것과 변하지 않는 것public void deleteAll() throws SQLException {
Connection c = dataSource.getConnection();
PreparedStatement ps = c.prepareStatement("DELETE FROM users")ㅣ
ps.executeUpdate();
ps.close();
c.close();
}→ error가 발생하면 close 메소드가 실행되지 않아 리소스가 반환되지 않을 수 있음 public void deleteAll() throws SQLException {
Connection c = null;
PreparedStatement ps = null;
try {
c = dataSource.getConnection();
ps = c.prepareStatement("DELETE FROM users");
ps.executeUpdate();
} catch (SQLException e) {
throw e;
} finally {
if (ps != null)
try {
ps.close();
} catch (SQLException e) {
// 이제 여기서 ps 리소스 반환 실패를 잡을 수 있다
}
if (c != null)
try {
c.close();
} catch (SQLException e) {
}
}
}→ close는 해줄 수 있겠으나 모든 메서드에 try/catch/finally를 다 붙이면 가독성도 안좋고 중복도 많이 발생 어떻게 해결할 수 있을까?
private PreparedStatement makeStatement(Connection c) throws SQLException{
PreparedStatement ps;
ps = c.prepareStatement("delete from user");
return ps;
}→ 변하는 부분은 매번 새로 만들어줘야함
템플릿 메소드 패턴은 상속을 통해 기능을 확장해서 사용하는 부분. 변하지 않는 부분은 슈퍼 클래스에 두고 변하는 부분은 추상 메서드로 정의해서 서브 클래스에서 오버라이드하여 새롭게 정의해 쓰는 것. public abstract class UserDao {
// executeDao()같은 메소드를 두고, 매번 반복되는 try~finally 구문을 기록하고
// 그 사이에 이 아래 makeStatement()를 끼워 넣어둔다
public abstract PreparedStatement makeStatement(Connection c) throws SQLException;
}public class UserDaoDeleteAll extends UserDao{
private PreparedStatement makeStatement(Connection c) throws SQLException{
PreparedStatement ps;
ps = c.prepareStatement("delete from user");
return ps;
}makeStatement()만 바뀌고 새로 메소드를 만들때도 이 메서드만 보면 됨. 하지만 두가지 문제점이 존재
OCP 를 잘 지키는 구조이면서도 템플릿 메서드 패턴보다 유연하고 확장성이 뛰어난 것이, 오브젝트를 아예 둘로 분리하고 클래스 레벨에서는 인터페이스를 통해서만 의존하도록 만드는 전략 패턴 public interface StatementStrategy {
PreparedStatement makePreparedStatement(Connection c) throws SQLException;
}public class DeleteAllStatement implements StatementStrategy {
public PreparedStatement makePreparedStatement(Connection c) throws SQLException {
PreparedStatement ps = null;
ps = c.prepareStatement("DELETE FROM users");
return ps;
}public void deleteAll() throws SQLException {
Connection c = null;
PreparedStatement ps = null;
try {
c = dataSource.getConnection();
StatementStrategy stmt = new DeleteAllStatement(); //여기만 바꾸면 됨
ps = stmt.makePreparedStatement(c);
ps.executeUpdate();
} catch (SQLException e) {
throw e;
} finally {
if (ps != null)
try {
ps.close();
} catch (SQLException e) {
}
if (c != null) try {
c.close();
} catch (SQLException e) {
}
}
}→ 전략 패턴을 그럭저럭 적용함 하지만 전략 패턴은 필요에 따라 컨텍스트는 그대로 유지되면서 전략을 바꿔쓸 수 있음(OCP) 그러나 위 코드는 구체적인 전략 클래스인 DeleteAllStatement를 사용하도록 고정되어 있음. 컨텍스트가 StatementStrategy 인터페이스 뿐 아니라 특정 구현 클래스인 DeleteAllStatement를 직접 알고 있다는건 전략 패턴에도 OCP에도 잘 들어맞는다고 할 수 없음 위 문제를 어떻게 해결? Context를 사용하는 Client가 어떤 전략을 사용하게 할 것인지 정하도록 하자 // Client
public void deleteAll() throws SQLException {
StatementStrategy stmt = new DeleteAllStatement();
jdbcContextWithStatementStrategy(stmt);
}
// Context
public void jdbcContextWithStatementStrategy(StatementStrategy stmt) throws SQLException{
// SQL 쿼리(PreparedStatement)와는 결합도가 낮은 "JDBC 작업 흐름"을 분리해 냄
Connection c = null;
PreparedStatement ps = null;
try {
c = dataSource.getConnection();
ps = stmt.makeStatement(c); // 이 부분에서 strategy 사용
ps.executeUpdate();
} catch (SQLException e) {
throw e;
} finally {
if (ps != null)
try {
ps.close();
} catch (SQLException e) {
}
if (c != null) try {
c.close();
} catch (SQLException e) {
}
}
}이제 구조로 볼 때 완벽한 전략 패턴의 모습을 갖추게 됨. 클라이언트와 컨텍스트는 클래스를 분리하지 않았지만 의존관계와 책임으로 볼 때 이상적인 클라이언트/컨텍스트 관계를 갖게됨. 클라이언트가 컨텍스트가 사용할 전략을 전달한다는 면에서 DI구조로 봐도 됨. JDBC 전략 패턴의 최적화아직 개선할 점이 남아있음.
→ 어차피 각 전략은 각 메소드에서만 쓰이니까 local class를 사용하자 public void add(final User user) throws SQLException {
class AddStatement implements StatementStrategy { // add() 메소드 내부에 선언된 로컬 클래
User user;
public AddStatement(User user) {
this.user = user;
}
public PreparedStatement makePreparedStatement(Connection c) throws SQLException {
PreparedStatement ps = c.prepareStatement("insert into users(id, name, password) values(?,?,?)");
...
}
StatementStrategy st = new AddStatement(user);
jdbcContextWithStatementStrategy(st);
}
}→ 메소드마다 추가해야했던 클래스 파일을 줄일 수 있음 → 로컬 변수를 바로 가져다 사용할 수 있음 익명 클래스를 쓰면? public void add(final User user) throws SQLException {
jdbcContextWithStatementStrategy(
new StatementStrategy() {
public PreparedStatement makePreparedStatement(Connection c) throws SQLException {
PreparedStatement ps = c.prepareStatement("insert into users(id, name, password) values(?,?,?)");
ps.setString(1, user.getId());
ps.setString(2, user.getName();
...
return ps;
}
}
);
}훨씬 간결해짐 jdbcContextWithStatementStrategy()는 UserDao외에도 적용할 수 있으므로 별도 클래스로 독립시켜 모든 DAO가 사용할 수 있도록 해보자 JdbcContext라는 컨텍스트를 만들었늗네 이러면 DataSource가 필요한 것은 JdbcContext가 되어버림. 그러므로 JdbcContext가 DataSource를 DI받을 수 있도록 해야함 public class JdbcContext {
private DataSource dataSource;
public void setDataSource(DataSource dataSource) { // DataSource 타입 빈을 DI 받을 수 있게 준비
this.dataSource = dataSource;
}
public void workWithStatementStrategy(StatementStrategy stmt) throws SQLException {
Connection c = null;
PreparedStatement ps = null;
try {...}
catch (SQLException e) {...}
finally {...}
}
}public class UserDao {
...
private JdbcContext jdbcContext;
public void setJdbcContext(JdbcContext jdbcContext) {
this.jdbcContext = jdbcContext; // jdbcContext를 Di받도록 만든다.
}
public void add(final User user) throws SQLException {
this.jdbcContext.workWithStatementStrategy( // DI 받은 JdbcContext의 컨텍스트 메소드를 사용하도록 변경한다.
new StatementStrategy() {...}
);그런데 UserDao는 구체 클래스에 의존하고 있음. 하지만 이 경우 JdbcContext는 그 자체로 독립적인 JDBC 컨텍스트를 제공해주는 '서비스 오브젝트'로서 의미가 있을 뿐이고 구현 방법이 바뀔 가능성은 거의 없다"라고 함. → Jdbc가 아닌 JPA나 하이버네이트같이 ORM을 사용해야 하면 아예 싹다 갈아야함. JdbcContext를 UserDao와 DI구조를 만들어야할 이유?
수동 DI? public class UserDao {
JdbcContext jdbcContext;
DataSource dataSource;
public void setDataSource(DataSource dataSource) {
this.dataSource = dataSource;
this.jdbcContext = new JdbcContext();
this.jdbcContext.setDataSource(dataSource);
}
// ...
}→ 긴밀한 관계를 가진 두 객체를 어색하게 빈으로 분리 안해도 됨. → UserDao 내부에서 DI를 적용하는 방식 but 싱글톤X, DI를 위한 추가 코드도 발생함 템플릿/ 콜백 패턴템플릿은 고정된 작업 흐름을 가진 코드를 재사용 한다는 의미에서 붙은 이름 콜백은 템플릿 안에서 호출되는 것을 목적으로 만들어진 오브젝트 전략패턴의 컨텍스트를 템플릿이라고 부르고 익명 내부 클래스로 만들어지는 오브젝트를 콜백이라고 부름(콜백은 보통 단일 메소드 인터페이스) 
DI 방식의 전략 패턴 구조라고 생각하면 됨. 콜백의 분리와 재활용 public void deleteAll() throws SQLException {
executeSql("delete from users");
}
private void executeSql(final String query) throws SQLException {
this.jdbcContext.workWithStatementStrategy(
new StatementStrategy() { // 변하지 않는 콜백 클래스 정의와 오브젝트 생성
public PreparedStatement makePreparedStatement(Connection c) throws SQLException {
return c.preparedStatement(query);
}
}
);
}이렇게 바뀌는 부분과 바뀌지 않는 부분을 분리 가능 콜백과 템플릿의 결합 public class JdbcContext {
...
public void executeSql(final String query) throws SQLException {
workWithStatementStrategy(
new StatementStrategy() {...}
);
}
}이렇게 JdbcContext 클래스로 콜백 생성과 템플릿 호출이 담긴 executeSql을 옮기면 모든 DAO 메소드에서 사용 가능 템플릿/콜백은 스프링이 객체지향 설계와 프로그래밍에 얼마나 가치를 두고 있는지를 잘 보여주는 예시임. 스프링이 제공하는 템플릿/콜백을 잘 사용해아 하는것은 물론이고 직접 템플릿/콜백을 만들어 활용할 수도 있어야함 |
The text was updated successfully, but these errors were encountered: