예제로 살펴보는 솔리드 원칙
2024 ж. 25 Нау.
38 336 Рет қаралды
객체지향프로그래밍의 핵심인 솔리드원칙입니다.
유니티 E-BOOK에도 동일한 내용이 나와있습니다.
블로그 글은 한글이지만 e-book은 영어입니다. 아래 링크 참고하세요.
blog.unity.com/kr/games/level...
맴버십 회원 중 2단계 이상이신 분들은,
한글로 정리된 노션 문서 링크를 커뮤니티에서 확인하실 수 있습니다.
채널에 가입하여 혜택을 누려보세요.
/ @today_coding
-------------------------------------------------------------------------------
에셋스토어 링크:
assetstore.unity.com/?aid=101...
Unity Plus:
prf.hn/click/camref:1011lvz7i...
Unity Pro:
prf.hn/click/camref:1011lvz7i...
Unity 프리미엄 학습:
prf.hn/click/camref:1011lvz7i...
Unity 파트너 과정:
prf.hn/click/camref:1011lvz7i...
문의 및 이메일 : devtodaycoding@gmail.com
유니티로 게임 개발을 할 때 객체지향 프로그래밍은 너무 중요하고, 그 핵심이 되는 솔리드 원칙에 관한 영상입니다. 자세한 사항은 영상설명을 참고해주세요.
제가 얼마나 촛같이 코드를 짜고 있었는지 이해가 바로 되네요 ㅋㅋ
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
야 너듀?! 나듀
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ어?...어??ㅋㅋㅋㅋㅋㅋ저도 ㅋㅋㅋㅋㅋㅋㅋ
ㄹㅇㅋㅋㅋ
와 드디어 나왔다!! 진짜 기다렸어요 ㅠㅠ 오늘코딩 증말 사랑합니다
설명도 좋은데 목소리까지 좋으셔서 귀에 쏙쏙 박힙니다. 늘 도움 받고 있습니다. 감사합니다.
잘봤습니다!!! 머리가 띵햇네요 여러번 다시 봐야겠습니댜
앞으로 계속 염두에 두고 배워가야겠습니다. 잘봤습니다. 감사합니다!
오늘도 좋은 영상 감사합니다. 객체 지향 법칙에 대해서 잘 알게 되었습니다. 스스로 공부해보면서 코드에 적용해보아야겠습니다.
필수적인 내용들을 쉽게 풀어서 설명해주셔서 감사합니다😊
이해하기 쉽게 영상 만들어주셔서 감사합니다. 😊
안그래도 e book 번역해서 봐야지 하고 있었는데 이렇게 영상이 나오다니 아주 감사합니다
신입때 이거 이해 하느라 진짜 힘들었는데.. 신입들에게 정말 좋은 영상이네요 감사합니다
내부 스터디 자료 만들다가 오늘 봤던 내용인데 신기하게 영상이 올라와서 반가웠습니다!! ㅋㅋ
와 민바크님 댓글감사합니다 ㅎㅎ 화이팅입니다!!
헐 딱 어제 밤에 정처기 공부하면서 SOLID 원칙을 외우게됐는데 때마침 이런 영상이라니요! 실제로는 어떻게 적용되는것인지 이해가 잘됐어요! 게임 프로그래머 꿈꾸는 제 입장에서 많은 도움이 되었습니다 ㅎㅎ 감사합니다
좋은내용 배우고 갑니다. 감사합니다.
감사합니다. 영상에 나온거 적용해가면서 공부해보려고합니다 ㅎㅎ
훌륭한 강의영상 감사합니다!
감사합니다, 엄청난 도움이 됐습니다!
설명 잘들었습니다!!
쉽게 이해할 수 있게 예시가 있어 좋네요!
복습하게 해주셔서 감사합니다.
아주 쉽게 설명 감사합니다
인터페이스 사용이 막연했는데 이 영상덕분에 어떻게 사용할지 감이 잡힌거 같아요ㅎㅎ 감사합니다!
좋은영상감사합니다
제가 게임만들면서 코딩하는데 몇가지는 지키고 잇었네요. 안지키고 있었던것들을 보니 제가 예전에 고민하면서 말해주신 방향성으로 고쳐보려다가 실패한 경험이 있네요. 예시덕에 경험에 빗대어 앞으로는 더 능숙하게 코드를 짤수 있을것같습니다. 감사합니다!
너무 알차군요 구독할수밖에 없습니다ㅏ
역시 설명을... 👍
귀한영상
잘 봣습니다. 개발을 업으로 삼으로면 꼭 보고 숙지해야 할거 같네요.
드디어..!
훌륭한 영상입니다 이걸 아는 사람은 많이 보앗지만 지키는 개발자는 정말 못봣다고 할 정도로 적은거같네요 물론..대부분 기존소스로 고도화를 하다보니 한계가 있긴하지만 아에 모르는 사람은 꼭 이 영상을 시청하면 좋을것같습니다 저희 회사 신입에게 프로젝트할때만 말로 설명하는데 이 영상을 참조하는것도 좋을것같네요 감사합니다
LSP 원칙을 잘 지켜 타입 계층이 만들어지면 OCP 원칙도 자연스레 지켜지게 되겠네요.
와 알차다
SRP에서 컴포넌트 패턴을 예시로 들어주셨는데요. 그렇다면, 컴포넌트간에 통신이 필요한 경우(ex. InputComp로 입력을 받았으니 MoveComp를 통해 움직여야한다 or MoveComp가 움직였으니 AudioComp에서 소리를 재생해야한다)가 생긴다면 어떻게 처리하는게 가장 좋나요? 1. 리플렉션 기능으로 InputComp에서 MoveComp를 가져와서 움직인다 -> 이건 근데 의존성이 너무 높은 것 같네요 2. Character 클래스에 중간 다리가 되어주는 함수를 작성한다. 3. MoveComp와 중간 다리가 되어주는 함수를 인터페이스로 뺀 뒤 Character 클래스가 상속받아 구현 후 호출한다. 등등 물론 상황에 따라 모두 사용할 수 있지만 오늘 코딩님의 의견이 궁금합니다.
의존성이 생기는 순간 각 컴포넌트가 별개로 작동할 수 없기 때문에, 제3의 클래스를 만들어서 사용하는 것이 바람직할 것입니다. 예를 들면 말씀하신 ”움직이면 소리 재생“을 구현할 때 1. MoveComp에서 움직일 때 Event를 Publish하기 2. AudioComp에서 소리를 재생시킬 수 있는 함수를 public으로 선언 3. 제3의 클래스인 PlayAudioOnMove는 MoveComp의 Event에 Subscribe해서 AudioComp 함수 호출 이 방식으로 작성하면 움직임이 생길 때 다른 액션을 취하는 클래스를 새로 작성하기 쉽습니다. (Open Closed Principle) 이벤트 작동 방식은 UniRx처럼 Reactive하게 쓰거나 ScriptableObject로 중간다리를 놓을 수도 있겠네요.
@@jeongjehoon2 헛 부끄럽지만 UniRx를 처음 들어서 검색해봤네요 알게 해주셔서 감사합니다. 이런게 있었군요 기존의 EventHandler만 사용하고있었네요...
(ex. InputComp로 입력을 받았으니 MoveComp를 통해 움직여야한다 or MoveComp가 움직였으니 AudioComp에서 소리를 재생해야한다) => 객체 지향의 메세징(Messaging)을 통신으로 표현하신 듯 합니다. 객체는 메시지를 주고 받으며 상호 작용하는데, 객체가 수신할 수 있는 메시지와 그 메시지를 처리하는 수단을 메서드(Method)라고 부릅니다. 즉, 객체 사이의 통신은 곧 메서드의 호출을 의미합니다. 질문의 요지는 이 메시지를 통한 상호작용의 연결고리를 어떻게 이을 것인가에 관한 것같아 보입니다. 입력의 상태 변화를 읽은 방법은 크게 폴링(Polling)과 이벤트(혹은 인터럽트)가 있습니다. 콘솔 앱처럼 기반 인프라 없는 경우 프로그래머의 성향에 따라 이 둘 중에 하나를 선택할 수 있지만, 대부분의 프레임워크는 이벤트를 제공하기에 이를 이용하는 것이 간편하거나 유일한 선택지일 수 있습니다. InputComp 는 시스템의 입력을 읽어 버릴 것은 버리고, 의미 있는 값을 - 예를 들면, Movement 로 만들어 이벤트에 실어 보내도록 설계할 수 있습니다. 이 이벤트의 처리자는 전달 받은 Movement 객체를 이용하여, Point Character.Move(Movement movement)와 void AudioPlayer.Play(Movement movement)를 호출하도록 연결할 수 있을 것 같습니다. void MoveInputHandler(object? s, Movement movement) { var newPoint = _character.Move(movement); CharacterX = newPoint.X; CharacterY = newPoint.Y; _audioPlayer.Play(movement); // _audioPlayer.Play(movement, newPoint); }
@@user-xo6in3yr5t EventHandler처럼 단순히 데이터를 주고받기보다 이벤트로 받은 값 A를 B로 변환하고, 그 중 조건에 맞는 C만 얻어내고, 다시 D로 변환하는 등 원하는 형태로 데이터를 Stream의 형태로 바꿀 수 있는게 큰 장점같아요!
오... 역시 유튜브 알고리즘이야
알 차다
👍
혹시 c++강의가 따로 있을까요?
SRP부터 내용이 잘못되었네요. 클린아키텍처에서 엉클밥이 ‘책임’ 에 대해서 사람들이 오해하고 있다고 직접 서술한 부분이 있습니다. 기능 단위의 책임이 아니라 액터에 대한 책임으로 보아야 원래 의미상 맞습니다.
와.. 목소리 지렸....
이론상으로는 이해를 잘 했는데 이걸 실제로 적용하고 개발하다 보면 애매하게 헷갈리는 경우가 생길 것 같음..
기본중에 기본인것들이네요. 웹 프로그램밍을 하든 윈도우 프로그래밍을 하든 저런 기본적인것들만 잘 지켜도 유지보수 하기 쉬워지죠
알차다 오코..b
너무너무 예쁘다고 해도 너를 떠올리며 거절했지만 이번 한번뿐이라는 걸 맹세해
오 이렇게 쉬운 예제가 있다니
감사합니다!! ㅎㅎ
단일 책임 원칙은 하나의 클래스는 하나의 기능을 가져야 한다는 것이 아닙니다. 클래스의 코드가 수정되어야 할 이유는 하나여야 한다는 원칙입니다.
말이 아다르고 어다른 느낌이네요 결국 클래스의 목적?이 있으면 그것과 관련된 여러기능이 있어도 수정을 할땐 그 목적인 하나의 이유라면 괜찮다 이렇게 이해하면 될까요?
어떠한 기능이 문제가 생겨서 수정해야할때 그 클래스만 수정할 수 있다면 ㅇㅋ입니다
그 하나의 이유가 클래스가 맡은 기능을 수행하는 방식이 변경되는 경우를 의미입니다.
단일책임원칙이 잘못 설명되었습니다 단일책임 원칙에서의 책임은 객체의 책임을 의미하지 않습니다
내가 얼마나 코드를 대충짜고있었는지 느껴진다 내가 하고있던건 객체지향이 아니라 절차지향이였구나
단일책임과 단일기능은 다른거 아닙니까?
😮😮
김조한이 부릅니다 "이 밤에 끄츨 좝고 있눈 나에 코드가 더 이상 쵸롸하지 안케에에"
게임 개발시에 더 중요한 이유가 있나요?
거의 모든 프로그래밍에 필요한 개념이긴 합니다. 저기에 모든 원칙을 항상 따르지 않아도 좋은 프로그램을 만들 수는 있지만 개발을 더 진행하면서 막히는 부분이 분명히 찾아옵니다. 그래서 게임개발에만 중요하진 않고 거의 모든 개발에 중요하다고 생각되네요
게임 개발이 가장 규모가 크고 복잡해서 그렇지 않을까요? 사실상 웹개발이 구조가 가장 간단하니까요
예제로 살펴보는 솔리드 원칙
인터페이스는 아무런 기능을 가지지 않았는데 왜 써야하는건지… 인터페이스는 아무리 들어도 이해가 안가네요 ㅠㅠ 몇년째 그냥 그렇구나 하는중..
같은 클래스를 상속받아 만들지만 서로 다른 기능이 추가로 필요할 때, 서로 다른 클래스지만 같은 기능이 필요할 때 정도만 보시면 될 거에요 예를 들어 일부 캐릭터나 일부 탈 것에 공격 기능이 필요하다면 attack이라는 함수를 작성해둔 iattackable이라는 인터페이스를 붙이는 거죠
인터페이스를 작성할 일이 없었다면, 그건 아마도 Bottom-Up 방식으로 코드를 작성해왔기 때문일 것입니다. Bottom-Up 방식은 의존객체를 먼저 작성(구현)하고, 클라이언트 객체를 나중에 작성(구현)하는 것 혹은 둘을 동시에 구현하는 것입니다. 이와 반대로, 클라이언트 객체를 먼저 구현하고 의존 객체의 구현을 미루는 Top-Down 방식으로 코드를 작성한다면, 인터페이스의 사용 비율이 많이 올라갈 것입니다. 예를 들어, 클라이언트의 임무 중 하나를 아래와 같이 인터페이스에 의존하도록 정의하면, 워커 객체의 구현이 없어도, 클라이언트의 구현을 마감할 수 있습니다.(문제 없이 빌드할 수 있습니다.) void MyJob(IWorker worker) => _myState = worker.Do(); 반대로 워커를 클래스로 정의하면, void MyJob(Worker worker) => _myState = worker.Do(); Worker.Do()를 구현하기 전에는 클라이언트 코드를 마감할 수 없습니다. (빌드할 수 없습니다) "의존 객체의 구현을 미룬다"는 의미를 명확하게 이해하려면, 클라이언트는 본인이 작성하고, 워커는 동료가 작성한다고 가정해보면 됩니다. class 로 정의하는 경우, 둘의 업무 마감은 서로에게 강하게 결합되지만, 인터페이스로 정의한다면, 그런 일이 발생하지 않습니다.
영상의 말처럼 느슨한 결합이 중요한 사용목적입니다. 일반 class로 선언할 경우, 당장은 소스량이 적어보이지만 해당 객체들을 확장시켜야할 경우 소스상 각 class별 예외처리가 필요하게되어 소스가 무진장 늘어나지만 동일한 interface를 기반으로 만들어진 class들을 확장시킨다면 기존 소스상에서는 interface기반으로 동일동작을 제공하기에 기존 소스를 수정없이 유지시킬수 있습니다. 다른 중요목적중 하나로는 API 제공간 관리범위 밖에 타 모듈, 개발side에 실제 구현요소를 공개하지 않고 기능만을 제공하기 위한 목적도 있구요. 또한 개발단계에서 설계 및 정책을 interface로 제한시켜 주기 위한 목적도 있습니다.
단일 책임원칙과 개방폐쇄 원칙을 보면서 드는 궁금점이 5각형 클래스가 shape 을 상속받아 면적을 계산하는 함수를 오버라이드 하고 5각형 클래스 안에 5강형의 면적을 계산하는 메서드를 구현하면 다시 단일책임 원칙을 위배하는 것 아닌가요?
01:45 부분에 상속하여 확장하기에 용이하다는 점으로 볼 때 오히려 단일 책임 원칙의 이점으로 볼 수 있을 것 같아요. Shape가 단일기능이었기에 각각의 다각형의 면적 계산(확장된 기능)을 적용할 수 있다는 말로 전 이해했습니다.
디자인 패턴도 다루실 예정인가요?
다룰 생각은 항상 있는데 언제 업로드 할 수 있을 지는 모르겠습니다