목차
알고리즘
Stack
isEmpty 구현
💡isEmpty는 스택이 비었는지 확인하는 함수이다.
Java
복사
isEmpty 테스트 코드
isEmpty 코드
peek 구현
💡peek은 스택의 맨 위 원소가 무엇인지 반환하는 함수이다.
- 주의할 점 : 스택이 비었을 때 peek을 호출하게 되는 경우를 예외처리해야 한다.
Plain Text
복사
peek 테스트 코드
peek 코드
push와 pop의 예외처리
💡 push는 스택이 다 차있을 때 push를 경우
pop은 스택이 비었을 때 pop을 할 경우 이 두가지 경우를 에러 처리 해야 한다.
Plain Text
복사
push 에러처리
pop 에러처리
Stack 전체 코드
Stack 코드
Stack Test 코드
토비의 스프링
0. Spring 복습
복습
복습 목록
코드
이전 코드
Factory
•
@Configuration
◦
UserDaoFactory클래스를 객체를 생성하고 생성된 객체의 관계를 결정해주는 클래스로 명시
•
@Bean
◦
UserDaoFactory라는 설정 클래스는 ApplicationContext에 awsUserDao, localUserDao라는 이름의 빈을 등록한다.
UserDaoFactory 코드
1. Test_토비의 스프링2장
Test를 만들 때 중요한 점
언제 실행해도 동일한 결과가 나오게끔 테스트를 구성해야 한다.
deleteAll()
•
DELETE FROM users를 실행하는 메소드
•
users 테이블에 존재하는 모든 레코드 수 삭제
deleteAll 코드
getCount()
•
SELECT COUNT(users) FROM users 를 실행하는 메소드
•
users 테이블에 존재하는 모든 레코드의 수를 반환
getCount 코드
UserDaoTest 리팩토링
UserDaoTest 클래스 코드
•
@BeforEach의 적용
◦
각 @Test 메소드가 실행 될때마다 실행되는 코드가 있다. 그 부분을 Junit에서 공통화 시킬 수 있게 제공하는 기능이 BeforeEach이다.
@BeforEach 적용 코드
데이터가 없을 때 ResultSet이 빈 경우
•
findById메소드에서 users에 없는 레코드를 반환받는 시도를 할 때 위와 같은 exception이 생긴다.
•
EmptyResultDataAccessException(1) 위 경우 에러처리를 한다.
findById 리팩토링 코드
findById 리팩토링 테스트 코드
JUnit의 작동 방식
1.
테스트 클래스에서 @Test가 붙은 public이고 void형이며 파라미터가 없는 테스트 메소드를 모두 찾는다.
•
public은 생략해도 된다.(Junit 5)
2.
테스트 클래스의 오브젝트를 하나 만든다,
3.
@BeforeEach가 붙은 메소드 실행
4.
@Test가 붙은 메소드를 하나 호출하고 테스트 결과를 저장한다.
5.
@AfterEach가 붙은 메소드 실행
6.
나머지 남은 테스트에 대해 2~5번을 반복
7.
모든 테스트 결과를 종합해서 돌려준다.
Junit5에서 테스트 실행할 때 마다 오브젝트를 생성하는 이유
•
각 테스트가 서로 영향을 주지 않고 독립적으로 실행됨을 확실히 보장해주기 위해 매번 새로운 오브젝트를 만든다.
•
테스트 클래스는 인스턴스 변수를 매번 새로 생성해주기 때문에, 독립적인 실행을 확실하게 보장한다.
•
따라서, 각 테스트 메소드끼리는 의존이 전혀 없으므로, 테스트 메소드 실행에 대한 순서가 보장되지 않는다.
•
Test Method순서 정하기 : https://psawesome.tistory.com/32
ApplicationContext Singleton
•
@Autowired를 이용해 Container에서 가져오게 하여 new를 한번만 하도록 한다.
•
@Autowired
◦
필요한 의존 객체의 “타입"에 해당하는 빈을 ApplicationContext 에서 찾아 주입한다.
◦
필드 주입, 생성자 주입, 설정자 주입의 3가지로 DI가 가능하다.
◦
우리가 작성한 방식은 필드 주입 방식이다.
◦
즉, 이 어노테이션을 통해 AppplicationContext라는 빈 객체를 스프링 컨테이너가 알아서 자동으로 주입해주는 것이다.
ApplicationContext에서 Bean을 가지고 올 때 Spring이 검색하는 방법
•
getBean()을 통해 스프링에 등록된 빈을 조회할 수 있다.
•
빈의 이름은 설정 클래스에서 @Bean 어노테이션을 통해 빈을 생성하는 각 메소드의 이름으로 지정된다.
2. 예외처리_토비의 스프링_3장
예외처리가 없을 때 문제점
public void deleteAll() throws SQLException {
Connection c = connectionMaker.connectionMaker();
PreparedStatement p = c.prepareStatement(
"DELETE FROM users;"
);
p.executeUpdate();
p.close();
c.close();
}
Java
복사
•
SQLException 발생시 close()가 실행되지 않는 문제가 발생한다.
•
리소스의 반환이 이루어지지 않아 서버가 다운된다.
리소스 반환을 위한 예외처리 리팩토링
예외처리 리팩토링 코드
•
에러가 발생하든 발생하지 않든, 커넥션과 PreparedStatement, ResultSet과 같은 클래스는 풀에 있는 위에서 언급한 것과 같이 정해진 풀 안에 제한된 리소스를 만들어두고, 필요할 때 할당하고 반환하면 다시 풀에 넣는 방식으로 사용한다.
•
만약 makeConnection()에서 Db 커넥션을 가져오다가 일시적인 db 서버 문제나, 네트워크 문제 때문에 예외가 발생했다면, PreparedStatement와 커넥션 오브젝트는 아직 모두 null 상태이다.
◦
null 상태의 변수에 close() 메소드를 호출하면 NPE가 발생할 테니 이럴 땐 close() 메소드를 호출하면 안된다.
•
또 다른 상황으로, PreparedStatement를 생성하다가 예외가 발생했다면, 그 때는 c 변수가 커넥션 객체를 갖고 있는 상태이므로 c는 close() 호출이 가능한 반면 pstmt는 아니다.
•
이 말의 요지는 어느 시점에서 예외가 발생했는지에 따라서 close()를 사용할 수 있는 변수가 달라질 수 있기 때문에 finally에서는 반드시 c와 pstmt가 null이 아닌지 먼저 확인한 후에 close() 메소드를 호출해야 한다.
