>  기사  >  Java  >  Java의 인터페이스 지향 프로그래밍 예에 대한 자세한 설명

Java의 인터페이스 지향 프로그래밍 예에 대한 자세한 설명

黄舟
黄舟원래의
2017-09-20 10:24:441601검색

이 글에서는 인터페이스의 본질, 객체 지향 프로그래밍과 인터페이스 지향 프로그래밍의 관계, 그리고 이를 필요로 하는 저자 자신의 이해를 결합하여 모든 사람에게 인터페이스 지향 프로그래밍에 대한 몇 가지 사항을 소개합니다.

객체지향 프로그래밍 언어를 사용하는 프로그래머들이라면 '인터페이스'라는 용어가 익숙할 거라 생각하는데, 혹시 인터페이스가 무슨 용도인지 궁금하시죠? 그것과 추상 클래스의 차이점은 무엇입니까? 인터페이스 대신 추상 클래스를 사용할 수 있나요? 게다가 프로그래머라면 "인터페이스 지향 프로그래밍"이라는 말을 자주 듣게 되는데, 그게 무슨 뜻일까요? 이념적 의미는 무엇입니까? 객체 지향 프로그래밍과의 관계는 무엇입니까? 이 기사에서는 이러한 질문에 하나씩 답할 것입니다.

1. 인터페이스 지향 프로그래밍과 객체 지향 프로그래밍의 관계는 무엇입니까?

먼저 인터페이스 지향 프로그래밍과 객체 지향 프로그래밍은 동일한 수준이 아닙니다. 객체지향 프로그래밍보다 더 발전된 프로그래밍이지만 객체지향 이데올로기 시스템에 속해 있으며 그 일부입니다. 즉, 객체지향 프로그래밍 시스템에서 아이디어의 본질 중 하나이다.

2. 인터페이스의 본질

인터페이스는 표면에 본문 코드가 없는 여러 메서드 정의의 모음이며 고유한 이름을 가지며 클래스나 다른 인터페이스로 구현될 수 있습니다. 계승). 형식은 다음과 같습니다.


interface InterfaceName
{
void Method1();
void Method2(int para1);
void Method3(string para2,string para3);
}

그렇다면 인터페이스의 본질은 무엇일까요? 즉, 인터페이스의 존재 의미는 무엇인가? 다음 두 가지 관점에서 생각해 볼 수 있다고 생각합니다.

1) 인터페이스는 규칙의 집합이며, 이 인터페이스를 구현하는 클래스나 인터페이스가 가져야 할 규칙의 집합을 규정합니다. "당신이... 있다면... 할 수 있어야 합니다..."라는 자연의 철학을 반영합니다.

예를 들어 자연에서는 누구나 먹을 수 있다. 즉, "인간이라면 먹을 수 있어야 한다"는 것이다. 그런 다음 컴퓨터 프로그램으로 시뮬레이션할 때 IPerson(일반적으로 인터페이스 이름은 "I"로 시작) 인터페이스와 Eat()라는 메서드가 있어야 합니다. 그런 다음 "사람"을 나타내는 모든 클래스가 IPerson 인터페이스를 구현해야 한다고 규정합니다. "인간이라면 먹을 수 있어야 한다"는 자연의 법칙을 시뮬레이션한 것입니다.

여기서 객체지향적 사고에 대해서도 알 수 있을 것 같아요. 객체지향 사고의 핵심 중 하나는 현실 세계와 현실 세계의 추상적인 것들을 클래스로 시뮬레이션하는 것입니다. 전체 프로그램은 각 클래스의 인스턴스에 의존하여 서로 통신하고 협력하여 시스템 기능을 완성합니다. 현실 세계의 작동 조건과 매우 일치하며 객체 사고의 본질을 지향합니다.

2) 인터페이스는 특정 세부적인 관점에서 유사한 것을 추상적으로 표현한 것입니다. 여기서는 "유사한 것"이라는 개념이 상대적이고 세부적인 관점에 따라 다르기 때문에 특정 세부적인 관점을 강조한다는 점에 유의하세요.

예를 들어, 내 눈에 나는 돼지와 근본적으로 다른 사람이다. 같은 반 친구와 내가 같은 부류라는 것은 받아들일 수 있지만, 나와 돼지가 같은 부류라는 것은 결코 받아들일 수 없다. 그러나 동물학자의 눈에는 돼지와 내가 같은 종류여야 한다면, 우리 둘 다 동물이기 때문에 그는 "사람"과 "돼지" 모두 IAnimal 인터페이스를 구현한다고 생각할 수 있으며, 동물 행동을 연구할 때 그는 나와 돼지를 별도로 취급하고 "동물"이라는 보다 큰 범위에서 연구할 것이지만 나와 나무 사이에는 본질적인 차이가 있다고 생각할 것입니다.

이제 유전학자가 있는데 상황이 다릅니다. 모든 생명체는 유전될 수 있기 때문에 그의 눈에는 나는 돼지와 다를 바 없을 뿐만 아니라 모기, 박테리아, 나무, 식물과도 다르지 않습니다. SARS 바이러스 사이에는 차이가 없습니다. 왜냐하면 우리 모두가 IDescendable 인터페이스(참고: 하강 vi. 상속)를 구현한다고 생각하기 때문입니다. 즉, 우리는 모두 유전 가능한 개체이며 연구되지 않습니다. 우리는 별개이지만 연구를 수행할 때 모든 생명체를 같은 종류로 간주할 것입니다. 그의 눈에는 인간과 바이러스의 구별이 없으며 단지 유전되는 물질과 비유전되는 물질만 있을 뿐입니다. 하지만 적어도 나와 돌 사이에는 차이가 있다.

그런데 어느 날 위대한 인물이 세상에 나타났습니다. 그의 이름은 레닌이었습니다. 그는 마르크스와 엥겔스의 변증법적 유물론의 걸작을 읽고 나서 유명한 결정을 내렸습니다. : 소위 실체란 의식에 의해 반영될 수 있는 객관적인 현실이다. 이 시점에서 나와 돌, 공기의 숨결, 숙어, 휴대폰 신호를 전송하는 전자기장 사이에는 아무런 차이가 없습니다. 왜냐하면 레닌의 눈에는 우리 모두가 의식에 의해 반영될 수 있는 객관적인 현실이기 때문입니다. 레닌이 프로그래머라면 그는 이렇게 말할 것입니다. 소위 문제는 "IReflectabe" 및 "IEsse" 인터페이스를 모두 구현하는 모든 클래스에 의해 생성되는 인스턴스입니다. (참고: 반영 v. 반영 esse n. 객관적 현실)

위의 예가 말도 안 된다고 생각하실 수도 있겠지만, 이것이 바로 인터페이스가 존재하는 이유입니다. 객체지향 사고의 핵심 개념 중 하나가 다형성(Polymorphism)입니다. 직설적으로 말하면 비슷한 것을 어느 정도 세분화된 보기 수준에서 구분 없이 획일적으로 다룬다는 뜻이다. 제가 감히 이런 일을 하는 이유는 바로 인터페이스의 존재 때문입니다. 유전학자와 마찬가지로 그는 모든 유기체가 IDescendable 인터페이스를 구현한다는 것을 이해하고 있으므로 유기체라면 Descend() 메서드가 있어야 합니다. 그래야 각 유기체를 개별적으로 연구하다가 결국 지쳐 죽는 대신 통일된 연구를 수행할 수 있습니다.

여기서는 인터페이스의 성격과 기능에 대해 직관적인 인상을 줄 수 없을 수도 있습니다. 그러면 다음 예시와 여러 디자인 패턴 분석을 통해 인터페이스가 내포하는 의미를 더욱 직관적으로 경험하게 될 것입니다.

3. 인터페이스 지향 프로그래밍 개요

위를 통해 모두가 인터페이스에 대한 이해와 인터페이스의 이념적 의미를 알고 있다고 생각합니다. 내 개인적인 정의는 시스템 분석과 아키텍처에서 레벨과 종속성을 구별하는 것입니다. 각 레벨은 상위 계층에 직접 서비스를 제공하지 않고(즉, 상위 계층에서 직접 인스턴스화되지 않음) 일련의 인터페이스를 정의합니다. , 위쪽에만 상위 계층은 인터페이스 기능을 노출하고 상위 계층은 하위 계층의 인터페이스에만 의존하며 특정 클래스에 의존하지 않습니다.

이 작업의 이점은 무엇보다도 시스템 유연성에 좋습니다. 하위 레이어를 변경해야 할 때 인터페이스와 인터페이스 기능이 변경되지 않는 한 상위 레이어는 수정할 필요가 없습니다. WD 60G 하드 드라이브를 Seagate 160G 하드 드라이브로 교체하는 것처럼 상위 레이어 코드를 변경하지 않고 전체 하위 레이어를 교체할 수도 있습니다. 대신 컴퓨터의 다른 부분을 변경할 필요가 없습니다. 원래 하드 드라이브를 설치하고 새 하드 드라이브를 설치하십시오. 컴퓨터의 다른 부분은 특정 하드 디스크에 의존하지 않고 IDE 인터페이스에만 의존하기 때문입니다. 교체할 수 있습니다. 여기에서 보면 프로그램 속 인터페이스가 실제 인터페이스와 매우 유사해서 인터페이스라는 단어가 정말 비슷하다는 생각을 늘 하고 있습니다!

인터페이스 사용의 또 다른 이점은 하드 드라이브를 만드는 사람이 인터페이스가 일관적인 한 CPU나 모니터를 만드는 사람을 기다릴 필요가 없는 것처럼 다양한 구성 요소나 수준의 개발자가 병렬로 작업을 시작할 수 있다는 것입니다. 디자인이 합리적이며 동시에 개발을 완료하여 효율성을 높일 수 있습니다.

이 글은 여기서 먼저 끝납니다. 마지막으로 한 가지 더 말씀드리고 싶습니다. 객체 지향의 본질은 현실을 시뮬레이션하는 것이며, 이것이 제 글의 핵심이라고도 할 수 있습니다. 그러므로 현실에서 객체지향적인 것에 대해 더 많이 생각하는 것은 시스템 분석 및 설계 능력을 향상시키는 데 큰 도움이 될 것입니다.

다음 글에서는 예제를 사용하여 인터페이스 프로그래밍의 기본 방법을 보여 드리겠습니다.

세 번째 기사에서는 고전적인 디자인 패턴의 인터페이스 지향 프로그래밍 아이디어를 분석하고, .NET 계층 아키텍처의 인터페이스 지향 아이디어를 분석하겠습니다.

1 "인터페이스 지향 프로그래밍"의 "인터페이스"와 특정 객체 지향 언어의 "인터페이스"라는 두 단어에 대해 ​​

친구가 "인터페이스"에 "인터페이스"라는 단어를 언급하는 것을 보았습니다. 지향 프로그래밍"은 순수 프로그래밍 언어의 인터페이스 범위보다 넓어야 합니다. 곰곰이 생각해 보니 맞는 말인 것 같습니다. 내가 여기에 쓴 내용은 참으로 불합리하다. 객체지향 언어에서 "인터페이스"는 C#에서 인터페이스 키워드로 정의된 인터페이스와 같은 특정 코드 구조를 의미한다고 생각합니다. "인터페이스 지향 프로그래밍"에서 "인터페이스"는 소프트웨어 아키텍처 관점과 보다 추상적인 수준에서 특정 기본 클래스를 숨기고 다형성을 구현하는 데 사용되는 구조적 구성 요소를 의미한다고 할 수 있습니다. 이런 의미에서 추상 클래스가 정의되고 그 목적이 다형성을 달성하는 것이라면 이 추상 클래스를 "인터페이스"라고 부르는 것이 합리적이라고 생각합니다. 하지만 다형성을 구현하기 위해 추상 클래스를 사용하는 것이 합리적일까요? 아래 두 번째 기사에서 설명합니다.

요약하자면, "인터페이스"라는 두 가지 개념은 서로 다르며 서로 연관되어 있다고 생각합니다. "인터페이스 지향 프로그래밍"의 인터페이스는 다형성을 달성하고 소프트웨어 유연성과 유지 관리성을 향상시키는 데 사용되는 이념적 수준의 아키텍처 구성 요소인 반면, 특정 언어의 "인터페이스"는 이 이념적 수준에서 코드로 구현되는 구체적인 구성 요소입니다. .

2. 추상 클래스 및 인터페이스 관련

답변에서 이 문제가 뜨겁게 논의되는 문제임을 확인했습니다. 기사에서 이에 대해 논의하는 것에 대해 두 번 생각하지 않아서 죄송합니다. 이 문제에 대한 개인적인 이해는 다음과 같습니다.
특정 코드만 보면 이 두 개념이 모호해지기 쉽고 인터페이스가 중복된다고 생각하기도 합니다. 왜냐하면 다중 상속을 제외하고는 특정 기능만으로는 충분하지 않기 때문입니다. (C#, Java) 추상 클래스는 인터페이스를 완전히 대체할 수 있는 것 같습니다. 그런데 다중상속을 구현하기 위한 인터페이스가 존재하는가? 물론 그렇지 않습니다. 제 생각에는 추상 클래스와 인터페이스의 차이점은 사용 동기에 있습니다. 추상 클래스를 사용하는 목적은 코드 재사용을 위한 것이고, 인터페이스를 사용하는 동기는 다형성을 달성하는 것입니다. 따라서 어딘가에 인터페이스를 사용할지 추상 클래스를 사용할지 결정하지 못했다면 동기를 생각해 보세요.

IPerson 인터페이스에 대해 의문을 제기하는 친구들을 보았습니다. 개인적으로 이해한 바에 따르면 IPerson 인터페이스를 정의해야 하는지 여부는 특정 애플리케이션에 따라 다릅니다. 프로젝트에 Women과 Man이 있고 둘 다 Person을 상속하고 Women과 Man의 메서드가 대부분 동일하다면

DoSomethingInWC() 메서드 하나만 다릅니다(예제는 다소 저속하므로 양해해 주시기 바랍니다). 물론 AbstractPerson 추상 클래스를 정의하는 것이 더 합리적입니다. 다른 모든 메서드를 포함할 수 있고 하위 클래스는 DoSomethingInWC()만 정의하므로 반복되는 코드의 양이 크게 줄어듭니다.

그러나 우리 프로그램의 Women 및 Man 클래스에 기본적으로 공통 코드가 없고 이를 인스턴스화해야 하는 PersonHandle 클래스가 있고 그들이 남성인지 여성인지 알고 싶지 않고 그냥 처리하면 됩니다. 그들을 인간으로 인식하고 다형성을 달성하려면 이를 인터페이스로 정의해야 합니다.

간단히 말하면 인터페이스와 추상 클래스의 차이점은 주로 사용 동기에 있는 것이지 그 자체에 있는 것이 아닙니다. 추상 클래스로 정의해야 하는지 인터페이스로 정의해야 하는지는 특정 환경의 컨텍스트에 따라 다릅니다.

게다가 인터페이스와 추상 클래스의 또 다른 차이점은 추상 클래스와 해당 하위 클래스 사이에 일반 및 특수 관계가 있어야 하는 반면 인터페이스는 하위 클래스가 구현해야 하는 규칙 집합일 뿐이라는 것입니다. (물론 때로는 일반적이고 특별한 관계가 있을 수 있지만 인터페이스를 사용하는 목적은 여기에 있지 않습니다.) 예를 들어 차량을 추상 클래스로 정의하고 자동차, 비행기, 선박을 하위 클래스로 정의하는 것은 허용됩니다. , 비행기, 배는 특별한 교통 수단입니다. 또 다른 예는 Icomparable 인터페이스입니다. 이는 이 인터페이스를 구현하는 클래스가 비교 가능해야 한다는 것입니다. Car 클래스가 Icomparable을 구현한다면 이는 Car에 두 개의 Car 인스턴스를 비교하는 메서드가 있다는 의미일 뿐입니다. 더 비싸거나 클 수도 있지만 "자동차는 특별한 종류"라고 말할 수는 없습니다. 비교할 수 없는 것입니다.” 이것은 문법적으로 불합리합니다.

요약

일반적으로 인터페이스 지향 프로그래밍이란 객체 지향 시스템의 클래스나 모듈 간의 모든 상호 작용이 인터페이스에 의해 완료된다는 의미입니다.

위 내용은 Java의 인터페이스 지향 프로그래밍 예에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.