Back-End

데이터베이스 로직 같은 예외 발생 가능성이 높거나 공유 리소스의 반환이 필요한 코드는 예외 처리 블록으로 별도로 관리해줘야 함 일정하게 반복되는 작업 흐름에서 일부만 다른 코드가 존재하는 경우 전략 패턴을 사용하는 것이 좋고, 바뀌지 않는 부분을 컨텍스트, 바뀌는 부분을 전략으로 만들고 이 두 오브젝트를 인터페이스로 유연하게 연결한다. 클라이언트 메서드를 통해 직접 전략을 정의하고 제공하여 사용하게 한다. 클라이언트 메서드 안에 익명 내부 클래스를 사용하여 전략을 구현하면 클라이언트 메서드의 정보를 사용할 수도 있고 코드를 간결하게 작성할 수 있다. 컨텍스트가 여러 클라이언트에서 사용된다면 별도의 클래스로 분리하여 공유되게 만든다. 컨텍스트는 별도의 빈으로 등록하여 의존관계를 주입 받거나 클라이언트에서 ..
스프링이 제공하는 JDBC를 이용하는 DAO에서 사용할 수 있는 템플릿과 콜백 private JdbcTemplate jdbcTemplate; public void setDataSource(DataSource dataSource) { this.jdbcTemplate = new JdbcTemplate(dataSource); this.dataSource = dataSource; } JDBC Template을 사용하기 위해 기존의 JdbcContext를 빼고 바꿔준다. update 기존 전략 인터페이스의 메서드를 통해 전략을 적용했던 것과 똑같이 JDBC Template이 제공하는 콜백 중 PreparedStatementCreator 인터페이스의 createPreparedStatement 메서드를 사용하면 된다..
전략 패턴은 복잡하지만 바뀌지 않는 일정한 패턴을 갖는 작업 흐름이 존재하고 그중 일부분만 자주 바꿔 사용하는 경우 적합한 구조다. 전략 패턴의 기본 구조에 익명 내부 클래스를 활용한 방식을 템플릿/콜백 패턴이라고 한다. 컨텍스트는 템플릿에 해당하고 익명 내부 클래스로 만들어지는 오브젝트를 콜백에 해당한다. 템플릿 어떤 목적을 위해 미리 만들어둔 모양이 있는 틀로 고정된 틀 안에서 특정 부분만 상황에 맞게 바꿔 사용하는 경우를 말한다. JdbcContext처럼 공통적인 기능에서 특정 부분만 전략에 맞게 사용하는 것과 같다. 콜백 특정 로직을 담은 메서드를 실행시키기 위해 다른 오브젝트의 메서드에 전달되는 오브젝트 JdbcContext에 전달되어 실행되는 전략과 같다. 템플릿/콜백의 동작 원리 클라이언트(..
전략 패턴의 구조에서는 클라이언트는 add, delete 같은 메서드에 해당하고 전략은 익명 내부 클래스에 해당하며 jdbcContextWithStatementStrategy 메서드를 컨텍스트라고 볼 수 있다. 여기서 컨텍스트는 User의 DAO에서만 사용하는 것이 아니라 다른 DAO에서도 공통적으로 사용할 수 있는 기능에 해당하기 때문에 해당 컨텍스트를 모든 DAO에서 사용할 수 있게 별도의 클래스로 독립시키는 것이 좋다. 클래스 분리하기 별도의 클래스를 만들어 컨텍스트 메서드를 옮기고 DI를 알맞게 설정해준다. public class JdbcContext { DataSource dataSource; public void setDataSource(DataSource dataSource) { this.d..
전략 패턴을 사용하여 메서드 추출을 했을 때보다 유연하고 확장성 있는 코드를 짜는 것은 성공했지만 여전히 필요할 때마다 전략 패턴을 새로 생성해야 하는 것은 그대로다. 또한, 전략에 부가적인 정보가 필요한 경우 이를 위해 생성자와 인스턴스 변수를 추가적으로 만들어야 하는 것도 번거롭다. 로컬 클래스로 사용하기 전략 클래스를 계속해서 생성해야 하는 문제는 전략 클래스를 컨텍스트 클래스에 내부 클래스로 정의하는 것으로 해결할 수 있다. 이러한 전략 클래스들은 컨텍스트 클래스 이외에는 사용되지 않기 때문에 굳이 외부에 클래스로 따로 만들어둘 필요가 없기 때문이다. public void add(User user) throws SQLException { // 사용할 컨텍스트 메소드 내부에 클래스 선언 class ..
개방 폐쇄 원칙 이전에 알아본 내용이지만 다시 간단하게 알아보자면 변경에 개방적이어야 하는 코드들은 수정과 확장에 열려있어야 하고 변경되지 말아야 하는 코드들은 닫혀있어야 하는 원칙이다. 템플릿 개방 폐쇄 원칙을 적용하여 효과적으로 활용할 수 있도록 하는 방법으로 바뀌는 성질이 다른 코드 중 변경이 거의 없고 일정한 패턴으로 유지되는 부분을 자유롭게 변경되는 부분으로부터 독립시키는 방법이다. 즉, 이전에 학습했던 객체지향적인 리팩토링처럼 변하지 않고 많은 곳에서 중복되는 코드와 자주 변경되는 코드를 분리하는 작업이다. 템플릿 적용하기 1. 변하는 성격이 다른 것 찾기 데이터베이스를 조작하는 코드에서 예시를 든다면 조작을 위한 SQL문과 전체적인 데이터베이스 로직을 처리하는 반복적인 코드가 있다. 여기서 ..
JUnit은 각각의 테스트가 독립적으로 존재할 수 있게 하기 위해 테스트 메서드마다 서로 다른 오브젝트를 만들어서 실행되게 한다. 하지만 이 경우가 스프링에서는 문제가 될 수 있는데 애플리케이션 컨텍스트를 테스트 오브젝트마다 반복적으로 만들기 때문에 빈이 많아지고 설정이 복잡해지는 경우에는 컨텍스트 생성에 시간이 많이 소요된다. 또한 여러 테스트가 함께 참조해야할 애플리케이션 컨텍스트를 오브젝트 레벨에 저장해두면 각각 다른 컨텍스트를 참조하게 되어 곤란하다. 이를 위해서 JUnit은 테스트 클래스 전체에서 딱 한 번만 실행되는 @BeforeClass 스태틱 메서드라는 기능을 제공한다. 물론 이 기능으로도 가능하지만 스프링에서 제공하는 더 좋은 방법이 있다. 스프링 테스트 컨텍스트 프레임워크 적용하기 @R..
JUnit 테스트 실행하기 IDE 자바 IDE에서는 대부분 내장된 JUnit 테스트 지원 도구가 존재한다. JUnit을 메인 메서드를 만들지 않고도 테스트를 진행할 수 있게 해주며, 테스트 정보를 표시해주는 다양한 뷰 기능도 제공한다. 빌드 툴 메이븐, 그래들 같은 빌드 툴에서 제공하는 JUnit 플러그인과 테스트가 존재한다. HTML이나 텍스트 파일 형식으로 보기 좋게 테스트 결과를 만들어주기 때문에 개인별로는 IDE를 통해서 테스트를 실행하지만 통합 빌드 후의 테스트는 빌드 툴을 통한 테스트 결과를 파일로 전달 받는다. 일관된 테스트 결과 테스트는 외부의 상태에 따라 결과가 달라지는 일이 발생하지 않고 코드의 변화가 있지 않는한 항상 같은 결과가 나와야 한다. 이를 위해서는 테스트한 결과는 실제로 반..
da9dac
'Back-End' 카테고리의 글 목록 (6 Page)