[Spring] 컨테이너에 등록된 스프링 Bean 조회하기 [getBean() 메서드를 활용한 스프링 빈 조회]
·
▣ Framework/Spring🍃
- 컨테이너에 등록된 스프링 Bean 조회하기 AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); // 스프링 컨테이너에서 스프링 빈을 찾는 가장 기본적인 조회 방법 ac.getBean("memberService", MemberService.class); // 타입만으로도 빈 조회가 가능하다. ac.getBean(MemberService.class); // 스프링에 등록된 모든 빈 이름을 조회한다. ac.getBeanDefinitionNames(); // 해당 타입의 모든 빈을 조회한다. Map 형태로 반환 ac.getBeansOfType(); - ApplicationContextIn..
[Spring] SOLID : 객체지향 설계의 5가지 원칙(5) [DIP(Dependency Inversion Principle) : 의존 역전 원칙]
·
▣ Framework/Spring🍃
- DIP(Dependency Inversion Principle) : 의존 역전 원칙 의존 역전 원칙은 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안 되며, 추상화된 것은 구체적인 것에 의존해서도 안 된다는 원칙이다. 이 원칙을 지키면서 코드를 작성하면, 모듈간의 결합도를 낮출 수 있다. 아래는 의존 역전 원칙이 위배된 코드이다. public class UserService { private Database database = new Database(); public void createUser(String username, String password) { // DB에 사용자 생성 database.insertUser(username, password); } public void deleteUs..
[Spring] SOLID : 객체지향 설계의 5가지 원칙(4) [ISP(Interface Segregation Principle) : 인터페이스 분리 원칙]
·
▣ Framework/Spring🍃
- ISP(Interface Segregation Principle) : 인터페이스 분리 원칙 인터페이스 분리 원칙은 클라이언트가 사용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다. 단일 책임 원칙(SRP)과 밀접한 관련이 있으며, 인터페이스를 작은 단위로 분리함으로써 단일 책임 원칙을 달성할 수 있다. 아래는 인터페이스 분리 원칙에 위배된 코드이다. public interface Machine { void print(); void scan(); void fax(); } public class AllInOneMachine implements Machine { public void print() { System.out.println("Printing..."); } public void scan() {..
[Spring] SOLID : 객체지향 설계의 5가지 원칙(3) [LSP(Liskov Substitution Principle) : 리스코프 치환 원칙]
·
▣ Framework/Spring🍃
- LSP(Liskov Substitution Principle) : 리스코프 치환 원칙 리스코프 치환 원칙은 상속 관계에서 하위 클래스는 상위 클래스를 대체할 수 있어야 한다는 원칙이다. 상위 클래스의 기능을 하위 클래스에서 변경하지 않고 사용할 수 있어야 하며, 상속에서 발생할 수 있는 문제점을 방지한다. 아래는 리스코프 치환 원칙이 위배된 코드이다. class Rectangle { int width; int height; public int getArea() { return width * height; } /* Constructor, getters, and setters */ } class Square extends Rectangle { @Override public void setWidth(int..
[Spring] SOLID : 객체지향 설계의 5가지 원칙(2) [OCP(Open-Closed Principle) : 개방-폐쇄 원칙]
·
▣ Framework/Spring🍃
- OCP(Open-Closed Principle) : 개방-폐쇄 원칙 개방-폐쇄 원칙은 확장에는 열려 있고 변경에는 닫혀 있어야 한다는 원칙이다. 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계해야 하며, 변경에 유연하면서도 안정적인 시스템을 만드는 데 도움을 준다. 아래는 개방-폐쇄 원칙이 위배된 코드이다. public class Product { private String name; private double price; private String type; /* Constructor, getters, and setters */ public double calculateDiscount() { if (this.type.equals("book")) { return this.price * ..