최대 절전 모드는 무엇입니까? Hibernate Core 구현의 기초
게시 됨: 2013-04-17
Hibernate는 오픈 소스 Java 퍼시스턴스 프레임워크 프로젝트입니다. HQL 및 SQL을 사용하여 강력한 개체 관계형 매핑 및 쿼리 데이터베이스를 수행합니다.
일반적으로 널리 사용되는 라이브러리는 잘 설계되고 구현되었으며, 이들로부터 몇 가지 코딩 모범 사례를 배우는 것은 매우 흥미로웠습니다.
하이버네이트 코어 라이브러리 내부를 살펴보고 그 디자인 키 중 일부를 발견해보자.
이 포스트에서 Hibernate Core는 JArchitect 에 의해 분석되어 그것의 디자인과 구현에 대해 깊숙이 들어갑니다.
기능별 패키지
Package-by-feature 패키지는 패키지를 사용하여 기능 세트를 반영합니다. 단일 기능(및 해당 기능만)과 관련된 모든 항목을 단일 디렉토리/패키지에 배치합니다. 그 결과 높은 응집력과 높은 모듈성을 가진 패키지와 패키지 간의 결합이 최소화됩니다. 밀접하게 작동하는 항목은 서로 옆에 배치됩니다.
Hibernate 코어에는 많은 패키지가 포함되어 있으며, 각각은 hql, sql 및 기타 특정 기능과 관련되어 있습니다.
커플 링
응용 프로그램의 한 영역을 변경하면 전체 응용 프로그램에서 더 적은 수의 변경이 필요하므로 낮은 결합이 바람직합니다. 장기적으로 이것은 수정하고 애플리케이션에 새로운 기능을 추가하는 것과 관련된 많은 시간, 노력 및 비용을 경감할 수 있습니다.
다음은 인터페이스를 사용하여 얻을 수 있는 세 가지 주요 이점입니다.
- 인터페이스는 재사용을 촉진하는 계약을 정의하는 방법을 제공합니다. 객체가 인터페이스를 구현하는 경우 해당 객체는 표준을 준수해야 합니다. 다른 개체를 사용하는 개체를 소비자라고 합니다. 인터페이스는 개체와 소비자 간의 계약입니다.
- 인터페이스는 또한 프로그램을 더 쉽게 이해할 수 있도록 추상화 수준을 제공합니다. 인터페이스를 통해 개발자는 많은 세부 사항에 들어가지 않고도 코드가 동작하는 일반적인 방식에 대해 이야기할 수 있습니다.
- 인터페이스는 구성 요소 간의 낮은 결합을 적용하므로 인터페이스를 구현하는 클래스의 구현 변경 사항으로부터 인터페이스 소비자를 쉽게 보호할 수 있습니다.
Hibernate Core에 의해 정의된 모든 인터페이스를 검색해 봅시다. 이를 위해 CQLinq 를 사용하여 코드 기반을 쿼리합니다.
|
1 |
from t in Types where t . IsInterface select t |
우리의 주요 목표가 낮은 결합을 적용하는 것이라면 인터페이스를 사용할 때 사용하는 유틸리티를 죽일 수 있는 일반적인 실수가 있습니다. 인터페이스 대신에 구체적인 클래스를 사용하는 것이며 이 문제를 더 잘 설명하기 위해 다음 예를 들어보겠습니다.
클래스 A는 계산() 메서드를 포함하는 인터페이스 IA를 구현하고 소비자 클래스 C는 다음과 같이 구현됩니다.
|
1 2 3 4 5 6 7 8 9 10 11 |
public class C < br > { … . public void calculate ( ) { … . . m_a . calculate ( ) ; … . } A m_a ; } |
클래스 C는 인터페이스 IA를 참조하는 대신 클래스 A를 참조합니다. 이 경우 낮은 결합 이점을 잃게 되며 이 구현에는 두 가지 주요 단점이 있습니다.
- IA의 다른 구현을 사용하기로 결정했다면 C 클래스의 코드를 변경해야 합니다.
- IA에 없는 A에 몇 가지 메소드를 추가하고 C가 이를 사용하면 인터페이스 사용의 계약 이점도 잃게 됩니다.
C#은 IA의 메서드가 구체적인 클래스에 대한 참조에서 호출되지 않고 인터페이스에 대한 참조에서만 호출되도록 하기 위해 언어에 명시적 인터페이스 구현 기능을 도입했습니다. 이 기술은 개발자가 인터페이스 사용의 이점을 잃지 않도록 보호하는 데 매우 유용합니다.
JArchitect를 사용하면 CQLinq 를 사용하여 이러한 종류의 실수를 확인할 수 있습니다. 아이디어는 다른 메서드에서 직접 사용하는 구체적인 클래스에서 모든 메서드를 검색하는 것입니다.
|
1 2 3 4 5 6 7 8 9 |
from m in Methods where m . NbMethodsCallingMe > 0 && m . ParentType . IsClass && ! m . ParentType . IsThirdParty && ! m . ParentType . IsAbstract let interfaces = m . ParentType . InterfacesImplemented from i in interfaces where i . Methods . Where ( a = > a . Name == m . Name && a . ParentType ! = m . ParentType ) . Count ( ) > 0 select new { m , m . ParentType , i } |
예를 들어 SessionFactoryImplementor 인터페이스를 구현하는 SessionFactoryImpl의 getEntityPersister 메소드는 이 문제와 관련이 있습니다.
SessionFactoryImpl.getEntityPersister를 직접 호출하는 메서드를 검색해 보겠습니다.
|
1 2 3 |
from m in Methods where m . IsUsing ( "org.hibernate.internal.SessionFactoryImpl.getEntityPersister(String)" ) select new { m , m . NbBCInstructions } |
SessionImpl.instantiate와 같은 메소드는 인터페이스를 사용하는 대신 getEntityPersister를 직접 호출하여 인터페이스 사용의 이점을 깨뜨립니다. 다행히 최대 절전 모드 코어에는 이 문제가 있는 메서드가 많이 포함되어 있지 않습니다.
외부 항아리와 결합
외부 라이브러리를 사용하는 경우 전체 애플리케이션에 영향을 미치지 않고 타사 라이브러리를 다른 라이브러리로 쉽게 변경할 수 있는지 확인하는 것이 좋습니다. 타사 라이브러리를 변경하도록 권장할 수 있는 많은 이유가 있습니다.
다른 라이브러리는 다음을 수행할 수 있습니다.
- 더 많은 기능이 있습니다
- 더 강력한
- 더 안전한
hql 쿼리를 구문 분석하는 데 사용되는 antlr lib 의 예를 들어 antlr보다 강력한 다른 파서가 생성되었다고 상상해 봅시다. 새 파서로 antlr을 쉽게 변경할 수 있습니까?
이 질문에 답하기 위해 최대 절전 모드에서 직접 사용하는 메서드를 검색해 보겠습니다.
|
1 2 3 |
from m in Methods where m . IsUsing ( "antlr-2.7.7" ) select new { m , m . NbBCInstructions } |
그리고 간접적으로 사용한 것들:
|
1 2 3 4 |
from m in Projects . WithNameNotIn ( "antlr-2.7.7" ) . ChildMethods ( ) let depth0 = m . DepthOfIsUsing ( "antlr-2.7.7" ) where depth0 > 1 orderby depth0 select new { m , depth0 } |
많은 방법이 antlr을 직접 사용하여 최대 절전 모드 코어를 그것과 고도로 결합시키며, antlr을 다른 것으로 변경하는 것은 쉬운 일이 아닙니다. 이 사실이 우리가 최대 절전 모드 설계에 문제가 있다는 것을 의미하지는 않지만 타사 lib를 사용할 때 주의해야 하고 타사 lib가 애플리케이션과 로우 커플링되어야 하는지 잘 확인해야 합니다.
응집력
단일 책임 원칙은 클래스가 변경해야 하는 이유는 단 하나여야 한다고 말합니다. 이러한 수업은 응집력이 있다고 합니다. 높은 LCOM 값은 일반적으로 응집력이 낮은 클래스를 정확히 나타냅니다. 몇 가지 LCOM 메트릭이 있습니다. LCOM은 [0-1] 범위의 값을 사용합니다. LCOMHS(HS는 Henderson-Sellers를 나타냄)는 [0-2] 범위의 값을 사용합니다. LCOMHS 메트릭은 종종 응집력이 없는 유형을 감지하는 데 더 효율적인 것으로 간주됩니다.
1보다 높은 LCOMHS 값은 경고로 간주되어야 합니다.
일반적으로 응집력에 더 관심이 있는 클래스는 많은 메소드와 필드를 가진 클래스입니다.
메소드와 필드가 많은 타입을 찾아보자.
|
1 2 3 4 |
from t in Types where ( t . Methods . Count ( ) > 40 | | t . Fields . Count ( ) > 40 ) && t . IsClass orderby t . Methods . Count ( ) descending select new { t , t . InstanceMethods , t . Fields , t . LCOMHS } |
소수의 유형만이 이 쿼리와 관련이 있으며 모든 유형에 대해 LCOMHS가 1보다 작습니다.
주석 사용
주석 기반 개발은 Java 개발자가 번거로운 구성의 고통을 덜어줍니다. 그리고 상용구 코드에서 소스 코드를 해제할 수 있는 강력한 기능을 제공합니다. 결과 코드에는 버그가 포함될 가능성도 적습니다.
hibernate core에 의해 정의된 모든 어노테이션을 검색해보자.
|
1 |
from t in Types where t . IsAnnotationClass && ! t . IsThirdParty select t |
많은 주석이 정의되어 개발자가 최대 절전 모드를 사용하기 쉽게 만들고 구성 파일의 골칫거리를 피할 수 있습니다.
결론
Hibernate Core는 배울 수 있는 오픈 소스 프로젝트의 좋은 예입니다. 주저하지 말고 내부를 살펴보십시오.