본문 바로가기

STUDY

(107)
[알고리즘] SW Expert Academy 10032. 과자 분배 문제 풀이 (사고의 흐름) 문제를 보고 가장 처음든 생각은 N이 K로 딱 나누어 떨어지면 모두 같은 수의 과자를 먹을 수 있다는 것이다. 그리고 자연스럽에 N이 K로 딱 나누어 떨어지지 않으면 어떤지 생각해 보았다. 다르게 말하면 N이 K로 나누었을 때, 나머지 Z(K보다 작다)가 있다는 말이고 Z개의 과자는 Z명의 사람들에게 1개씩 줄 수 있다. 즉, Z명의 사람들은 과자 1개씩을 더 받게되고, K-Z명의 사람들은 과자를 더 받지 못한다. 이 상황에서 과자 수 차이는 1이다. 결론적으로 다음과 같다고 할 수 있다. N이 K로 나누어 떨어질 때(N%K == 0), 과자수 차이는 0 N이 K로 나누어 떨어지지 않을 때(N%K != 0), 과자수 차이는 1 정답 코드 #include iostream int ..
2-2) 스프링 트랜잭션 관리: ACID, Dirty Read, Repeatable Read, Pantom Read, @EnableTransactionManagement, @Transactional, READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE - 데이터베이스 트랜잭션 데이터베이스 트랙잭션이란, 데이터관리 시스템에서 사용되는 업무처리 단위를 말한다. 은행에는 송금이라는 기본적인 기능이 있다. 송금은 내부적으로 출금 계좌에서 돈을 꺼내는 과정과, 입금 계좌에 돈을 넣는 과정으로 나누어 볼 수 있다. 여기서 두개의 과정중 일부만 실패하거나 성공하는 경우는 일어나서는 안된다. 이처럼 트랜잭션은 지켜져야하는 조건이 있는데 이를 ACID라고 부른다. - RDB의 특징: ACID 최근 NoSQL과 같은 새로운 형태의 DB가 인기를 끌고 있긴 하지만, 여전히 대다수의 서비스에서는 관계형 데이터베이스(Relational Database), RDB를 사용한다. RDB는 키와 값들의 간단한 관계를 테이블화 시킨 데이터베이스이다. 그리고 RDB에서 지켜져야하는 다..
2-1) 스프링 JDBC: DataSource, H2, SimpleJdbcInsert, NamedParameterJdbcTemplate, BeanPropertyRowMapper, BeanPropertySqlParameterSource - JAVA에서의 DB 접근: JDBC 거의 모든 서비스는 데이터를 기반으로 이루어진다. 따라서 DB에 접근하는 동작이 자주 수행되는데, JAVA에서는 이를 위해 JDBC가 존재한다. JDBC는 JAVA에서 각 데이터베이스에 접근하기위한 인터페이스이다. 실제 코드를 보면 다음과 같이 DB에 접근하여 데이터를 가져올 수 있다. Connection conn = null; PreparedStatement stmt = null; ResultSet rs = null; try { // 1. Connection을 가져오고 conn = dataSource.getConnection(); // 2. 쿼리를 실행할 준비를하고 stmt = conn.prepareStatement("SELECT * FROM Noun001"); ..
1-8) 스프링 리소스(Resource): Resource, ResourceLoader - 스프링 리소스: Resource 추상 클래스 서비스를 개발하다 보면 리소스 파일에 접근할 일이 종종 있다. 설정 정보를 불러오기위해 resources 폴더의 .properties 파일에 접근하기도 하고, 외부 사이트의 이미지 파일을 불러오기도 한다. 스프링에는 리소스에 접근하기 위한 추상클래스 Resource가 존재하고, 각 상황별로 쓸 수 있는 구현 클래스가 존재한다. - 스프링 리소스 편하게 가져오기: ResourceLoader 개발자 입장에서는 상황에 맞는 Resource 구현 클래스를 사용해야 한다는 것 자체가 부담으로 다가올 수 도 있다. 그래서 스프링에서는 ResourceLoader가 존재한다. ResourceLoader는 리소스의 경로를 보고 적절한 Resource 구현 클래스를 사용하고..
1-7) 스프링 프로파일(Profile): @Profile - 스프링 프로파일(Profile) 상용 서비스를 출시하면, 서비스가 운영되고있는 운영 서버와 추가 개발을 위한 개발 서버를 분리하는 것이 보통이다. 개발을 하다보면 새로운 버그가 생길 수 있고, 자주 소스를 새로 배포해야하는 상황이 생기기 때문이다. 따라서 코드 또한 개발서버에서 동작해야하는 코드와, 운영서버에서 동작해야하는 코드가 분기될 수 있다. @Configuration public class DBConfig { ... // 개발 서버용 dataSource // @Bean // public DataSource dataSourceForDev() { // return new EmbeddedDatabaseBuilder() // .setType(EmbeddedDatabaseType.H2) // .setS..
1-6) 스프링 프로퍼티(Property): @PropertySource, @Value, Environment - 스프링 프로퍼티(Property) 소스 코드를 작성하다 보면, 정적으로 하드코딩된 내용을 쓸때가 있다. 대표적으로 DB의 설정정보가 그렇다. 그래서 DB 설정 정보 클래스를 보면 다음과 같이 코딩되어있다. @Configuration @Import(value = {DBConfig.class}) public class AppConfig { ... } @Configuration public class DBConfig { private String driver = "DB 접속 드라이버"; private String url = "DB 접속 URL"; private String username = "DB 접속 유저명"; private String password = "DB 접속 패스워드"; ... @Overri..
1-5) 스프링 AOP(Aspect Oriented Programming) : @Aspect, @Pointcut, @Before, @After, @AfterReturning, @AfterThrowing, @Around - AOP(Aspect Oriented Programming)란? 과거 프로그램의 규모가 커지면서 중복된 코드를 줄이고 유지보수성을 높이기 위해 OOP, 객체지향 프로그래밍이 등장하였다. 객체지향 프로그래밍은 각각의 역할을 분리하고 서로 필요할 기능을 호출하도록 하여 그 목표를 달성하였다. 웹서비스의 구조를 보면, 사용자 입장에서는 서로 다른 기능으로 보일지라도 여러 서비스와 레포지토리 객체를 공통으로 사용한다. 이렇게 공통 기능을 객체로 분리하여 코드의 재사용성을 높혔지만, 여전히 객체마다 중복해서 들어가야하는 요소들이 존재했다. 예를들어 로그의 경우, 각 객체마다 로그를 남기기 위한 별도의 코드가 삽입되어야 했다. 이렇게 각 객체를 관통하여 존재하는 중복을 제거할 필요성이 생겼다. 그리고 이를 위해 ..
1-4) 스프링 빈 생애주기(Life Cycle) 관련 기능 : BeanPostProcessor, @PostConstruct, @PreDestroy - 스프링의 빈 생애주기 관리 스프링은 DI 컨테이너로서 기능하면서, 빈의 생명주기를 관리한다. 빈의 스코프에 따라서 객체를 생성하고, 의존성의 주입하여 사용할 수 있게 해준다. 또 때가 되면, 해당 객체를 제거한다. 이렇게 객체의 생성과 초기화, 제거를 아우르는 흐름을 생명 주기라고 하고, 스프링에서는 개발자가 특정 시점에 동작하는 코드를 작성할 수 있도록 한다. 이 글에서는 BeanPostProcessor, @PostConstruct, @PreDestroy를 다루겠다. - 빈의 초기화 시점 : BeanPostProcessor BeanPostProcessor를 상속받아서 메소드를 구현하면 초기화 전후에 실행되는 코드를 작성할 수 있다. 여기서 말하는 초기화는 스프링에 의해 의존성 주입이 완료된 이후에 ..