JAVA의 종속성 반전 원칙
미국 법의 가장 기본적인 원칙 중 하나는 "모든 사람은 평등하다"입니다. 우리는 그것이 어떤 투쟁이나 유혈 사태를 통해 달성되었는지는 상관하지 않으며 다음과 같이 정의됩니다.
public final boolean 모든 사람은 평등하다(사람 1, 사람 2){
사실을 반환;
}
미국의 기본법처럼 각 주마다 법률이 다르지만 뉴욕은 뉴욕 기본법이라고 부를 수 있습니다. 뉴욕 기본법은 미국의 기본법을 계승하는 관계를 가져야 합니다. 상태이지만 이 메소드의 재작성은 허용되지 않습니다.
뉴욕에서의 집행과 관련하여 다음이 사용됩니다.
미국 기본법 = 새로운 뉴욕 기본법
어디에서나 "모든 사람은 평등하다"라는 방법을 호출하면 "true"가 반환됩니다. 이는 모든 사람의 평등의 원칙은 어디에서나 바뀔 수 없다는 것을 의미하며 이는 미시를 결정하는 거시적 결정이며 New 때문에 남성과 여성 사이에는 변하지 않습니다. 요크. 여성 불평등.
예를 들어, 어떤 나라에는 모두를 위한 기본법과 평등의 방법이 있습니다. 정의는 다음과 같아야 합니다.
public boolean 모든 사람은 평등하다(사람 1, 사람 2){
사실을 반환;
}
예를 들어, 어떤 나라의 특정 장소에도 기본법이 있습니다. 그러나 "모든 사람은 평등하다"는 방식이 최종적이지 않기 때문에, 특정 장소의 기본법도 특정 국가의 기본법을 계승합니다. 특정 위치에서 구현되면 다음과 같이 작성될 수 있습니다.
특정 국가의 기본법 = 특정 지역의 새로운 기본법
또는
특정 장소의 기본법 = 특정 장소의 새로운 기본법
어쩌면 특정 지역의 기본법이 특정 국가의 기본법을 계승했을 때 "모든 사람은 평등하다"라는 방식을 다시 작성하여 다음과 같이 변경했습니다.
public boolean 모든 사람은 평등하다(사람 1, 사람 2){
if(사람 1==특정 장소의 사람&& 사람 2==특정 장소의 사람){
if(사람 1과 사람 2가 동일한 속성을 가짐){
if(사람 1과 사람 2는 동일한 사람이 아닌 점을 제외하면 동일합니다){
if(다른 사람은 아무 일도 일어나지 않습니다){
사실을 반환;
}또 다른{
거짓을 반환;
}
}또 다른{
거짓을 반환;
}
}또 다른{
거짓을 반환;
}
}또 다른{
거짓을 반환;
}
}
"JAVA and Patterns"에 따른 종속성 반전 원칙에 대해 이야기해 보겠습니다.
추상 수준에는 전체 시스템에 중요하고 불가피성을 반영하는 응용 프로그램 시스템의 비즈니스 논리와 거시적 수준의 전략적 결정이 포함되어 있는 반면, 구체적인 수준에는 전술적 구현과 관련된 일부 사소한 구현 관련 알고리즘 및 논리가 포함되어 있습니다. 결정에는 상당한 가능성이 따릅니다. 특정 수준의 코드는 자주 변경되며 오류는 피할 수 없습니다. 추상화 수준은 구체성 수준에 따라 달라집니다. 특정 수준에서 세부 사항을 사용하는 알고리즘 변경은 추상 수준의 거시적 비즈니스 로직에 즉시 영향을 미쳐 미시적 측면에서 거시적 측면을 결정하고 전략을 결정하는 전술, 필요성을 결정하는 기회를 제공합니다. 이건 말도 안 돼요.
이 글을 읽고 나면 앞으로 코드를 작성할 때 왜 더 자주 사용해야 하는지 이해하게 될 것입니다.
추상적 논리 = 새로운 구체적 논리
가능한 한 적게 사용하십시오:
특정 논리 = 새로운 특정 논리
이것은 현재 옹호되는 인터페이스 지향 프로그래밍입니다. 다음은 인터페이스 지향 프로그래밍의 또 다른 실제 예입니다.
일반적으로 List를 더 자주 사용해야 합니다. List 자체는 Collection에서 상속된 인터페이스입니다.
목록 목록=새 Vector();
이 방식으로 선언된 List는 Vector의 하위 클래스이기 때문에 실제로는 Vector 유형입니다. Liskov 대체 원칙에 따라 하위 클래스는 상위 클래스가 허용될 수 있는 곳이면 어디든 허용될 수 있습니다. 이때 List는 동기화되며, 당연히 특정 성능에 영향을 받습니다. 향후에 동기화가 필요하지 않은 환경으로 변경한다면 위의 코드를 다음과 같이 변경하면 됩니다.
목록 목록=new ArrayList();
다른 코드는 수정할 필요가 없습니다. 현재 List의 실제 유형은 ArrayList입니다.
이 시점에서 디자이너가 인터페이스 지향 프로그래밍을 소중히 여기는 이유를 알 수 있습니다. 인터페이스를 제공한 후 구현자는 인터페이스를 기반으로 특정 클래스를 구현하고 구현자가 원본의 무결성을 파괴하는 것에 대해 걱정할 필요가 없기 때문입니다. 프로그램을 작성하면 디자이너는 인터페이스의 메서드에만 신경쓰지 않고 구체적인 클래스의 보조 메서드에 대해서는 걱정하지 않습니다. 그러나 JAVA 클래스를 추가하는 등의 추가 비용이 발생합니다. 추상 클래스가 효율성을 떨어뜨릴 수 있다면 도구 클래스와 같은 구체적인 결합을 사용하는 것이 더 나은 선택입니다.