내일배움캠프 42일차 TIL + 인터페이스

인터페이스

 

추상화

인터페이스는 추상적인 개념으로 실제로 구현된 메서드가 없고 메서드의 시그니처만을 가짐

>> 인터페이스는 인스턴스화될 수 없으며, 구현체가 필요함

 

메서드 시그니처

인터페이스는 구현 클래스가 반드시 구현해야 하는 메서드들의 시그니처를 정의

메서드의 이름, 매개변수, 반환 타입이 포함

 

다중 상속 가능

클래스는 하나의 클래스만 상속받을 수 있지만, 여러 인터페이스를 동시에 구현할 수 있음

이를 통해 다중 상속을 흉내내는 것이 가능

 

강제적 구현

클래스가 인터페이스를 구현하면, 인터페이스에서 정의한 모든 메서드를 반드시 구현해야 한다

이로 인해 클래스는 인터페이스에 정의된 동작을 강제로 구현하게 됨

 

인터페이스 간 확장

인터페이스는 다른 인터페이스를 확장(extends)할 수 있음

이를 통해 더 큰 범위의 공통 동작을 정의할 수 있다

 

인터페이스를 통해 클래스들은 공통적인 동작을 정의하고

이러한 동작들을 구현하는 클래스들은 해당 인터페이스를 구현(implement)함으로써 공통 규약을 준수할 수 있다

 

 

인터페이스를 사용하는 이유

>> 코드는 결합도가 낮아야 한다!!!

 

결합도가 높다 = 클래스 간 의존도가 높다  >> 유연성이 떨어짐

구체적 구현 클래스가 아닌 작은 단위의 여러 인터페이스를 사용하자

 

ex. 휴대폰 클래스를 만든다

갤럭시 S2 , 갤럭시 S11 이런식으로 클래스를 만들 때

이제 필요없는 기술, 새로운 기술 등이 있다.

기존 기능을 계속 상속받아오기 보단

카메라 기능을 인터페이스로, 와이파이 기능을 인터페이스로 이런식으로 기능별로 빼고

필요한 기능만 상속받아서 휴대폰을 만드는게 더 낫

 

 

협업의 관점

 

개발기간 단축 - 인터페이스라는 구현되지 않은 틀만 작성하면 구현 클래스에서도 코드 작성 및 개발 가능

표준화 가능 - 여러명의 개발자가 작업해도 정형화된 작업 가능

독립적인 프로그래밍 가능 - 선언은 인터페이스에서, 구현은 클래스에서

 

인터페이스 작업 예시

페이먼트라는 인터페이스 (지불기능)

pay 함수를 가지고 있당.

 

public interface Payment
{
	public void Pay();
}

public class Card : Payment
{
		public void Pay(){}
}

public class Cash : Payment
{
		public void Pay(){}
}

public class QR : Payment
{
		public void Pay(){}
}

(x)
public class Store
{
		Card card;
		Cash cash;
		QR qr;
}


(o)
public class Store
{
		Payment payment;
		payment.Pay();
}

페이먼트 자체로 찾기 때문에, 카드 캐쉬 큐알 어떤거를 내도 꼬이지 않고 사용할 수 있다