JavaBean 스펙의 액세서 메소드가 Java 개발의 표준이 된 이유는 무엇입니까?

자바 빈즈 사양은 자바 빈즈로 설명

Java Bean은 빌더 도구에서 시각적으로 조작 할 수있는 재사용 가능한 소프트웨어 구성 요소입니다.

작성된 코드 라인의 대부분은 빌더 도구에서 시각적으로 조작하는 것과 아무 관련이없는 것 같습니다. 왜 JavaBean 사양이 객체 지향 코드를 작성하는 "길"이 되었습니까?

전통적 으로 객체 지향 코드가 Java로 작성되는 방식이 아니기 때문에 빌더뿐만 아니라 코드 전체에서 Fluent Interfaces 를 선호하는 전통적인 getter / setter를 포기하고 싶습니다 .

JavaBean 스타일 접근자는 하나의 핵심 포인트에서 원래 "빌더 도구"시나리오와 유사한 모든 종류의 시나리오에 적합한 것으로 입증되었습니다. 구성 요소는 응용 프로그램 코드뿐만 아니라 일반 컨테이너 및 도구에 의해 전달되고 조작됩니다. 응용 프로그램 서버에는 EJB 또는 Spring 컨테이너가 트랜잭션 및 종속성 주입을 추가하는 서비스 구성 요소, ORM이 지연로드 및 변경 감지를 추가하는 영구 도메인 모델 및 특정 코드없이 라이브러리에서 XML로 직렬화 할 수있는 서비스 구성 요소가 있습니다.

접근자는 구성 요소를 사용하는 방법에있어 매우 유연한 공통 API를 제공하지만 작업 순서를 제공하지는 않습니다. 각 접근 자 호출은 다른 호출자와 독립적이며 모두 동일한 패턴을 따르므로 원하는 사용 패턴을 방해하지 않으면 서 기능을 추가하는 일반 레이어를 쉽게 추가 할 수 있습니다.

반면에 유창한 인터페이스는 종종 원샷 사용을 위해 설계됩니다. 객체가 생성되고 최종 결과를 생성하는 메소드로 끝나는 메소드 체인이 호출 된 다음 오브젝트가 폐기됩니다. 유연성 (대부분의 방법은 선택 사항 임)과 일반성이 훨씬 적지 만 이것이 바로 장점입니다. 인터페이스는 사용자를 의도 된 사용 패턴으로 만들어 사용하기 매우 쉽습니다.

따라서 JavaBeans 및 유창한 인터페이스는 서로 다른 시나리오에서 이점이 있으며 사용해야하는 인터페이스가 다릅니다. 그리고 둘 다 결합 할 수도 있습니다.

글쎄, 당신이 링크하는 JavaBeans Specification이 속성에 액세스하기위한 규칙을 정의하기 때문에 사람들은 규칙을 활용하기로 결정하고 그 주위에 프레임 워크를 구축하기로 결정했습니다. 최대 절전 모드와 같은 이러한 프레임 워크 중 일부는 매우 유용하여 널리 사용되었습니다. 따라서 사람들이 JavaBeans 사양을 기반으로하는 프레임 워크를 사용했기 때문에 javaBeans가 점점 더 보편적으로 사용되었으며 점점 더 많은 프레임 워크가 구축되었습니다.

Fluent Interface는 좋은 아이디어이지만 Spring 또는 Struts 2와 잘 어울 립니까? 나를 때린다.