작성
·
902
1
안녕하세요 !
좋은 강의 만들어 주셔서 너무 재밌게 공부하고 있습니다 !
상태 (State) 패턴 은 순환구조 (Circular Reference) 로 구성된 것으로 이해 하였습니다.
순환구조를 Code smell 로 표현하는 글들을 몇번 본적이 있습니다.
제가 기억하는 이유는 다음과 같습니다.
* 메모리 누수 요인 (순환을 끊지 않는한)
* 컴파일(빌드) 시, 순환구조 import 에러 (Java 에서는 정상 동작되는 것이 이상하게 생각 되었습니다)
개인적으로 Parent-Child 를 순환구조로 사용하면, 사용성이 너무 좋게 느껴졌습니다. (특히 탐색을 적게 하니까 더 좋았습니다.)
선생님께서는 순환구조를 어떻게 생각하시는지, 사용해도 되는지 궁금합니다 🙇♂️
(혹은 제가 상태 패턴을 순환구조로 잘 못 이해하고 있는걸까요? 🤔)
감사합니다.
답변 2
2
시원한 답변 감사합니다 !!
말씀해 주신것 처럼 interface State 의 각 메서드에 Context 를 인자로 넘기니, 순환구조가 해소되었습니다 👍
public interface State {
public void addStudent(Student student, OnlineCourse onlineCourse);
public void addReview(Student student, String review, OnlineCourse onlineCourse);
}
그리고 Parent-Child 처럼 긴밀한 관계에서, 이제는 순환구조를 좀 더 당당하게 쓸 수 있을 것 같습니다.
순환구조 import 에러는 Javascript 의 모듈 번틀러 빌드시 발생했던 상황이었습니다. (빌드결과가 undefined 인 상황)
(저의 주 개발언어가 Javascript 거든요 ㅎㅎ;)
FE 주니어도 이해할 수 있는 좋은 강의 만들어주셔서 감사합니다 !!
1
안녕하세요. 좋은 질문이네요.
말씀하신대로 순환 참조는 가급적이면 피하는게 좋은데요. 이 패턴의 경우에는 제가 만든 예제 코드처럼 State쪽에서 Context를 필드로 가져도 되지만 State에 있는 메소드를 호출할 때 Context를 매개변수로 넘겨줄 수도 있습니다. 매개변수로 넘기더라도 State와 Context는 상호간에 참조를 하긴하지만 필드로 가지고 생성자로 넘겨줘야 할 때 보다는 객체 생성이나 순환 참조로 인한 이슈가 줄어들긴 할 겁니다.
순환 참조는 저도 가급적이면 피하려고 하지만, 그 둘이 긴밀하게 관련이 있는 상황이라면 굳이 피할 필요도 없다고 생각해요. 그리고 말씀하신 순환 참조 문제 중에 "컴파일(빌드) 시, 순환구조 import 에러가 발생한다" 이 부분은 사실인지 조금 더 확인해 보시는게 좋을 것 같습니다.
감사합니다.