이전 Java 객체

Plain old Java object

소프트웨어 엔지니어링에서, 평범한 오래된 자바 객체(POJO)는 어떤 특별한 제한에 구속되지 않는 평범한 자바 객체다.이 용어는 2000년 9월 마틴 파울러, 레베카 파슨스, 조쉬 맥켄지에 의해 만들어졌다.[1]

그는 "우리는 왜 사람들이 일반 물체를 사용하는 것을 반대하는지 궁금했고 단순한 물체에는 화려한 이름이 없기 때문이라고 결론 내렸다"고 말했다.그래서 우리가 하나 줬는데 아주 잘 걸려들었어."[1]

"POJO"라는 용어는 처음에 주요 자바 객체 모델, 규약 또는 프레임워크를 따르지 않는 자바 객체를 가리켰다. 오늘날 "POJO"는 평범한 오래된 자바스크립트 객체의 약어로도 사용될 수 있다. 이 용어는 유사한 혈통의 자바스크립트 객체를 가리킨다.[2]

이 용어는 루비의 일반 구형 전화 서비스(POTO), 전화의 일반 구형 전화 서비스(POTS), Perl의 일반 구형 문서(POD) 등 화려한 새로운 기능을 사용하지 않는 기술에 대해 코인 레트로닉을 위한 약어 패턴을 계속한다.의 POJO와 동일함.NET Framework는 POCO(보통 Old CLR 객체)이다.[3]PHP의 경우 PHP 객체(POPO)이다.[4][5]

POJO 현상은 복잡한 객체 프레임워크와 대조되는 공통적이고 쉽게 이해되는 용어의 필요성 때문에 널리 받아들여졌을 가능성이 높다.[citation needed]

정의

이상적으로 말하면, POJO는 Java 언어 규격에 의해 강요된 것 이외의 제약에 의해 구속되지 않는 Java 객체다. 즉, POJO는 그럴 필요가 없어야 한다.

  1. 다음과 같이 미리 지정된 클래스 확장
    공중의 계급 푸 연장하다 자바스.서빙을 하다.http.httpServlet { ...
  2. 에서와 같이 미리 지정된 인터페이스 구현
    공중의 계급 바 기구들 자바스.ejb.엔티티빈 { ...
  3. 다음과 같이 미리 지정된 주석 포함
    @javax.persistence.persistence.persistence.persistence.독립체 공중의 계급 바즈 { ...

그러나 기술적 어려움과 다른 이유로 인해, POJO 호환으로 기술된 많은 소프트웨어 제품이나 프레임워크는 실제로 지속성과 같은 기능이 제대로 작동하기 위해 사전 지정된 주석을 사용해야 한다.주석을 추가하기 전에 개체(실제 클래스)가 POJO였고 주석을 제거하면 POJO 상태로 되돌아간다면 여전히 POJO로 간주할 수 있다는 생각이다.그러면 기본 객체는 그것을 "특수 자바 객체"(SJO 또는 (sic) SoJO)로 만드는 특별한 특성(실행된 인터페이스 등)이 없다는 점에서 POJO로 남는다.

문맥적 변화

자바 빈즈

자바빈(JavaBean)은 직렬화할 수 있고 무인수 생성자가 있으며 간단한 명명 규칙을 따르는 게터 및 세터 방법을 사용하여 속성에 액세스할 수 있는 POJO이다.이 관습 때문에, 임의의 자바 빈즈의 속성에 대해 간단한 선언적 언급이 이루어질 수 있다.그러한 선언적 참조를 사용하는 코드는 콩의 종류에 대해 아무것도 알 필요가 없으며, 콩은 이러한 틀에서 콩의 정확한 종류를 알 필요가 없이 많은 틀에서 사용될 수 있다.JavaBeans 사양은 클래스가 진정한 JavaBean이 되려면 Serialable 인터페이스를 구현해야 하므로 POJO 모델을 약간 깨트린다.자바빈즈라 불리는 많은 POJO 클래스는 이 요건을 충족하지 못한다.Serialable은 마커(메소드리스) 인터페이스여서 부담이 크지 않다.

다음은 POJO 속성에 양방향 바인딩을 갖는 JavaServer Faces(JSF) 구성 요소의 예를 보여준다.

<h:inputText> 값어치="#{마이빈.someProperty}"/>

POJO의 정의는 다음과 같을 수 있다.

공중의 계급 마이빈 {      사유의 끈 썸프로퍼티;      공중의 끈 getSomeProperty() {          돌아오다 썸프로퍼티;     }      공중의 공허하게 하다 setSomeProperty(끈 썸프로퍼티) {         이.썸프로퍼티 = 썸프로퍼티;     } }

JavaBean 명명 규칙 때문에 단일 "someProperty" 참조는 값을 얻기 위한 "getSomeProperty"("또는 "isSomeProperty"(") 방법 및 값을 설정하기 위한 "setSomeProperty(string) 방법"으로 자동 변환될 수 있다.

투명하게 서비스 추가

POJO를 사용하는 설계가 더 보편적으로 사용됨에 따라, 프레임워크에 사용되는 전체 기능성과 실제로 필요한 기능 영역에 대한 더 많은 선택권을 POJO에게 부여하는 시스템이 생겨났다.이 모델에서 프로그래머는 단지 POJO에 지나지 않는다.이 POJO는 순전히 비즈니스 논리에 초점을 맞추고 있으며 (기업) 프레임워크에 의존하지 않는다.그러면 AOP(양면 지향 프로그래밍) 프레임워크는 지속성, 트랜잭션, 보안 등과 같은 교차 커팅 우려를 투명하게 추가한다.[6]

봄은 이 아이디어를 조기에 구현한 것이며 이 모델을 대중화시킨 원동력 중 하나이다.

EJB 콩이 POJO인 예:

다음은 EJB3가 POJO 모델을 활용하는 방법을 보여주는 완벽한 기능 EJB 빈입니다.

공중의 계급 헬로월드서비스 {      공중의 끈 안부 전해주세요.() {         돌아오다 "안녕, 세상!";     } }

주어진 대로 콩은 EJB 클래스를 확장하거나 EJB 인터페이스를 구현할 필요가 없으며 EJB 주석을 포함할 필요도 없다.대신 프로그래머는 외부 XML 파일에서 EJB 서비스를 콩에 추가해야 한다고 선언한다.

<기업 콩><ejb-name> helloWorld</ejb-name> <ejb-class>com. 예.HelloWorldService</ejb-class> <세션형> </세션형> </엔터프라이즈-beans>

실제로, 어떤 사람들은 주석을 우아하게 보는 반면, 그들은 XML을 장황하고 추하며 유지하기 어렵다고 보는 반면, 다른 사람들은 주석을 통해 POJO 모델을 오염시킨다는 것을 발견한다.[7]

따라서 XML의 대안으로 많은 프레임워크(예: 스프링, EJB 및 JPA)는 XML 대신 또는 XML에 주석을 사용할 수 있도록 허용한다. 다음은 위에 표시된 것과 동일하지만 주석이 추가된 EJB 빈을 보여준다.이 경우 XML 파일이 더 이상 필요하지 않다.

@스테이트리스 공중의 계급 헬로월드서비스 {      공중의 끈 안부 전해주세요.() {         돌아오다 "안녕, 세상!";     } }

위에 제시된 주석과 함께 콩은 더 이상 진정한 순수 POJO가 아니지만, 주석은 수동적 메타데이터에 불과하기 때문에, 이것은 클래스를 확장하거나 인터페이스를 구현해야 하는 불활성화에 비해 해로운 단점이 훨씬 적다.[6]따라서, 프로그래밍 모델은 여전히 순수 POJO 모델과 매우 흡사하다.

관련 약어

일반 이전 Java 인터페이스

플레인 구 자바 인터페이스(POJI)는 자바 인터페이스의 기본 형태로서 보다 복잡한 자바 인터페이스가 허용되지 않는 지점에서 허용된다.[8]: 57, 572, 576, 579, 1340

참고 항목

참조

  1. ^ a b "MF Bliki: POJO". MartinFowler.com.
  2. ^ Almaer, Dion (2006-07-17). "Return of the POJO: Plain 'Ole JavaScript". Ajaxian. Archived from the original on 2014-09-13. Retrieved 2014-08-19.
  3. ^ "POCO Support". microsoft.com. Retrieved 2012-05-27.
  4. ^ Kneschke, Jan (2007-02-19). "typesafe objects in PHP". kneschke.de. Archived from the original on 2012-03-26. Retrieved 2012-05-27.
  5. ^ Cheong, Jym (2011-06-26). "Controller with bare-bone Plain Old PHP Object aka POPO". jym.sg. Archived from the original on 2012-03-26. Retrieved 2012-05-27.
  6. ^ a b 마틴, 로버트 C; (2008);Clean Code, 11장, Pure Java AOP 프레임워크
  7. ^ 팬더, 데부, 라만, 레자, 레인, 데릭, (2007)EJB 3 실행 중, 피난처 섬(NY), ISBN 978-1-93-398834-4(www.manning.com/books/ejb-3-in-action)).11장, 배포 설명자 대 주석
  8. ^ Wahli, Ueli; Vieira, Miguel; Gomes, Ferreira Lopes; Hainey, Brian; Moharram, Ahmed; Napoli, JuanPablo; Rohr, Marco; Cui, Henry; Gan, Patrick; Gonzalez, Celso; Ugurlu, Pinar; Ziosi, Lara (29 June 2009). Rational Application Developer V7.5 Programming Guide. IBM Redbooks. ISBN 978-0738432892.