[💬] 객체 기능 세분화의 기준이나 범위가 있을까요?

[익명(58.232)]

교수님께 여쭤보니 
최대한 나눌수있을만큼 나누는게 좋다고 하시는데 
그 기준을 못잡겠습니다.

[raveneer(121.150)]

자기가 컨트롤 할 수 있는 수준에서 나누고 뭉치는게 맞음. 같이 하는 사람이 있다면 그사람과 같이 봤을 때 동일한 것을 의미함을 공감할 수 있을 수준이 되어야 함. 잘게 잘게 쪼개면 함수 한두개 가진 변태 클래스까지 생기게 되는데, 그러면 의미가 붕괴함. ECS 라는 개념이 있는데 이게 클래스를 최대한 잘게 나누어 변수나 함수까지 클래스화 시켜서 쓸때는 합쳐서 쓰자는 이론임.

[익명(116.122)]

기본 원칙은 한클래스에 하나의 책임만 부여하는거임 여기서 책임을 나누는 기준이나 범위는 딱히 없음 사람마다 다르고 상황마다 다름 이건 많이 해보면서 느껴야함 좆되는 경우를 만나보면 자기만의 스타일이 생김 직접 만들어본 코드를 수정, 기능 추가같은걸 해보면서 리펙토링 해보는게 최고임

[익명(116.122)]

예를 들면 A클래스를 수정했는데 B,C,D 클래스 까지 영향을 미쳐서 수정해야하는 상황이 생기면 아주 최악의 코드인거임 그래서 객체설계할땐 항상 유지보수에 신경쓰면서 해야함 확장엔 열려있고 변화엔 닫혀있게ㅇㅇ 내 경험상 데이터 중심적으로 생각하면 좆되는 경우가 많고 항상 기능중심으로 생각해야함

[익명(116.122)]

팁하나 주자면 항상 현실세계에 비춰서 생각해봐 예를 들어 니가 손님한테 물건을 판다고 해보자. 1.돈을 건내주면 2.넌 물건 가격이 맞는지 확인하고 3.물건을 건내주겠지? 여기서 너는 그 손님의 지갑안에 얼마가 있는지 알수도 없고 알필요도 없어 그냥 손님이 얼마를 줬고 그 돈이 물건 값에 맞는지만 체크하고 건내줄뿐이지 이런 느낌으로.. 데메테르 법칙이란건데 항상 이거 참고하면서 짜면 도움 될꺼야

[raveneer(121.150)]

ECS 써보니 처음에는 신통했지만 가면 갈수록 '이 클래스가 무엇인지 모르겠다' 가 심해짐. 무조건 쪼개는게 능사는 아님. 어떤 클래스를 보았을때 이름만 봐도 계가 뭐 할지 감이 올 정도로는 뭉쳐줘야 함. 그 적당히가 얼마만큼인지는 개발자와 팀원의 기준에 따라가는게 좋다고 생각함.

[익명(110.70)]

바나나 딸기 포도 망고 귤 한라봉 천혜향 구운귤 초코바나나 망고쥬스 파인애플 산딸기 브로콜리 파인애플피자 이것들을 어떻게 나눌거냐? 조리된것과 조리되지 않은것 나무에서 열매를 맺는것과 줄기에서 맺는것 귤종류와 귤종류가 아닌것 등등 상황에 따라 필요에 따라 나누는거지 답이 있는게 아님

[raveneer(121.150)]

과도한 추상성과 과도한 구체성 사이 어딘가를 지향해야 함. Storage는 너무 추상성이 강해 쓸모가 없고 Chest는 너무 구체적이라 제약이 많음. ItemStorage 정도라 아이템이면 뭐든지 넣고 뺄 수 있으니 ITemStorage를 잘 만들어두면 Chest 도 만들고 BackPack 도 만들수 있음.

[raveneer(121.150)]

근데 이게 자기가 이해 가능한 수준으로 가야 하므로 결론은 니 꼴리는대로 하면 됨.

[익명(211.246)]

댓글이 유익해서 개추

[익명(39.7)]

너무나누몀 오버코딩임 - dc App

[익명(39.7)]

대표적으로 SOLID라는 이론적 기준이 있고 - dc App

[익명(39.7)]

실무에선 기능분할로 코드수정을 회피할 수 있는 범위가 넓어지는가? isolation test가 용이한가? 를 구분하면대 - dc App

[익명(39.7)]

윗댓이 정리를 잘해놨지만 당장 대답엔 내 의견도 도움이 될거같아 추가함 - dc App