작성
·
144
답변 1
0
안녕하세요, 인프런 AI 인턴입니다.
님의 질문에 대한 답변을 드리겠습니다.
List<Integer> list = new ArrayList<>();
문장에서 List<Integer> list;
로 바꾸는 것은 변수 list
의 선언만 하는 것이므로, 실제로 구현체인 ArrayList
를 생성하고 할당하는 부분이 사라집니다. 따라서 기존 코드가 의도한 바와 다르게 동작할 수 있습니다. 일반적으로 인터페이스 타입으로 선언하고 구현체를 할당하는 것은 좋은 프로그래밍 습관입니다. 이는 특정 구현체에 대한 의존성을 낮추고, 코드를 더 유연하게 만들어 줍니다.
클래스 다이어그램에 인터페이스가 포함되는지에 대한 질문인데요, 인터페이스도 클래스 다이어그램에 포함될 수 있습니다. 클래스 다이어그램은 시스템의 클래스들의 관계를 보여주는 UML 다이어그램으로, 인터페이스와 클래스, 그리고 이들 사이의 관계를 나타낼 수 있습니다.
@Bean
어노테이션은 스프링 컨테이너에게 해당 메서드가 Bean 객체를 생성한다는 것을 알려주는 것인데요, 일반적으로 List
와 같은 컬렉션 타입을 Bean으로 등록하는 경우는 드뭅니다. 대신, List 타입의 Bean을 주입받아 사용하는 경우는 있을 수 있습니다. 예를 들어, 같은 타입의 여러 Bean을 리스트로 받아서 처리해야 할 때 사용할 수 있습니다.
추가적인 궁금증이 있으시면 언제든 질문해주세요.
인터페이스에만 의존하도록 코드를 변경하는 부분에서, 실제로 List와 같은 인터페이스도 AppConfig에 선언해주기도 하는지가 궁금합니다.
예를 들면,
인터페이스인 List도, 상황에 따라 다른 구현체로 변경해야할 상황일 때
2. 구현체인 ArrayList나 LinkedList가 MemoryMemberRepository 처럼 주 객체로 사용될 때
MemoryMemberRepository 클래스 안에 선언된 Map<Long, Member> store = new HashMap<>(); 로 이 클래스가 지금 Map과 HashMap 구현체에 둘 다 의존하는 일반적인 자료형으로 사용될 때(1. 상황과 약간 겹치는 상황)
2. 3.번 상황을 예시로 들었는데, 이런 상황이거나 이외의 상황에서도 List같은 인터페이스도 실제(실무?)로 "인터페이스에만 의존하도록 코드 변경"에 적용하는지 궁금합니다.
안녕하세요. 노동자님
클라이언트 코드는 인터페이스에 의존하도록 설계하는 것이 좋습니다 🙂
그러면 구현체를 ArrayList로 사용하다가 LInkedList로 변경해도 클라이언트 코드를 변경하지 않아도 되니까요.
List나 Map을 사용하는 예는 강의 이후에 나오니 한번 쭉 들어보시면 이해가 되실거에요.
감사합니다.
먼저 답변 감사드립니다.
1.번 답변에 따르면 그럼 AppConfig에도 list의 선언을 해주는게 맞는건가요?