첫째, 클래스의 관련 객체 생성은 실제로 새로운 방식으로 할 수 있습니다. 하지만 프로젝트가 너무 크고 객체에 의존성이 너무 많으면, 객체를 만들 때 많은 새 코드를 작성해야 하고, 일부 의존 객체를 인스턴스화하는 것을 잊은 후 직접 객체를 호출하는 메서드가 있을 수 있습니다. 그러면 null 포인터 예외가 발생할 수 있습니다. 이 과정을 컨테이너 관리에 맡기면 객체 인스턴스화에 대해 걱정할 필요가 없고, 의존 객체를 사용할 때 null 포인터 예외가 없으며, 코드도 단순화할 수 있습니다.
둘째, 메서드 호출 과정에서 사용되는 속성이 인스턴스 속성일 수 있습니다. 모두 정적으로 정의되어 있다면, 메서드에서 사용되는 데이터는 어떻게 되나요? 모든 메서드를 정적으로 정의하면, 메서드에서 참조된 클래스의 속성도 정적으로 정의되어야 하며, 이는 전역 속성과 동등하므로 데이터 동기화 문제가 분명히 발생할 것입니다.
사실, 설계 패턴에 제시된 프로그래밍 원칙들을 생각하는 것이 타당하며, 모두 매우 가독성 있고 유지보수가 쉬우며 확장 가능한 코드를 만드는 데 목적이 있습니다. 행운을 빌며!
소프트웨어는 구성 요소 형태로 조립하는 것이 편리하며, 높은 응집력과 낮은 결합성을 가진 소프트웨어를 만드는 것도 편리합니다(코드에서 의존성을 추출하는 방식)
협업 개발, 코드 디버깅(구성 요소를 통합할 필요 없고 별도로 테스트할 수 있음), 그리고 생성된 코드가 더 견고합니다.
프로젝트 개발은 높은 응집력과 낮은 결합에 중점을 두며, 의존성 주입을 사용하면 새로운 키워드 영역을 이용해 객체를 생성하는 것을 피할 수 있어 클래스 간 결합을 줄일 수 있습니다
|
게시됨 2019. 2. 10. 오후 6:14:29
|
|
|
