쉽게 생각해서 다형성 이란 -> 인터페이스 혹은 클래스를 상속받으면 상속받은 클래스들은 타입이 부모 클래스가 "되기 때문에" 한 타입으로 묶어서 정의 가능함. 또한 부모 클래스에 있는 메서드를 사용가능하다. 즉 자바는 어떤 타입이냐에 따라 다르기 때문에. 인터페이스의 경우 불릿 포인트와 캐릭터 포인트를 상속 해줬고 불릿 포인트의 타입은 인터페이스 캐릭터 포인트의 타입도 역시 인터페이스 둘 타입은 인터페이스 타입이기 때문에 매개변수에 타입을 인터페이스로 넣어도 오류가 뜨지 않는다.
네! 달아주신 댓글로 보았을 때 이해하고 계신게 맞아 보입니다. 컴파일러는 프로그래머가 작성한 클래스 내부를 비교해서 같음을 비교하지 않습니다. 그저 타입을 가지고 같음을 비교합니다. 사용자 정의 클래스에서 공통부분을 설정하기 위해선 인터페이스 등을 사용해서 다형성을 컴파일러에게 알려줘야 합니다! 질문 있으시면 언제든지 해주셔도 됩니다~~!!
영상 잘 봤습니다. 한가지 객체가 여러 타입에 대입하게 만드는거를 다형성, 한가지 객체가 한가지 타입에 대입하는거는 단혀성 이다. 이렇게 다형성을 작업을 할수있게 인터페이스를 만들거나 추상 클래스 또는 일반 클래스를 만들어서 공통 프로퍼티들을 뽑아서 정의하는거를 추상화 작업 추상화 작업이라고 하는 이유는 메서드 또는 메서드의 파라미터 타입, 반환 타입을 지정해주고 내부 로직은 오버라이딩을 하든 뭐를 하든 신경안쓰기 때문 맞을까요?
추상화란 단어에 의미를 여쭤보신 것 맞으시죠? 지금 설명해주신 추상화란 단어의 의미는 좀 틀린 것 같아요 제가 한번 설명해드리겠습니다! 추상화란 서로 다른 객체들이 공통적으로 갖고있는 특성을 모은 것이라고 생각하시면 됩니다. 이해가 바로 안되실 것 같아 몇 가지 예를 들어드리겠습니다 1. 강아지, 앵무새, 고양이, 코끼리 등은 모두 다른 동물이만 동물의 특성 중 하나인 울음소리를 갖는다는 특징이 있습니다. 이럴경우 강아지, 앵무새, 고양이, 코끼리 객체가 가지고 있는 공통 특성인 운다()라는 함수를 갖는 일반 클래스나 추상 클래스나 인터페이스등을 만들어서 울수있는 것들에 대한 추상화를 할 수 있을 것입니다. 당연히 이렇게 되면 동물 객체들을 다루는 로직에서 운다()를 추상화하고있는 인터페이스등을 가지고 다형하게 프로그래밍할 수 있을 것입니다. 2. 네이버페이, 카카오페이, 페이코 등의 결제수단들은 아마 결제(), 환불()이란 이름의 함수로 추상화할 수 있을 것입니다. 왜냐하면 앞서 말씀드린 결제수단들은 모두 결제를 할 수 있고 그에 따른 환불도 할 수 있을 것이기 때문입니다. 이렇게 추상화 해놓고 다형성있게 로직을 작성해 놓으면 영상에서 말씀 드린 것 처럼 다른 결제 수단의 추가에 따른 코드 변경이 없어질 수 있습니다. 이런 것을 개방 폐쇄 원칙 (OCP)라고 하는데 이 부분에 대해선 한번 찾아보시면 좋을 것 같습니다. 조금 어려운 말로 정리를 한다면 세상에 있는 다양한 문제를 컴퓨터 안에서 일반되게 처리할 수 있도록 공통문보를 추출하는 것을 추상화라고 생각하시면 될 것 같습니다. 다른 질문 있으시면 편안하게 댓글로 질문 주시면 최대한 답변 드리겠습니다. 감사합니다!
좋은강의 감사합니다 질문이있는데 조상class a=자손class b 같은경우 말씀하신것처럼 a에는 b의 필수요소가 있으니까 a와 b에서 구현한건 쓸수있다. 는 알겠습니다만 반대로 자손class b = (자손class) 조상a 이 경우에 왜 이렇게쓰는지 멤버개수를 맞추려고 한다는데 그냥 조상 class a 를 new연산자로 받아와서 쓰면되는게아닌가요?ㅠ 이해가잘안갑니다
안녕하세요! 좋은 질문입니다. 언제든지 이해가 안가시는게 있으시면 말씀 주세요! '자손class b = (자손class) 조상a' 과 같이 사용하는 경우는 이미 '조상a', '조상b', '조상c'가 만들어진 상황에서 그 각각의 객체를 '자손class'로 받아서 처리하게 되면 기능이 추가될 때 마다 코드를 변경하지 않아도 되는 코드가 되기 때문입니다. 이러한 이유로 인터페이스를 사용하고 이런 것을 객체지향에서는 OCP라고 부르는데 이쪽을 좀 더 공부해보시면 좋을 것도 같습니다. 제 영상 ua-cam.com/video/TnvfaFNuF9U/v-deo.html 14분 정도부터 보시면 히드라리스크라는 클래스를 추가하면서 그 예를 설명드리고 있으니 한번 확인해보시면 좋을 것 같습니다. 혹시 제 답변 중에 이해가 안되시는 부분이 있으시면 언제든지 댓글 달아주시기 바랍니다. 감사합니다!
인터페이스란 서로다른 클래스들의 최대 공약수 같은 느낌이군요. (서로다른 클래스들의 공통된 특징들을 보장하는) 강의 진짜 명료합니다. 오늘도 인터페이스고자탈출. 여기서 질문한가지만 남기자면.. 같은 타입의 변수와 변수명 (int x, int y)를 가져도 클래스 명이 다르면 컴파일러는 이를 서로 다른것으로 인식하잖아요? 이는 메모리 상의 위치가 초기 선언시에 달라서 그런건지.. 그 root cause(근본 원인)이 어디 있는건가요?
인터페이스를 보고 최대 공약수를 생각하신거라면 정말 제대로 이해하고 계신겁니다! 근래에 들었던 표현 중 가장 멋있는 표현이네요! 최대 공약수로 표현하신 것을 소프트웨어 공학적으로 표현하자면 데이터를 '추상화' 했다고 표현할 수 있습니다! '추상화'라는 것은 모든 설계와 많은 기술의 근간이 되는 아주 중요한 개념입니다 인터페이스를 자주 사용하시다보면 자연스럽게 관심을 가지게 되실겁니다. 주신 질문은 너무 당연하게 생각을 해서 한번도 생각해본적이 없는 내용의 질문이네요 여러모로 찾아보았지만 올바른 답을 찾기 쉽지 않았습니다! 저도 다른 곳에 질문을 통해 답을 얻어보도록 하겠습니다! ㅜㅜ 감사합니다
안녕하세요 안영훈님 마수리입니다! 주신 질문에 대한 대답을 얻어 댓글 답니다! 부디 원하시는 대답이 되셨으면 합니다 결론은 클래스의 '이름' 자체가 식별자기기 때문입니다! 클래스의 이름은 각 타입 간의 차이를 식별하는데 사용하는 기본 식별자입니다. 그래서 우리는 그 식별자 겹치게 설계할 수 없으며 네임스페이스를 이용해서 식별자(이름)이 같더라도 서로 식별할 수 있게 하는 겁니다!
안녕하세요~ 좋은 질문이 있어 그에 관한 답을 편집해 하이라이트로 남깁니다. 필요하신 분은 읽어보시면 좋겠다고 생각합니다~ 다른 분들이 보실 수 있기에 interface를 이용해 얻을 수 있는 설계의 장점에 대해서 설명하겠습니다. 1. 구체적인 객체에 의존해서 구현하는 것이 아닌 추상화된 객체를 이용해 구현이 가능하다. interface의 개념은 초창기 Widnwos에도 있었습니다. Microsoft사는 자신의 소프트웨어에 다양한 I/O 객체를 손쉽게 접목시킬 수 있도록 모든 I/O 드라이버에 Read,Write,Open,Close,Seek 기능 구현을 강제 했고 이들은 모두 같은 함수 형태를 가지고 있어야 했습니다. (현재의 interface와 같은 기능이죠?) 그렇게 되면 Windows는 로지텍사의 키보드를 사용하든 Microsoft사의 키보드를 사용하던 상관없이 무조건 Read 함수를 호출하면 어떤 키보드인지 상관없이 값을 읽을 수 있게 하였습니다. 이러한 개념은 제가 만든 IEnumerable 관련 영상에서도 말씀드렸지만 IEnumerable을 구현하는 객체는 그 무엇이든 간에 객체를 열거 할 수 있는 것 등으로 .Net Framework안에 들어와 있습니다. interface를 사용하면 이런 것과 같이 구체 클래스가 아닌 그들이 가지고 있는 행동(함수)에 맞춰 개발을 할 수 있기 때문에 다양한 현실세계를 컴퓨터 안에서 일관되게 처리 할 수 있게 됩니다. 2. 객체간에 의존성을 없앨 수 있습니다. 의존성이란 설계에 아주 중요한 개념으로 객체가 어떻게 소통하는지 나타내는 것입니다. 설계를 구체 클래스에 하게 되면 객체간의 강한 의존성이 생기게 됩니다. 그래서 interface를 사용해서 return이나 parameter로 다른 객체와 소통하는 구간에 사용하면 의존성이 줄어들어 자신과 소통하는 객체의 변화에 강한 클래스를 만들 수 있게됩니다. 이런 의존성은 과거부터 있었던 많은 Framework에서 발전해 MVC, MVVM 패턴등으로도 승화 되었고 depedecny injection등의 기술이 사용됩니다. 관련해서 GOF의 디자인패턴이란 책을 보시면 다형성을 이용한 객체의 의존성을 관리하는 여러 패턴을 살펴보실 수 있을 것입니다. [추가] 3. 단위 테스트 가능한 코드를 만들 수 있다 테스트 가능한 코드를 만드는 것은 객체지향 적 사고를 품는 설계의 방식을 필요합니다. 테스트 가능하도록 설계하지 않은 코드는 아예 단위 테스트가 불가능 하거나 직접 데이터를 조작하고 지우는 방법의 테스트를 진행해야 합니다. 하지만 여기서 주목해야 할 부분은 ".Net 예제로 배우는 단위 테스트"의 저자 로이 오셔로브의 생각입니다. 그는 메모리에서만 동작해 빠르고 재실행 가능한 것이 유닛 테스트라고 정의 하고 있습니다. 직접 데이터를 조작해서 원하는 결과가 이루어 지는 것은 통합 테스트의 과정이라고 말합니다. 그럼 위와 같이 실제 데이터를 조작하지 않고 테스트를 작성하기 위해 어떤 방식의 설계를 해야할까요? 인터페이스를 이용해 의존성을 주입하고 주입된 의존성 코드를 테스트에서 mock, stub등으로 바꾸어 오류 상황을 재현해보기도 하고 직접 데이터가 올바로 생성되고 삭제되고 조작되는지 확인해 볼 수 있습니다. 이러한 특징으로 interface를 사용해서 설계를 하면 코드가 모듈화 되고 그로인해 유지보수성도 올라간다는 특징이 있습니다 그럼 모든 곳에서 interface를 사용하면 아주 좋겠네요? 그게 또 그렇진 않습니다. interface를 사용하면 그만큼 복잡성이 올라가 실제로 어떤 클래스와 의존하고 있는지 찾기 힘듭니다. (장점이자 단점이 될 수 있겠네요) 그래서 동료들과 어떤 부분을 interface로 추상화 할 것인지 논의해 적절한 곳에 사용해야 합니다. 저의 부족한 경험에서 나온 글이지만 다른 분들께 도움이 되었으면 합니다. 다른 중요한 특징을 알고 계시거나 저보다 더 쉽게 설명하실 수 있는 분이 계시면 댓글로 제 부족한 글을 채워주시면 감사드리겠습니다. 감사합니다.
뭔가 조금 아쉽네요.. 왜 interface를 굳이 시간과 비용을 들여 사용하는지 아직 풀리지 않네요.. 사실 interface는 꾀 많이 사용되고, interface 설계를 함으로써 얻는 이점이 많은데, 단순히 영상만 보곤 매우 일부분만 사용할 것 같습니다. (그마저도 필요한지 의문이 듭니다.)
안녕하세요 !!님 우선 제 부족한 영상에 매우 건설적 댓글 달아주신 점 감사드립니다. 댓글을 읽고 저도 다시한번 제 영상을 보았습니다. 역시 써주신 것과 같이 설계에 초점을 맞춰서 보면 interface의 설계시 이점에 대해 많이 부족한 영상이 맞는 것 같습니다. 다만, 영상 제목에서도 볼 수 있듯이 interface를 이용해 다형성에 대해서 설명하고 싶었던 영상이라 그 부족함을 조금 이해해 주셨으면 합니다. 개인적인 관점으로 객체지향에서 다형성을 이해하고 훈련해야 올바른 설계를 할 수 있다고 생각하기 때문에 interface의 다양한 기능 중 다형성에만 대해 초점을 맞춰 영상을 제작했던 걸로 기억합니다. 다른 분들이 보실 수 있기에 interface를 이용해 얻을 수 있는 설계의 장점에 대해서 설명하겠습니다. 1. 구체적인 객체에 의존해서 구현하는 것이 아닌 추상화된 객체를 이용해 구현이 가능하다. interface의 개념은 초창기 Widnwos에도 있었습니다. Microsoft사는 자신의 소프트웨어에 다양한 I/O 객체를 손쉽게 접목시킬 수 있도록 모든 I/O 드라이버에 Read,Write,Open,Close,Seek 기능 구현을 강제 했고 이들은 모두 같은 함수 형태를 가지고 있어야 했습니다. (현재의 interface와 같은 기능이죠?) 그렇게 되면 Windows는 로지텍사의 키보드를 사용하든 Microsoft사의 키보드를 사용하던 상관없이 무조건 Read 함수를 호출하면 어떤 키보드인지 상관없이 값을 읽을 수 있게 하였습니다. 이러한 개념은 제가 만든 IEnumerable 관련 영상에서도 말씀드렸지만 IEnumerable을 구현하는 객체는 그 무엇이든 간에 객체를 열거 할 수 있는 것 등으로 .Net Framework안에 들어와 있습니다. interface를 사용하면 이런 것과 같이 구체 클래스가 아닌 그들이 가지고 있는 행동(함수)에 맞춰 개발을 할 수 있기 때문에 다양한 현실세계를 컴퓨터 안에서 일관되게 처리 할 수 있게 됩니다. 2. 객체간에 의존성을 없앨 수 있습니다. 의존성이란 설계에 아주 중요한 개념으로 객체가 어떻게 소통하는지 나타내는 것입니다. 설계를 구체 클래스에 하게 되면 객체간의 강한 의존성이 생기게 됩니다. 그래서 interface를 사용해서 return이나 parameter로 다른 객체와 소통하는 구간에 사용하면 의존성이 줄어들어 자신과 소통하는 객체의 변화에 강한 클래스를 만들 수 있게됩니다. 이런 의존성은 과거부터 있었던 많은 Framework에서 발전해 MVC, MVVM 패턴등으로도 승화 되었고 depedecny injection등의 기술이 사용됩니다. 관련해서 GOF의 디자인패턴이란 책을 보시면 다형성을 이용한 객체의 의존성을 관리하는 여러 패턴을 살펴보실 수 있을 것입니다. 이러한 특징으로 interface를 사용해서 설계를 하면 코드가 모듈화 되고 그로인해 유지보수성도 올라간다는 특징이 있습니다 그럼 모든 곳에서 interface를 사용하면 아주 좋겠네요? 그게 또 그렇진 않습니다. interface를 사용하면 그만큼 복잡성이 올라가 실제로 어떤 클래스와 의존하고 있는지 찾기 힘듭니다. (장점이자 단점이 될 수 있겠네요) 그래서 동료들과 어떤 부분을 interface로 추상화 할 것인지 논의해 적절한 곳에 사용해야 합니다. 감사합니다.
![[C# 중급] C# 인터페이스 기초](http://i.ytimg.com/vi/FcAnZ4emM4s/mqdefault.jpg)
![[C#]델리게이트의 모든 것(All about delegate)](/img/n.gif)
설명을 너무 잘해주셔서 놀라워요!! 다른 영상도 보고 있는데 좋은 강의 많이 올려주시면 정말 감사합니다!!
좋게 봐주셔서 감사합니다!!!! 영상 많이 올리고 싶은데 쉽지 않네요!! 댓글 감사합니다!
쉽게 생각해서 다형성 이란 -> 인터페이스 혹은 클래스를 상속받으면 상속받은 클래스들은 타입이 부모 클래스가 "되기 때문에" 한 타입으로 묶어서 정의 가능함.
또한 부모 클래스에 있는 메서드를 사용가능하다. 즉 자바는 어떤 타입이냐에 따라 다르기 때문에. 인터페이스의 경우 불릿 포인트와 캐릭터 포인트를 상속 해줬고
불릿 포인트의 타입은 인터페이스 캐릭터 포인트의 타입도 역시 인터페이스 둘 타입은 인터페이스 타입이기 때문에 매개변수에 타입을 인터페이스로 넣어도 오류가 뜨지 않는다.
네! 달아주신 댓글로 보았을 때 이해하고 계신게 맞아 보입니다. 컴파일러는 프로그래머가 작성한 클래스 내부를 비교해서 같음을 비교하지 않습니다. 그저 타입을 가지고 같음을 비교합니다. 사용자 정의 클래스에서 공통부분을 설정하기 위해선 인터페이스 등을 사용해서 다형성을 컴파일러에게 알려줘야 합니다! 질문 있으시면 언제든지 해주셔도 됩니다~~!!
영상 잘 봤습니다.
한가지 객체가 여러 타입에 대입하게 만드는거를 다형성, 한가지 객체가 한가지 타입에 대입하는거는 단혀성 이다.
이렇게 다형성을 작업을 할수있게 인터페이스를 만들거나 추상 클래스 또는 일반 클래스를 만들어서 공통 프로퍼티들을 뽑아서 정의하는거를 추상화 작업
추상화 작업이라고 하는 이유는 메서드 또는 메서드의 파라미터 타입, 반환 타입을 지정해주고 내부 로직은 오버라이딩을 하든 뭐를 하든 신경안쓰기 때문 맞을까요?
추상화란 단어에 의미를 여쭤보신 것 맞으시죠?
지금 설명해주신 추상화란 단어의 의미는 좀 틀린 것 같아요 제가 한번 설명해드리겠습니다!
추상화란 서로 다른 객체들이 공통적으로 갖고있는 특성을 모은 것이라고 생각하시면 됩니다.
이해가 바로 안되실 것 같아 몇 가지 예를 들어드리겠습니다
1. 강아지, 앵무새, 고양이, 코끼리 등은 모두 다른 동물이만 동물의 특성 중 하나인 울음소리를 갖는다는 특징이 있습니다. 이럴경우 강아지, 앵무새, 고양이, 코끼리 객체가 가지고 있는 공통 특성인 운다()라는 함수를 갖는 일반 클래스나 추상 클래스나 인터페이스등을 만들어서 울수있는 것들에 대한 추상화를 할 수 있을 것입니다. 당연히 이렇게 되면 동물 객체들을 다루는 로직에서 운다()를 추상화하고있는 인터페이스등을 가지고 다형하게 프로그래밍할 수 있을 것입니다.
2. 네이버페이, 카카오페이, 페이코 등의 결제수단들은 아마 결제(), 환불()이란 이름의 함수로 추상화할 수 있을 것입니다.
왜냐하면 앞서 말씀드린 결제수단들은 모두 결제를 할 수 있고 그에 따른 환불도 할 수 있을 것이기 때문입니다. 이렇게 추상화 해놓고 다형성있게 로직을 작성해 놓으면 영상에서 말씀 드린 것 처럼 다른 결제 수단의 추가에 따른 코드 변경이 없어질 수 있습니다. 이런 것을 개방 폐쇄 원칙 (OCP)라고 하는데 이 부분에 대해선 한번 찾아보시면 좋을 것 같습니다.
조금 어려운 말로 정리를 한다면 세상에 있는 다양한 문제를 컴퓨터 안에서 일반되게 처리할 수 있도록 공통문보를 추출하는 것을 추상화라고 생각하시면 될 것 같습니다.
다른 질문 있으시면 편안하게 댓글로 질문 주시면 최대한 답변 드리겠습니다.
감사합니다!
좋은강의 감사합니다 질문이있는데
조상class a=자손class b
같은경우 말씀하신것처럼 a에는 b의 필수요소가 있으니까 a와 b에서 구현한건 쓸수있다. 는 알겠습니다만
반대로 자손class b = (자손class) 조상a
이 경우에 왜 이렇게쓰는지 멤버개수를 맞추려고 한다는데 그냥 조상 class a 를 new연산자로 받아와서 쓰면되는게아닌가요?ㅠ 이해가잘안갑니다
안녕하세요! 좋은 질문입니다. 언제든지 이해가 안가시는게 있으시면 말씀 주세요!
'자손class b = (자손class) 조상a' 과 같이 사용하는 경우는 이미 '조상a', '조상b', '조상c'가 만들어진 상황에서
그 각각의 객체를 '자손class'로 받아서 처리하게 되면 기능이 추가될 때 마다 코드를 변경하지 않아도 되는 코드가 되기 때문입니다. 이러한 이유로 인터페이스를 사용하고 이런 것을 객체지향에서는 OCP라고 부르는데 이쪽을 좀 더 공부해보시면 좋을 것도 같습니다.
제 영상 ua-cam.com/video/TnvfaFNuF9U/v-deo.html 14분 정도부터 보시면 히드라리스크라는 클래스를 추가하면서 그 예를 설명드리고 있으니 한번 확인해보시면 좋을 것 같습니다.
혹시 제 답변 중에 이해가 안되시는 부분이 있으시면 언제든지 댓글 달아주시기 바랍니다.
감사합니다!
자료형이 프로모션하는 연산에서 유용할지도 ㅋ
안녕하세요~! 혹시 프로모션하는 연산이란게 어떤건지알 수 있을까요?
@@User_Masuri 저렇게 써 놓으니 뭔가 대단한 듯이 보이네요 ㅋ 그냥 가령 정수형에서 실수형이라던가 8비트 자료형이 16비트 자료형으로 변환해야 하는 상황에서도 함수를 바꾸는 고려하지 않고 쓸 수 있을 것 같다는 뜻
인터페이스란 서로다른 클래스들의 최대 공약수 같은 느낌이군요. (서로다른 클래스들의 공통된 특징들을 보장하는)
강의 진짜 명료합니다. 오늘도 인터페이스고자탈출.
여기서 질문한가지만 남기자면.. 같은 타입의 변수와 변수명 (int x, int y)를 가져도 클래스 명이 다르면 컴파일러는 이를 서로 다른것으로 인식하잖아요?
이는 메모리 상의 위치가 초기 선언시에 달라서 그런건지.. 그 root cause(근본 원인)이 어디 있는건가요?
인터페이스를 보고 최대 공약수를 생각하신거라면 정말 제대로 이해하고 계신겁니다!
근래에 들었던 표현 중 가장 멋있는 표현이네요!
최대 공약수로 표현하신 것을 소프트웨어 공학적으로 표현하자면 데이터를 '추상화' 했다고 표현할 수 있습니다!
'추상화'라는 것은 모든 설계와 많은 기술의 근간이 되는 아주 중요한 개념입니다
인터페이스를 자주 사용하시다보면 자연스럽게 관심을 가지게 되실겁니다.
주신 질문은 너무 당연하게 생각을 해서 한번도 생각해본적이 없는 내용의 질문이네요
여러모로 찾아보았지만 올바른 답을 찾기 쉽지 않았습니다!
저도 다른 곳에 질문을 통해 답을 얻어보도록 하겠습니다! ㅜㅜ
감사합니다
안녕하세요 안영훈님 마수리입니다!
주신 질문에 대한 대답을 얻어 댓글 답니다! 부디 원하시는 대답이 되셨으면 합니다
결론은 클래스의 '이름' 자체가 식별자기기 때문입니다!
클래스의 이름은 각 타입 간의 차이를 식별하는데 사용하는 기본 식별자입니다.
그래서 우리는 그 식별자 겹치게 설계할 수 없으며 네임스페이스를 이용해서
식별자(이름)이 같더라도 서로 식별할 수 있게 하는 겁니다!
@@User_Masuri길고 정성담긴 답변 너무나 감사합니다 ^^
추상화가 그런 의미얐군요 하나 더 배우고 갑니다!
강제로 이해 시키시네요. 감사드립니돠.
강제로 이해라.. ㅋㅋ 참 참신한 칭찬이십니다. 감사합니다!
덕분에 이해가 되었네요.. 나름 인터페이스를 왜 쓰이는가에 대해 고민하던 중 영상을 보고 어떠한 기능을 여러 객체들이 돌려쓰기 위해 구현되는거라 정리 되었습니다.
안녕하세요!! '여러 객체들이 돌려쓰기 위해'는 다형성으로 표현될 수 있을 것 같네요
다형성에 대해서 실질적 예제를 보면 도움이 되실 것 같습니다
감사합니다
진짜 좋은 설명입니다. 아주 이해가 잘 되었습니다. 감사합니다.
감사합니다!!
제가 알고있던 다형성을 다른 관점에서 설명해주셔서 좋았습니다!
안녕하세요~ 좋은 질문이 있어 그에 관한 답을 편집해 하이라이트로 남깁니다. 필요하신 분은 읽어보시면 좋겠다고 생각합니다~
다른 분들이 보실 수 있기에 interface를 이용해 얻을 수 있는 설계의 장점에 대해서 설명하겠습니다.
1. 구체적인 객체에 의존해서 구현하는 것이 아닌 추상화된 객체를 이용해 구현이 가능하다.
interface의 개념은 초창기 Widnwos에도 있었습니다. Microsoft사는 자신의 소프트웨어에 다양한 I/O 객체를 손쉽게 접목시킬 수 있도록
모든 I/O 드라이버에 Read,Write,Open,Close,Seek 기능 구현을 강제 했고 이들은 모두 같은 함수 형태를 가지고 있어야 했습니다. (현재의 interface와 같은 기능이죠?)
그렇게 되면 Windows는 로지텍사의 키보드를 사용하든 Microsoft사의 키보드를 사용하던 상관없이 무조건 Read 함수를 호출하면
어떤 키보드인지 상관없이 값을 읽을 수 있게 하였습니다.
이러한 개념은 제가 만든 IEnumerable 관련 영상에서도 말씀드렸지만 IEnumerable을 구현하는 객체는 그 무엇이든 간에
객체를 열거 할 수 있는 것 등으로 .Net Framework안에 들어와 있습니다. interface를 사용하면 이런 것과 같이
구체 클래스가 아닌 그들이 가지고 있는 행동(함수)에 맞춰 개발을 할 수 있기 때문에 다양한 현실세계를 컴퓨터 안에서 일관되게 처리 할 수 있게 됩니다.
2. 객체간에 의존성을 없앨 수 있습니다.
의존성이란 설계에 아주 중요한 개념으로 객체가 어떻게 소통하는지 나타내는 것입니다.
설계를 구체 클래스에 하게 되면 객체간의 강한 의존성이 생기게 됩니다.
그래서 interface를 사용해서 return이나 parameter로 다른 객체와 소통하는 구간에 사용하면
의존성이 줄어들어 자신과 소통하는 객체의 변화에 강한 클래스를 만들 수 있게됩니다.
이런 의존성은 과거부터 있었던 많은 Framework에서 발전해 MVC, MVVM 패턴등으로도 승화 되었고
depedecny injection등의 기술이 사용됩니다. 관련해서 GOF의 디자인패턴이란 책을 보시면
다형성을 이용한 객체의 의존성을 관리하는 여러 패턴을 살펴보실 수 있을 것입니다.
[추가]
3. 단위 테스트 가능한 코드를 만들 수 있다
테스트 가능한 코드를 만드는 것은 객체지향 적 사고를 품는 설계의 방식을 필요합니다.
테스트 가능하도록 설계하지 않은 코드는 아예 단위 테스트가 불가능 하거나
직접 데이터를 조작하고 지우는 방법의 테스트를 진행해야 합니다.
하지만 여기서 주목해야 할 부분은 ".Net 예제로 배우는 단위 테스트"의 저자 로이 오셔로브의 생각입니다.
그는 메모리에서만 동작해 빠르고 재실행 가능한 것이 유닛 테스트라고 정의 하고 있습니다.
직접 데이터를 조작해서 원하는 결과가 이루어 지는 것은 통합 테스트의 과정이라고 말합니다.
그럼 위와 같이 실제 데이터를 조작하지 않고 테스트를 작성하기 위해 어떤 방식의 설계를 해야할까요?
인터페이스를 이용해 의존성을 주입하고 주입된 의존성 코드를 테스트에서 mock, stub등으로 바꾸어
오류 상황을 재현해보기도 하고 직접 데이터가 올바로 생성되고 삭제되고 조작되는지 확인해 볼 수 있습니다.
이러한 특징으로 interface를 사용해서 설계를 하면 코드가 모듈화 되고 그로인해 유지보수성도 올라간다는 특징이 있습니다
그럼 모든 곳에서 interface를 사용하면 아주 좋겠네요? 그게 또 그렇진 않습니다.
interface를 사용하면 그만큼 복잡성이 올라가 실제로 어떤 클래스와 의존하고 있는지 찾기 힘듭니다. (장점이자 단점이 될 수 있겠네요)
그래서 동료들과 어떤 부분을 interface로 추상화 할 것인지 논의해 적절한 곳에 사용해야 합니다.
저의 부족한 경험에서 나온 글이지만 다른 분들께 도움이 되었으면 합니다.
다른 중요한 특징을 알고 계시거나 저보다 더 쉽게 설명하실 수 있는 분이 계시면 댓글로 제 부족한 글을 채워주시면 감사드리겠습니다.
감사합니다.
뭔가 조금 아쉽네요.. 왜 interface를 굳이 시간과 비용을 들여 사용하는지 아직 풀리지 않네요..
사실 interface는 꾀 많이 사용되고, interface 설계를 함으로써 얻는 이점이 많은데, 단순히 영상만 보곤 매우 일부분만 사용할 것 같습니다. (그마저도 필요한지 의문이 듭니다.)
안녕하세요 !!님 우선 제 부족한 영상에 매우 건설적 댓글 달아주신 점 감사드립니다.
댓글을 읽고 저도 다시한번 제 영상을 보았습니다.
역시 써주신 것과 같이 설계에 초점을 맞춰서 보면 interface의 설계시 이점에 대해 많이 부족한 영상이 맞는 것 같습니다.
다만, 영상 제목에서도 볼 수 있듯이 interface를 이용해 다형성에 대해서 설명하고 싶었던 영상이라 그 부족함을 조금 이해해 주셨으면 합니다.
개인적인 관점으로 객체지향에서 다형성을 이해하고 훈련해야 올바른 설계를 할 수 있다고 생각하기 때문에 interface의 다양한 기능 중
다형성에만 대해 초점을 맞춰 영상을 제작했던 걸로 기억합니다.
다른 분들이 보실 수 있기에 interface를 이용해 얻을 수 있는 설계의 장점에 대해서 설명하겠습니다.
1. 구체적인 객체에 의존해서 구현하는 것이 아닌 추상화된 객체를 이용해 구현이 가능하다.
interface의 개념은 초창기 Widnwos에도 있었습니다. Microsoft사는 자신의 소프트웨어에 다양한 I/O 객체를 손쉽게 접목시킬 수 있도록
모든 I/O 드라이버에 Read,Write,Open,Close,Seek 기능 구현을 강제 했고 이들은 모두 같은 함수 형태를 가지고 있어야 했습니다. (현재의 interface와 같은 기능이죠?)
그렇게 되면 Windows는 로지텍사의 키보드를 사용하든 Microsoft사의 키보드를 사용하던 상관없이 무조건 Read 함수를 호출하면
어떤 키보드인지 상관없이 값을 읽을 수 있게 하였습니다.
이러한 개념은 제가 만든 IEnumerable 관련 영상에서도 말씀드렸지만 IEnumerable을 구현하는 객체는 그 무엇이든 간에
객체를 열거 할 수 있는 것 등으로 .Net Framework안에 들어와 있습니다. interface를 사용하면 이런 것과 같이
구체 클래스가 아닌 그들이 가지고 있는 행동(함수)에 맞춰 개발을 할 수 있기 때문에 다양한 현실세계를 컴퓨터 안에서 일관되게 처리 할 수 있게 됩니다.
2. 객체간에 의존성을 없앨 수 있습니다.
의존성이란 설계에 아주 중요한 개념으로 객체가 어떻게 소통하는지 나타내는 것입니다.
설계를 구체 클래스에 하게 되면 객체간의 강한 의존성이 생기게 됩니다.
그래서 interface를 사용해서 return이나 parameter로 다른 객체와 소통하는 구간에 사용하면
의존성이 줄어들어 자신과 소통하는 객체의 변화에 강한 클래스를 만들 수 있게됩니다.
이런 의존성은 과거부터 있었던 많은 Framework에서 발전해 MVC, MVVM 패턴등으로도 승화 되었고
depedecny injection등의 기술이 사용됩니다. 관련해서 GOF의 디자인패턴이란 책을 보시면
다형성을 이용한 객체의 의존성을 관리하는 여러 패턴을 살펴보실 수 있을 것입니다.
이러한 특징으로 interface를 사용해서 설계를 하면 코드가 모듈화 되고 그로인해 유지보수성도 올라간다는 특징이 있습니다
그럼 모든 곳에서 interface를 사용하면 아주 좋겠네요? 그게 또 그렇진 않습니다.
interface를 사용하면 그만큼 복잡성이 올라가 실제로 어떤 클래스와 의존하고 있는지 찾기 힘듭니다. (장점이자 단점이 될 수 있겠네요)
그래서 동료들과 어떤 부분을 interface로 추상화 할 것인지 논의해 적절한 곳에 사용해야 합니다.
감사합니다.
안보여요ㅠㅠ
앞으로 촬영시! 어떠한 환경에서도 잘 보일 수 있게 촬영하도록 하겠습니다!! ㅠㅠ
감사합니다~