처음에 단순히 '사람이 일하다' 정도로 짰는데 나중에 무엇을 가지고 구체적으로 어떤 일을 했는가 점점 추가할 필요가 있어지면
work에 어떤 일을 해야 하는지 추가해야 할지, Person에 추가해야할지 (예로 들자면 직업에 따라 일한다고 치고 .work를 하면 그 직업대로 일함) 잘 감이 안 와..
중구난방되고 그러는데 해결 방법이나 지향첨 있을까
익명(122.32)2024-03-29 01:36
Person.work(Work)를 하면 Person이 Work에 종속되는거고
Work.execute(Person)을 하면 Work가 Person에 종속되는거임
Work가 변하면 Person이 변해야해? 그럼 Person.work(Work)를 쓰는거고
그래선 안된다면 Work.execute(Person)를 쓰는거지
둘다 변하면 안되면 둘중 하나를 추상화 시켜야하는거고
"사람이 일한다" 이런 문장에 집중하는건 초보적인 실수임
프갤러 1(183.109)2024-03-29 01:36
답글
중요한건 니가 둘중에 뭘 더 높은 급수의 오브젝트로 다룰거냐임
Person 말고 다른게 Work를 실행시킬 수 있으면 Person.work(Work)를 해야함
Person이 Work 말고도 여러가지를 다루는 공통 개념이면 Work.execute(Person)를 해야함
Person 말고도 다른게 Work를 실행시킬수도 있고
Person도 Work 말고 여러가지를 다룰 수 있으면 별도 개념으로 추상화를 시켜야함
예를 들자면 Worker같은거로
프갤러 1(183.109)2024-03-29 01:38
답글
어느 정도 이해했음 고마움. 그런데 처음엔 사람이 일을 한다는 한가지 경우의 수만 생각했는데 추후에 'a가 b를 한다'처럼 만들어야 한다면 니 말처럼 worker라는 것으로 추상화를 더 해야할텐데 내가 초보라 그런지 막상 하다보면 worker에 무엇을 넣어야할지 잘 생각도 안 나고, 무작정 늘어나는 것만 같아서 말이지.
좀 정리 방법론 없을까?
익명(122.32)2024-03-29 01:48
답글
뭐가 뭘 한다는 개념에 집착하지마. 그건 수단과 목적이 뒤바뀐거야
중요한건 관계와 종속이야
관계를 어떻게 짜야 코드가 가독성 좋고 체계적으로 다뤄질 수 있을지만 고민해
Worker에 무엇을 넣어야할지 잘 생각이 안나면 추상화 할 상황이 아닌거야
추상화는 정말 필요한 순간까지 미뤄야함
프갤러 1(183.109)2024-03-29 01:51
답글
객체지향은 원래 경험이 좀 필요해
뭐에 뭘 해야할지 처음부터 아는 사람이 어디있겠어?
공부 존나게 한 주니어들이 좃같은 코드 배설하는데는 다 이유가 있다
프갤러 1(183.109)2024-03-29 01:53
답글
글 읽고 대충 내가 머릿속으로 떠올리던 개념 다시 정리해보니까 다시 한 번 짜보면 어느정도 해볼 수 있을 것 같음.. 처음부터 할 수 있을진 모르겠지만 일단 노력해보게 고마워
익명(122.32)2024-03-29 02:05
답글
계속 생각하고 계속 짜봐야됨
객체지향은 그 방법밖엔 없음
책 많이 읽어서 다른 사람의 경험을 흡수하는거도 좋은 방법임
가장 주의해야되는건 객체지향 딸딸이임
아래서 헬마스터가 말하는거처럼 객체지향으로 뭐든지 할 수 있다는 망상에 빠지면 안됨
프갤러 1(183.109)2024-03-29 02:07
이게 oop의 맹점임. 이 경우는 명사.동사()로 person.work()가 맞겠으나 둘다 명사이고 객체인 경우는 골때리지
본인이 생각했을때 명확한답이 없고 우리는 계속해서 낳은 답을 찾아가는 중인듯
헬마스터(supersaver)2024-03-29 01:42
답글
oop의 맹점이 아니라 글쓴이의 맹점이지
프갤러 1(183.109)2024-03-29 01:43
답글
oop는 정보를 체계적으로 다루는 방법론인데, 그걸 명사.동사로 다루는 방법론으로 격하시켜버리니 답이 안나올수밖에
프갤러 1(183.109)2024-03-29 01:44
답글
oop를 그렇게 예술적 학문으로 올려치기 하면서 가독성보다는 계속 클래스 나누면서 쇼하다가 리턴한줄 있는 클래스 만들고 비효율적인 코드를 작성하는 사례를 많이 봐왔다
헬마스터(supersaver)2024-03-29 01:49
답글
oop의 맹점이라고 하면 oop에 문제가 있는거잖아
너 국어 못해?
프갤러 1(183.109)2024-03-29 01:52
답글
문제가 있지 oop는 완전무결한 방법이 아님
게터 세터만해도 헛짓거리임이 많이 전파되서 단순리턴용 게터는 쓰지않도록 권고되는 것으로 바꼈음
헬마스터(supersaver)2024-03-29 01:57
답글
그것도 사용자의 맹점이지
어느 세상의 객체지향에서 게터 세터를 강제함?
프갤러 1(183.109)2024-03-29 01:59
답글
테스트 커버리지 높이려고 게터 세터도 테스트하면 그건 테스트의 맹점임 ㅋㅋ?
프갤러 1(183.109)2024-03-29 02:00
답글
oop는 애초에 정해진 한개의 방법이 아니라서 완전무결하냐 아니냐를 따질 대상이 아님
너는 나사 잠그고 푸는 드라이버 보고 이것은 완전무결한 것이 아님 이라고 표현하냐?
프갤러 1(183.109)2024-03-29 02:01
답글
세간에서 강조된 oop 실천 방법들에 이상한 부분들이 있다고 말한거면야 이해가 되는데
그런 이상한 부분들 때문에 oop 자체를 부정하는건 좀 수준낮은 접근 아닐까
프갤러 1(183.109)2024-03-29 02:02
답글
드라이버는 건물을 철거하는데 쓸 수 없으므로 완전무결한 것이 아니다..
프갤러 1(183.109)2024-03-29 02:06
답글
라는건 좀 이상하잖아
프갤러 1(183.109)2024-03-29 02:06
위에 댓글처럼 말에 집착하지말고 만드는 목적이 중요한거지
11(223.38)2024-03-29 02:03
답글
사람이 일련의 작업을 하는 게임 같은 걸만든다면 Person 객체가 work eat move 처럼 메서드만 가져도 될테고
11(223.38)2024-03-29 02:04
답글
일의 태스크를 나눠서 계획하는 프로그램이면 Work 클래스에 Person 객체를 할당할거고
11(223.38)2024-03-29 02:05
답글
어떤걸 객체로 볼것인지는 만드는 프로그램에 따라 정해지는 거지 무조건 명사는 객체고 동사는 메서드가 아님
11(223.38)2024-03-29 02:07
답글
개인적으론 다형성을 가지는 경우엔 대체로 클래스화 하게 되는 느낌이긴 했음
11(223.38)2024-03-29 02:09
답글
댓글 쭉 읽어보다 보니 개념이 좀 정리 되는 것 같기도 하고.. 고맙다 좀 더 생각 정리해볼게
해당 댓글은 삭제되었습니다.
처음에 단순히 '사람이 일하다' 정도로 짰는데 나중에 무엇을 가지고 구체적으로 어떤 일을 했는가 점점 추가할 필요가 있어지면 work에 어떤 일을 해야 하는지 추가해야 할지, Person에 추가해야할지 (예로 들자면 직업에 따라 일한다고 치고 .work를 하면 그 직업대로 일함) 잘 감이 안 와.. 중구난방되고 그러는데 해결 방법이나 지향첨 있을까
Person.work(Work)를 하면 Person이 Work에 종속되는거고 Work.execute(Person)을 하면 Work가 Person에 종속되는거임 Work가 변하면 Person이 변해야해? 그럼 Person.work(Work)를 쓰는거고 그래선 안된다면 Work.execute(Person)를 쓰는거지 둘다 변하면 안되면 둘중 하나를 추상화 시켜야하는거고 "사람이 일한다" 이런 문장에 집중하는건 초보적인 실수임
중요한건 니가 둘중에 뭘 더 높은 급수의 오브젝트로 다룰거냐임 Person 말고 다른게 Work를 실행시킬 수 있으면 Person.work(Work)를 해야함 Person이 Work 말고도 여러가지를 다루는 공통 개념이면 Work.execute(Person)를 해야함 Person 말고도 다른게 Work를 실행시킬수도 있고 Person도 Work 말고 여러가지를 다룰 수 있으면 별도 개념으로 추상화를 시켜야함 예를 들자면 Worker같은거로
어느 정도 이해했음 고마움. 그런데 처음엔 사람이 일을 한다는 한가지 경우의 수만 생각했는데 추후에 'a가 b를 한다'처럼 만들어야 한다면 니 말처럼 worker라는 것으로 추상화를 더 해야할텐데 내가 초보라 그런지 막상 하다보면 worker에 무엇을 넣어야할지 잘 생각도 안 나고, 무작정 늘어나는 것만 같아서 말이지. 좀 정리 방법론 없을까?
뭐가 뭘 한다는 개념에 집착하지마. 그건 수단과 목적이 뒤바뀐거야 중요한건 관계와 종속이야 관계를 어떻게 짜야 코드가 가독성 좋고 체계적으로 다뤄질 수 있을지만 고민해 Worker에 무엇을 넣어야할지 잘 생각이 안나면 추상화 할 상황이 아닌거야 추상화는 정말 필요한 순간까지 미뤄야함
객체지향은 원래 경험이 좀 필요해 뭐에 뭘 해야할지 처음부터 아는 사람이 어디있겠어? 공부 존나게 한 주니어들이 좃같은 코드 배설하는데는 다 이유가 있다
글 읽고 대충 내가 머릿속으로 떠올리던 개념 다시 정리해보니까 다시 한 번 짜보면 어느정도 해볼 수 있을 것 같음.. 처음부터 할 수 있을진 모르겠지만 일단 노력해보게 고마워
계속 생각하고 계속 짜봐야됨 객체지향은 그 방법밖엔 없음 책 많이 읽어서 다른 사람의 경험을 흡수하는거도 좋은 방법임 가장 주의해야되는건 객체지향 딸딸이임 아래서 헬마스터가 말하는거처럼 객체지향으로 뭐든지 할 수 있다는 망상에 빠지면 안됨
이게 oop의 맹점임. 이 경우는 명사.동사()로 person.work()가 맞겠으나 둘다 명사이고 객체인 경우는 골때리지 본인이 생각했을때 명확한답이 없고 우리는 계속해서 낳은 답을 찾아가는 중인듯
oop의 맹점이 아니라 글쓴이의 맹점이지
oop는 정보를 체계적으로 다루는 방법론인데, 그걸 명사.동사로 다루는 방법론으로 격하시켜버리니 답이 안나올수밖에
oop를 그렇게 예술적 학문으로 올려치기 하면서 가독성보다는 계속 클래스 나누면서 쇼하다가 리턴한줄 있는 클래스 만들고 비효율적인 코드를 작성하는 사례를 많이 봐왔다
oop의 맹점이라고 하면 oop에 문제가 있는거잖아 너 국어 못해?
문제가 있지 oop는 완전무결한 방법이 아님 게터 세터만해도 헛짓거리임이 많이 전파되서 단순리턴용 게터는 쓰지않도록 권고되는 것으로 바꼈음
그것도 사용자의 맹점이지 어느 세상의 객체지향에서 게터 세터를 강제함?
테스트 커버리지 높이려고 게터 세터도 테스트하면 그건 테스트의 맹점임 ㅋㅋ?
oop는 애초에 정해진 한개의 방법이 아니라서 완전무결하냐 아니냐를 따질 대상이 아님 너는 나사 잠그고 푸는 드라이버 보고 이것은 완전무결한 것이 아님 이라고 표현하냐?
세간에서 강조된 oop 실천 방법들에 이상한 부분들이 있다고 말한거면야 이해가 되는데 그런 이상한 부분들 때문에 oop 자체를 부정하는건 좀 수준낮은 접근 아닐까
드라이버는 건물을 철거하는데 쓸 수 없으므로 완전무결한 것이 아니다..
라는건 좀 이상하잖아
위에 댓글처럼 말에 집착하지말고 만드는 목적이 중요한거지
사람이 일련의 작업을 하는 게임 같은 걸만든다면 Person 객체가 work eat move 처럼 메서드만 가져도 될테고
일의 태스크를 나눠서 계획하는 프로그램이면 Work 클래스에 Person 객체를 할당할거고
어떤걸 객체로 볼것인지는 만드는 프로그램에 따라 정해지는 거지 무조건 명사는 객체고 동사는 메서드가 아님
개인적으론 다형성을 가지는 경우엔 대체로 클래스화 하게 되는 느낌이긴 했음
댓글 쭉 읽어보다 보니 개념이 좀 정리 되는 것 같기도 하고.. 고맙다 좀 더 생각 정리해볼게
정보) oop와 전혀 상관없고 단지 아스키 아트적인 고민