Class class Class class 자바에는 이름이 Class인 클래스가 존재 이 Class 클래스는 어떤 클래스의 구조 자체를 표현하는 일종의 메타 클래스 A 클래스에 대해, A.class는 이 A 클래스의 Class 객체를 나타냄 Class 클래스는 다음과 같이 메타 정보를 얻을 수 있음 getFields() 메소드: 클래스의 필드 리스트 getMethods() 메소드: 클래스의 메소드 리스트 getName() 메소드: 클래스의 이름을 string으로 반환 References https://joont.tistory.com/165

Spring Container Spring Container 스프링 컨테이너는 싱글톤 패턴을 별도로 적용하지 않아도 객체 인스턴스를 자동으로 싱글톤으로 관리 이를 통해 싱글톤 패턴의 문제점을 해결 싱글톤을 위한 별도의 코드를 작성할 필요 없음 OCP, DIP 등을 지키며 유연하게 코드 작성 가능 Spring bean이 싱글톤으로 관리됨 물론 bean을 싱글톤으로 사용하지 않는 경우도 존재 Spring Container 주의점 Spring container를 비롯해 싱글톤 패턴을 사용 시 주의해야 함 여러 클라이언트가 한 개의 객체 인스턴스를 공유하므로, 특정 클라이언트에 의존적이면 안 됨 특정 클라이언트가 값을 변경할 수 있다면, 큰 문제 발생 가능 가급적 읽기만 가능하도록 Spring bean의 필드에 공유 값을 설정하지 말 것 References 스프링 핵심 원리 기본편 - 김영한 (https://www.

Singleton Pattern Singleton Pattern 클래스의 인스턴스가 정확히 한 개만 생성되도록 보장하는 디자인 패턴 많은 요청을 받을 때 마다 매 번 인스턴스를 생성하면 비효율적 미리 생성된 하나의 인스턴스를 공유하는 패턴 인스턴스를 임의로 생성하지 못하도록 생성자를 private으로 설정 만약 인스턴스를 new 키워드를 통해 생성 가능해지면 의미가 없어짐 예제 코드 public class Singleton { // 인스턴스를 static으로 생성 private static final Singleton instance = new Singleton(); // getInstance로만 인스턴스에 접근 가능. 매 번 동일한 한 개의 인스턴스만 반환 public static Singleton getInstance() { return instance; } // 생성자가 private private Singleton() { } } 단점 및 해결 방안 싱글톤 패턴에 필요한 코드 자체가 많음 구체적인 클래스에 의존해야 하기 때문에 OCP, DIP를 위반 생성자가 private이라 자식을 만들기 힘듦 테스트가 어렵고, 유연성이 떨어짐 이런 단점들을 해결하기 위해 spring에서는 싱글톤 컨테이너라는 것을 사용 References 스프링 핵심 원리 기본편 - 김영한 (https://www.

ApplicationContext BeanFactory 스프링 컨테이너 최상위 인터페이스 스프링 빈을 조회 및 관리 ApplicationContext BeanFactory를 상속받아서 제공하는 인터페이스 BeanFactory에 다음과 같은 기능을 추가 지역에 맞는 언어 제공(국제화) 기능 로컬 / 개발 / 운영 단계를 구분해서 처리하는 기능 환경 변수 관련 처리 애플리케이션에서 발생하는 이벤트 담당 리소스 조회 이러한 기능들때문에 사실상 BeanFactory만 사용하는 경우는 잘 없음 References 스프링 핵심 원리 기본편 - 김영한 (https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard) https://velog.io/@max9106/Spring-ApplicationContext

Junit Assertj Junit 자바에서 단위 테스트를 수행해 주는 라이브러리 다음과 같이 assert[SOMETHING] 함수들을 통해 테스트를 수행하고 결과를 알려줌 assertEquals(a, b): a, b가 동일한지 assertTrue(a): a가 참인지 assertNotNull(a): a가 null이 아닌지 조건의 참 / 거짓 정도만 판단할 수 있게 설계되어 검증이 많은 테스트를 표현하기 힘듦 Junit 5 부터는 org.junit.jupiter.api.Assertions에서 import해 옴 Assertj Junit의 테스트 코드에 사용하는, 테스트 코드의 가독성을 높이는 라이브러리 모든 테스트 코드가 assertThat 함수를 사용 assertThat(x).method1().method2()... 와 같이 체이닝 방식을 사용 x는 테스트를 수행할 타겟을 의미 assertThat 뒤에 메소드를 연쇄적으로 호출해서 x에 대한 테스트를 수행 Junit만 사용하는 것 보다 편하며, 사용이 권장됨 다음과 같이 여러 메소드 존재 isEqualTo(o): x가 o랑 같은지 확인 isInstanceOf(t): x가 t 타입인지 확인 asString(): x를 문자열로 변환 contains(a): x가 a를 포함하는지 확인 org.

NumberFormatException NumberFormatException 자바에서 문자를 숫자로 변경할 때 형식이 잘못되어 생기는 오류 Integer.parseInt(someString)을 실행할 때 주로 발생 다음과 같은 경우가 해당 숫자로 변경할 문자열이 "123B"와 같이 숫자 형태가 아님 자료형이 변경 가능한 범위보다 숫자가 큰 경우. int의 경우 2^31 이상 null 입력시 변경할 문자열에 공백이 있는 경우 특히 2번 경우는 코딩 테스트 문제를 풀 때 자주 나오기 때문에, long 혹은 BigInteger를 사용해야 함 References https://lnsideout.tistory.com/entry/JAVA-%EC%9E%90%EB%B0%94-NumberFormatException-%EC%9B%90%EC%9D%B8%EC%98%88%EC%99%B8%EC%B2%98%EB%A6%AC%ED%95%B4%EA%B2%B0

SOLID SOLID 좋은 객체 지향 프로그래밍을 설계하기 위한 다섯가지 원칙 로버트 마틴이 2000년대 초에 정리했으며, 다음과 같음 Single responsibility principle Open closed priciple Liskov substitution principle Interface segregation principle Dependency inversion principle Single responsibility principle (단일 책임 원칙) 한 클래스는 하나의 책임을 가져야 함 한 클래스를 변경했을 때 다른 클래스에 영향을 최소한으로 줘야 함 Ex) UI를 변경한 것이 기능에 영향을 줘서는 안 됨 Open closed priciple (개방 폐쇄 원칙) 소프트웨어는 확장에는 열려 있으나 변경에는 닫혀 있어야 함 기존 코드의 변경 없이 확장 가능해야 한다는 뜻 이를 위해서는 객체간의 연관관계를 맺어주는 별도의 설정이 필요 다형성 만으로는 OCP를 만족하지 않음 Liskov substitution principle (리스코프 치환 원칙) 프로그램의 객체는 정확성을 깨뜨리지 않으며 하위 타입의 인스턴스로 바꿀 수 있어야 함 하위 클래스는 인터페이스의 규약을 지켜야 한다는 뜻 인터페이스를 구현한 구현체를 믿고 사용하기 위해 필요한 원칙 Interface segregation principle (인터페이스 분리 원칙) 특정 클라이언트를 위한 여러 인터페이스를 사용하는 것이 한 개의 공용 인터페이스보다 나음 인터페이스들을 분리하면 서로 독립적이게 되고, 명확해짐 Dependency inversion principle (의존관계 역전 원칙) 프로그래머는 추상화가 아닌 구체화에 의존하면 안됨 클래스가 아니라 인터페이스에 의존하라는 뜻 구현 클래스를 유연하게 변경할 수 있게 됨 References 스프링 핵심 원리 기본편 - 김영한 (https://www.

OOP Object Oriented Programming 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 객체라는 독립된 단위로 파악하는 프로그래밍 방식 각 객체는 메시지를 주고 받고, 데이터를 처리 가능 프로그램이 변경이 용이해지고 유연해지기 때문에 대규모 개발에 적합 객체를 설계할 때 역할과 구현을 분리하는 것이 중요 인터페이스를 이용해 역할을 설정하고, 실제 구현체는 유연하게 변경 가능 이렇게 객체가 여러 가지 구현체를 가질 수 있는 것을 다형성이라고 함 References 스프링 핵심 원리 기본편 - 김영한 (https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard)

IoC Inversion of Control 객체지향 프로그래밍에서 제어를 역전시킨다는 원칙 클래스 내부가 아닌 외부에서 객체에 대한 생성 하고 이용하는 등의 제어권을 가지게 함 객체에 대한 변경이 자유로워지고, 의존성이 낮아지는 장점 존재 프레임워크 역시 개발자가 작성한 코드를 이용해 프로그램을 구동하기 때문에, IoC를 따른다고 볼 수 있음 Dependency Injection은 IOC를 구현하는 디자인 패턴 중 하나 References https://velog.io/@ohzzi/Spring-DIIoC-IoC-DI-%EA%B7%B8%EA%B2%8C-%EB%AD%94%EB%8D%B0 https://my-codinglog.tistory.com/entry/Spring-IoC-DI-%EC%99%80-DIP-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

DI Dependency (의존 관계) 클래스 A, B에 대해 A가 B를 의존한다는 뜻은 B를 변경했을 때 A에 영향을 미친다는 뜻 Ex) A 클래스의 필드로 B 클래스의 객체를 사용하는 경우 이런 의존관계를 끊기 위해서는 특정 클래스에 의존하는 대신 인터페이스를 사용하도록 추상화 시키면 됨 Ex) 클래스 대신 인터페이스를 사용하면, 하나의 클래스 외에도 여러 클래스가 올 수 있음 Dependency Injection 의존 관계에서 인터페이스로 추상화 시킨 경우에는 실제 구현체를 넣어줘야 함 인터페이스에 대한 구현을 외부에서 수행하고 주입하는 행위를 dependency injection이라고 함 인터페이스를 사용하기 때문에 클래스간의 의존 관계가 고정되지 않음 생성자 혹은 setter 메소드 등을 이용해 주입 가능 DI 장점 의존성이 줄어듦으로 인해 변경에 대한 부담이 줄어듦 재사용성이 높아짐 테스트를 수행하기 쉬워짐 가독성이 높아짐 References https://mangkyu.