예전엔 플머들 필독서였는데 요즘 애들은 c++을 잘 안하기도 하고 모르는 사람이 대부분인 듯
c++ 로 써져있긴 한데 c++ 아니어도 코딩 전반적인 상식들 이해하기에 좋음
ㅇㅇ 1(222.109)2025-03-10 22:06:00
답글
고맙습니다 도전해볼게요 - dc App
탱탱모모(wrapping5366)2025-03-10 22:07:00
이거 걍 그거아님?
클래스하나에 여러가지 메소드 한꺼번에 막 쳐넣지말고, 나눠서 쓴다 이거였나
익명(222.238)2025-03-10 22:06:00
간단하게 말하면 하나의 class는 하나의 일만 해야된다는거야
익명(hotkey02)2025-03-10 22:07:00
답글
godot gui 쪽 보면 됨
VBoxContainer, HBoxContainer 자식을 수직/수평 방향으로 배치하는 책임만 담당
MarginContainer - 자식 노드에 마진 추가하는 책임만 담당
PanelContainer - 패널 스타일을 적용하는 책임만 담당
Label - 택스트 표시하는 책임만 담당
이런식으로 하나의 class가 하나의 일만 해야함
익명(hotkey02)2025-03-10 22:24:00
답글
어디까지가 하나의 책임인지는 추상화 레벨에따라 달라질 수 있지만
핵심은 클래스나 노드가 변경되어야 하는 이유가 단 하나여야함
익명(hotkey02)2025-03-10 22:25:00
답글
갓godot로 설명해주니 이해가 쏙 되네요.역씨 고도신 - dc App
탱탱모모(wrapping5366)2025-03-10 22:26:00
클래스,메소드, 함수 ,시그널 뭐 막 이런걸 구분못하겟음 진짜큰일남 - dc App
탱탱모모(wrapping5366)2025-03-10 22:10:00
객체 지향으로 코드짜고, GPT한테 평가해달라고 해보삼.
계속 대가리 깨지면서 하면 됨
lhany(visitor0588)2025-03-10 22:11:00
답글
추가로 "한 클래스는 하나의 책임만 가져야 한다"를 예시로 들자면
lhany(visitor0588)2025-03-10 22:12:00
답글
CameraManager 안에 카메라 플로우(플레이어 따라가기), 카메라 페이드 인/아웃 등을 넣지말고
CameraFollow.cs, CameraFade.cs 이런 식으로 분리하라는 말임
lhany(visitor0588)2025-03-10 22:14:00
PlayerMovement 스크립트 만들면 여기엔 플레이어가 움직이는데에 필요한 필드와 메소드만 넣으라는거임
근데 어떻게든 구현하는게 훨 중요하니까 일단 만들면 됨
익명(fujiwara1)2025-03-10 22:11:00
답글
맞습니다 일단 구현해놓고 나중에 리팩토링하는게 더 나아요
ty(profound9724)2025-03-10 22:19:00
음.. 본인쟝이 몸소 체험해봤음. 모두 한 몸뚱아리로 만들면 어떤 일이 생기는지.
기능 하나 수정하거나 추가, 제거 할 때마다 클래스 전체를 휘젓는 상황이 발생하는 거임
안 되겠다 싶어서.. 최대한 쪼개서 쓰는 중...
선구자들의 지혜란..
211214(tomatoss)2025-03-10 22:13:00
답글
늘많이배워갑니다 선구자님 - dc App
탱탱모모(wrapping5366)2025-03-10 22:29:00
답글
211214(tomatoss)2025-03-10 22:31:00
객체지향 원칙에 너무 빠지지 마셈 지키는게 좋긴한데 일단 개같이 짜놓고 나중에 구조 바꿔도 됨
익명(gcghqzs9jhhk)2025-03-10 22:16:00
답글
맞슴다.개같이 짜버리겠음. - dc App
탱탱모모(wrapping5366)2025-03-10 22:18:00
답글
지킬건 지키는 게 좋음. 잠깐 10분 더 써서 나중에 10시간, 1주일 고생할거 아낄수가 있음
너무 막짜면 나중에 못고치고 사실상 처음부터 싹 다 다시 짜야되는 순간이 옴
익명(bloom9810)2025-03-10 22:19:00
답글
211214(tomatoss)2025-03-10 22:20:00
답글
뭐 수백줄 짤동안 건드리지 말라는 의민 아닌데 일단 기능구현 해놓고 시간들여서 천천히 구조 바꾸란거지 뭐
익명(gcghqzs9jhhk)2025-03-10 22:24:00
답글
이거를 전문용어로 기술부채라고 하는데
스파게티로 막짜면 나중에 감당해야 되는 거에 이자가 붙어서 기하급수적으로 늘어남
그래서 주기적으로 리팩토링을 해서 이자랑 원금을 청산해주는 거임
안그럼 나중에 감당 못하고 파산하거든
익명(bloom9810)2025-03-10 22:25:00
답글
ㅇㅇ 너무 과하게 집착해도 문젠데 너무 안지켜도 문제임
익명(bloom9810)2025-03-10 22:25:00
답글
적당한 타이밍에 분리해서 리팩토링하라는거죠?
많이.해바야알것같네요. 그 타이밍이 언제인지 아직도 감이 안옴 ㅎㅎ - dc App
탱탱모모(wrapping5366)2025-03-10 22:31:00
답글
어...이거 여기서 더 하면 ㅈ될것 같은 직감이 옴. 그때 하면 됨.
흑_두루미(combedro)2025-03-10 22:44:00
답글
경험 쌓이면 알게되는 날이 무조건 옴 그리고 평소에 코드 짜다가 이건 다른데서도 자주 쓰일거 같은데? 싶은 것들을 따로 클래스로 만들어 보거나 구현 하기전에 어떤 기능이 필요한지 생각해보고 미리 클래스를 분리해서 설계 해보거나 하면서 객체지향 감각을 늘리는거임 그 뒤에 솔리드가 중요해지는거고
effective c++이라는 레전드 책 읽어보면 대부분의 코딩 상식같은건 다 이해될거임
예전엔 플머들 필독서였는데 요즘 애들은 c++을 잘 안하기도 하고 모르는 사람이 대부분인 듯 c++ 로 써져있긴 한데 c++ 아니어도 코딩 전반적인 상식들 이해하기에 좋음
고맙습니다 도전해볼게요 - dc App
이거 걍 그거아님? 클래스하나에 여러가지 메소드 한꺼번에 막 쳐넣지말고, 나눠서 쓴다 이거였나
간단하게 말하면 하나의 class는 하나의 일만 해야된다는거야
godot gui 쪽 보면 됨 VBoxContainer, HBoxContainer 자식을 수직/수평 방향으로 배치하는 책임만 담당 MarginContainer - 자식 노드에 마진 추가하는 책임만 담당 PanelContainer - 패널 스타일을 적용하는 책임만 담당 Label - 택스트 표시하는 책임만 담당 이런식으로 하나의 class가 하나의 일만 해야함
어디까지가 하나의 책임인지는 추상화 레벨에따라 달라질 수 있지만 핵심은 클래스나 노드가 변경되어야 하는 이유가 단 하나여야함
갓godot로 설명해주니 이해가 쏙 되네요.역씨 고도신 - dc App
클래스,메소드, 함수 ,시그널 뭐 막 이런걸 구분못하겟음 진짜큰일남 - dc App
객체 지향으로 코드짜고, GPT한테 평가해달라고 해보삼. 계속 대가리 깨지면서 하면 됨
추가로 "한 클래스는 하나의 책임만 가져야 한다"를 예시로 들자면
CameraManager 안에 카메라 플로우(플레이어 따라가기), 카메라 페이드 인/아웃 등을 넣지말고 CameraFollow.cs, CameraFade.cs 이런 식으로 분리하라는 말임
PlayerMovement 스크립트 만들면 여기엔 플레이어가 움직이는데에 필요한 필드와 메소드만 넣으라는거임 근데 어떻게든 구현하는게 훨 중요하니까 일단 만들면 됨
맞습니다 일단 구현해놓고 나중에 리팩토링하는게 더 나아요
음.. 본인쟝이 몸소 체험해봤음. 모두 한 몸뚱아리로 만들면 어떤 일이 생기는지. 기능 하나 수정하거나 추가, 제거 할 때마다 클래스 전체를 휘젓는 상황이 발생하는 거임 안 되겠다 싶어서.. 최대한 쪼개서 쓰는 중... 선구자들의 지혜란..
늘많이배워갑니다 선구자님 - dc App
객체지향 원칙에 너무 빠지지 마셈 지키는게 좋긴한데 일단 개같이 짜놓고 나중에 구조 바꿔도 됨
맞슴다.개같이 짜버리겠음. - dc App
지킬건 지키는 게 좋음. 잠깐 10분 더 써서 나중에 10시간, 1주일 고생할거 아낄수가 있음 너무 막짜면 나중에 못고치고 사실상 처음부터 싹 다 다시 짜야되는 순간이 옴
뭐 수백줄 짤동안 건드리지 말라는 의민 아닌데 일단 기능구현 해놓고 시간들여서 천천히 구조 바꾸란거지 뭐
이거를 전문용어로 기술부채라고 하는데 스파게티로 막짜면 나중에 감당해야 되는 거에 이자가 붙어서 기하급수적으로 늘어남 그래서 주기적으로 리팩토링을 해서 이자랑 원금을 청산해주는 거임 안그럼 나중에 감당 못하고 파산하거든
ㅇㅇ 너무 과하게 집착해도 문젠데 너무 안지켜도 문제임
적당한 타이밍에 분리해서 리팩토링하라는거죠? 많이.해바야알것같네요. 그 타이밍이 언제인지 아직도 감이 안옴 ㅎㅎ - dc App
어...이거 여기서 더 하면 ㅈ될것 같은 직감이 옴. 그때 하면 됨.
경험 쌓이면 알게되는 날이 무조건 옴 그리고 평소에 코드 짜다가 이건 다른데서도 자주 쓰일거 같은데? 싶은 것들을 따로 클래스로 만들어 보거나 구현 하기전에 어떤 기능이 필요한지 생각해보고 미리 클래스를 분리해서 설계 해보거나 하면서 객체지향 감각을 늘리는거임 그 뒤에 솔리드가 중요해지는거고
흐어어엉 - dc App
일단 짜고 좆되면 그때 공부해도 된다 직접 몸으로 겪으면서 배우는게 제일 효율적인 법이야