5:38 Health같은걸 Inspector에서 설정할 수 없어서 상속받은 컴포넌트에서 추가로 _health 변수 작성해서 Start에서 Health = _health 해야 하던데 이러면 변수를 지정하는 이유가 있나요? 그리고 제가 배울때는 인터페이스가 상수 용도라고 했었는데 c#은 다른가요?
훌륭한 영상입니다 이걸 아는 사람은 많이 보앗지만 지키는 개발자는 정말 못봣다고 할 정도로 적은거같네요 물론..대부분 기존소스로 고도화를 하다보니 한계가 있긴하지만 아에 모르는 사람은 꼭 이 영상을 시청하면 좋을것같습니다 저희 회사 신입에게 프로젝트할때만 말로 설명하는데 이 영상을 참조하는것도 좋을것같네요 감사합니다
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로 중간다리를 놓을 수도 있겠네요.
(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); }
문법 알고 API 좀 더 아는게 중요한게 아니라 이런걸 잘 지키는게 실제 코드의 지속성, 안전성, 유지보수성에 가장 중요한데. 신입급은 말할것도 없고 경력 좀 있다는 개발자도 이걸 잘 못지키네요. 더욱 답답한건 본인들이 코드에 똥 싸놓은걸 다른 이들이 피해를 보는데 정작 본인이 멀 잘못 했는지도 모름...
![[구버전, 고정댓글 필독!!] 객체지향 프로그래밍이 뭔가요?](http://i.ytimg.com/vi/vrhIxBWSJ04/mqdefault.jpg)
유니티로 게임 개발을 할 때 객체지향 프로그래밍은 너무 중요하고, 그 핵심이 되는 솔리드 원칙에 관한 영상입니다.
자세한 사항은 영상설명을 참고해주세요.
제가 얼마나 촛같이 코드를 짜고 있었는지 이해가 바로 되네요 ㅋㅋ
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
야 너듀?! 나듀
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ어?...어??ㅋㅋㅋㅋㅋㅋ저도 ㅋㅋㅋㅋㅋㅋㅋ
ㄹㅇㅋㅋㅋ
이렇게 이론적으로 계속 듣더라도 처음 배울때는 이게 무슨 소린가 싶을건데, 뭐든 계속 만들어보고 이런 개념들을 계속 적용시키려고 노력하다 보면 언제부턴가는 사고방식 자체가 바뀌더라구요.
SRP부터 내용이 잘못되었네요. 클린아키텍처에서 엉클밥이 ‘책임’ 에 대해서 사람들이 오해하고 있다고 직접 서술한 부분이 있습니다. 기능 단위의 책임이 아니라 액터에 대한 책임으로 보아야 원래 의미상 맞습니다.
안그래도 e book 번역해서 봐야지 하고 있었는데 이렇게 영상이 나오다니 아주 감사합니다
제가 게임만들면서 코딩하는데 몇가지는 지키고 잇었네요. 안지키고 있었던것들을 보니 제가 예전에 고민하면서 말해주신 방향성으로 고쳐보려다가 실패한 경험이 있네요. 예시덕에 경험에 빗대어 앞으로는 더 능숙하게 코드를 짤수 있을것같습니다. 감사합니다!
신입때 이거 이해 하느라 진짜 힘들었는데.. 신입들에게 정말 좋은 영상이네요 감사합니다
1:38 여기서 다른 경우도 있어요. 예로 간단한 걸 늘어쓰면 보기 불편한데. 한 줄로 표현하면 간단하거든요. 6개 나올 걸 12개로 늘어 쓸 이유는 없잖아요.
잘 봣습니다. 개발을 업으로 삼으로면 꼭 보고 숙지해야 할거 같네요.
내부 스터디 자료 만들다가 오늘 봤던 내용인데
신기하게 영상이 올라와서 반가웠습니다!! ㅋㅋ
와 민바크님 댓글감사합니다 ㅎㅎ 화이팅입니다!!
좋은내용 배우고 갑니다. 감사합니다.
헐 딱 어제 밤에 정처기 공부하면서 SOLID 원칙을 외우게됐는데 때마침 이런 영상이라니요! 실제로는 어떻게 적용되는것인지 이해가 잘됐어요! 게임 프로그래머 꿈꾸는 제 입장에서 많은 도움이 되었습니다 ㅎㅎ 감사합니다
감사합니다. 영상에 나온거 적용해가면서 공부해보려고합니다 ㅎㅎ
5:38 Health같은걸 Inspector에서 설정할 수 없어서 상속받은 컴포넌트에서 추가로 _health 변수 작성해서 Start에서 Health = _health 해야 하던데 이러면 변수를 지정하는 이유가 있나요?
그리고 제가 배울때는 인터페이스가 상수 용도라고 했었는데 c#은 다른가요?
와 진짜 귀찮아서 하지않았던것들을 혼나는 기분으로 봤습니다
설명도 좋은데 목소리까지 좋으셔서 귀에 쏙쏙 박힙니다.
늘 도움 받고 있습니다.
감사합니다.
단일 책임 원칙은 하나의 클래스는 하나의 기능을 가져야 한다는 것이 아닙니다.
클래스의 코드가 수정되어야 할 이유는 하나여야 한다는 원칙입니다.
말이 아다르고 어다른 느낌이네요
결국 클래스의 목적?이 있으면 그것과 관련된 여러기능이 있어도
수정을 할땐 그 목적인 하나의 이유라면 괜찮다 이렇게 이해하면 될까요?
어떠한 기능이 문제가 생겨서 수정해야할때 그 클래스만 수정할 수 있다면 ㅇㅋ입니다
그 하나의 이유가 클래스가 맡은 기능을 수행하는 방식이 변경되는 경우를 의미입니다.
인터페이스 사용이 막연했는데 이 영상덕분에 어떻게 사용할지 감이 잡힌거 같아요ㅎㅎ 감사합니다!
감사합니다, 엄청난 도움이 됐습니다!
와 드디어 나왔다!! 진짜 기다렸어요 ㅠㅠ 오늘코딩
증말 사랑합니다
ㄹㅇ 조금이라도 제대로 구조 만들다보면 무조건 필요함
훌륭한 영상입니다
이걸 아는 사람은 많이 보앗지만 지키는 개발자는 정말 못봣다고 할 정도로 적은거같네요
물론..대부분 기존소스로 고도화를 하다보니 한계가 있긴하지만
아에 모르는 사람은 꼭 이 영상을 시청하면 좋을것같습니다
저희 회사 신입에게 프로젝트할때만 말로 설명하는데 이 영상을 참조하는것도 좋을것같네요 감사합니다
LSP 원칙을 잘 지켜 타입 계층이 만들어지면 OCP 원칙도 자연스레 지켜지게 되겠네요.
훌륭한 강의영상 감사합니다!
오늘도 좋은 영상 감사합니다.
객체 지향 법칙에 대해서 잘 알게 되었습니다. 스스로 공부해보면서 코드에 적용해보아야겠습니다.
잘봤습니다!!! 머리가 띵햇네요 여러번 다시 봐야겠습니댜
앞으로 계속 염두에 두고 배워가야겠습니다. 잘봤습니다. 감사합니다!
필수적인 내용들을 쉽게 풀어서 설명해주셔서 감사합니다😊
오늘코딩님 덕분에 솔리드를 이론으로만 알고있었는데, 직접 응용까지 하게되서 너무감사드립니다 ㅠ
혹시 MVP나 MVVM같은 디자인 패턴도 다루실 예정이 있으신가요!? 유튜브에 찾아봐도 예제는 잘 보이질 않네유ㅠ
귀한영상
이해하기 쉽게 영상 만들어주셔서 감사합니다. 😊
역시 설명을... 👍
이 솔리드 원칙이 디자인 패턴과 유사하다고 볼 수 있는 건가요?? 아 그리구 최근에 부트캠프 고민 문제로 오늘 코딩님과 쪽지를 주고 받은 적이 있었는데 , 덕분에 잘 선택하였습니다!!
오... 역시 유튜브 알고리즘이야
설명 잘들었습니다!!
복습하게 해주셔서 감사합니다.
아주 쉽게 설명 감사합니다
쉽게 이해할 수 있게 예시가 있어 좋네요!
너무좋네요
좋은영상감사합니다
이론상으로는 이해를 잘 했는데
이걸 실제로 적용하고 개발하다 보면 애매하게 헷갈리는 경우가 생길 것 같음..
내가 얼마나 코드를 대충짜고있었는지 느껴진다
내가 하고있던건 객체지향이 아니라 절차지향이였구나
너무 알차군요 구독할수밖에 없습니다ㅏ
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);
}
@@최영수-r3m EventHandler처럼 단순히 데이터를 주고받기보다 이벤트로 받은 값 A를 B로 변환하고, 그 중 조건에 맞는 C만 얻어내고, 다시 D로 변환하는 등 원하는 형태로 데이터를 Stream의 형태로 바꿀 수 있는게 큰 장점같아요!
드디어..!
와.. 목소리 지렸....
오 이렇게 쉬운 예제가 있다니
감사합니다!! ㅎㅎ
너무너무 예쁘다고 해도
너를 떠올리며 거절했지만
이번 한번뿐이라는 걸 맹세해
단일책임원칙이 잘못 설명되었습니다
단일책임 원칙에서의 책임은 객체의 책임을 의미하지 않습니다
와 알차다
혹시 c++강의가 따로 있을까요?
기본중에 기본인것들이네요. 웹 프로그램밍을 하든 윈도우 프로그래밍을 하든 저런 기본적인것들만 잘 지켜도 유지보수 하기 쉬워지죠
알 차다
문법 알고 API 좀 더 아는게 중요한게 아니라 이런걸 잘 지키는게 실제 코드의 지속성, 안전성, 유지보수성에 가장 중요한데. 신입급은 말할것도 없고 경력 좀 있다는 개발자도 이걸 잘 못지키네요. 더욱 답답한건 본인들이 코드에 똥 싸놓은걸 다른 이들이 피해를 보는데 정작 본인이 멀 잘못 했는지도 모름...
사짜 개발 유튜버들 많던데 아... 이분은 인정합니다!
김조한이 부릅니다 "이 밤에 끄츨 좝고 있눈 나에 코드가 더 이상 쵸롸하지 안케에에"
👍
알차다 오코..b
단일책임과 단일기능은 다른거 아닙니까?
예제로 살펴보는 솔리드 원칙
게임 개발시에 더 중요한 이유가 있나요?
거의 모든 프로그래밍에 필요한 개념이긴 합니다. 저기에 모든 원칙을 항상 따르지 않아도 좋은 프로그램을 만들 수는 있지만 개발을 더 진행하면서 막히는 부분이 분명히 찾아옵니다. 그래서 게임개발에만 중요하진 않고 거의 모든 개발에 중요하다고 생각되네요
게임 개발이 가장 규모가 크고 복잡해서 그렇지 않을까요?
사실상 웹개발이 구조가 가장 간단하니까요
😮😮
단일 책임원칙과 개방폐쇄 원칙을 보면서 드는 궁금점이 5각형 클래스가 shape 을 상속받아 면적을 계산하는 함수를 오버라이드 하고 5각형 클래스 안에 5강형의 면적을 계산하는 메서드를 구현하면 다시 단일책임 원칙을 위배하는 것 아닌가요?
01:45 부분에 상속하여 확장하기에 용이하다는 점으로 볼 때 오히려 단일 책임 원칙의 이점으로 볼 수 있을 것 같아요. Shape가 단일기능이었기에 각각의 다각형의 면적 계산(확장된 기능)을 적용할 수 있다는 말로 전 이해했습니다.
저는 오각형은 shape을 상속하니 shape의 책임을 가진다고 봤습니다. 책임분리에 대해 논하는 것은 Shape과 Shape이 아닌 객체 사이 상호작용에 적합한 것 같은데 어떻게 생각하시는지요?
디자인 패턴도 다루실 예정인가요?
다룰 생각은 항상 있는데 언제 업로드 할 수 있을 지는 모르겠습니다