일단 제 븅같은 두뇌로 귀한 말씀 곱씹어보니
무슨 말씀이신지 감이 온거 같은데요
형님께서는 c1ustmoer 객체에서의 orderFood(server)도 b로 보내는 메시지로 보시는거 잖아요?
위 예제에서 orderFood가 c1ustomer의 메서드였으면
저런식으로 내부함수로 표현하는게 맞는거 같은데
아닌가요?
메세지라는 개념에 대해 서로가 말하는게 다른거 같아서
영상이랑 서적들 많이 찾아봤는데
메서드를 일반적으로 절차지향에서의 함수 호출과 유사한 것으로 보고 한 객체에서 다른 객체의 메서드를 요청하는 형태를 메시지라 하는 설명이 주류 인거 같고(객체가 호출한다는 차이점만 있고)
의사소통을 한다라고 설명하는 분들은 예제가 없어서
구체적으로 의사소통의 의미가 뭔지 알아듣기 어렵더라구요
이런거에 왜 집착하는지 모르겠네 - dc App
객체지향이 객체들 간 상호작용이 핵심인데 이런걸 생각하는 습관이 결국 실력을 만드는거 아닐까요? 2학년이 학부공부 열심히 하면 되지 뭘 해야 하죠?
그러니까 외국서적 보라고 니가 올린 예제들 표기도 일관성 없고 존ㄴ나 병신같던데
오퍼레이션을 왜 자기 자신의 행위라고 생각하는거야?
오퍼레이션을 보내는 저 화살표가 자기 자신의 행위고, 오퍼레이션은 내가 보내는 메시지이자 상대방의 메소드인거야
책에는 메시지를 요청한다라는 의미가 메시지를 요청하는 객체가 메시지를 수신하는 객체의 메서드를 요청하는거라고 설명돼있더라구요.. 그래서 영상들도 좀 봣는데 강의자들도 보통 메서드 요청으로 보더라구요?
네 말씀하신게 결국 a->b로 메서드 요청하면 a가 b의 메서드를 요청한거 아닌가요?
그렇다니까?
형님께서 서버에 api 요청한거로 보면 된다고 하신게 결국 고객이 서버에 있는 기능을 사용하려고 요청했다라는 말씀 아니신지? 그러면 isOrderedFood가 맞지 않나요?
???
너 뇌가 좀 이상하게 동작하는거같은데
그런가요? 근데 객체는 역할을 갖잖아요? 주문하기라는건 고객이 주문하지 서버가 주문하진 않지 않나요? 그럼 서버가 주문을 행위로 받으려면 주문받기가 맞지 않아요?
메시지가 메소드라고 해서 네이밍까지 그게 맞춰야된다는건 아닌데.. 그럼 니 말대로 고객이 주문하는 주문 api는 order api가 아니라 isOrderedFood api여야하냐? 애초에 isOrderedFood는 또 뭔 개좆같은소리야;; 음식주문됐냐고??
아 그런가요..? 교수님이 네이밍 중요하다고 저런 것도 신경쓰라던데
isOrderedFood는 제가 지식이 짧아서 잘못 예로 든거 같고 어떤 느낌으로 말한건지만 알아주세여
아무튼 orderFood는 그럼 저기선 서버가 갖고 있는 메서드인거 맞져? 감사합니다
상황이 다른데 왜 같은 말을 씀.. 교수는 맞는 말 했는데 니 지능이 그걸 소화해내지 못한것임
그렇군요 죄송한데 그 상황이 뭔지 설명해주시긴 너무 번거로우시죠? api를 쓰는 상황이랑 네이밍 상황을 구분하라는 말씀이신건지 이해가 어렵네요 빡대가리라
만약 제가 서버에서 주문행위 메서드를 만드려면 메서드명을 뭐로 주는게 이상적인가요?
서버의 메소드명을 표현하자면 receiveOrder라고 해야겠지 server.receiveOrder("Give me a pizza") 정도가 되겠군 코드에서는 receiveOrder인데 시퀀스 다이어그램에서 orderFood인 이유는 관점이 다르기 때문이야 서버의 동작보다는 어떤 요청이 이루어졌는지를 표현하는게 더 중요한 상황임
아 그렇군요 답변 감사합니다 혈이 뚫린 기분이네요;; 귀한 시간 내주셔서 감사합니다
마지막으로 요청과 응답의 관점이 중요하니 실제 구현 코드랑 메서드명이 달라져도 무방한가요? 아님 구현 코드를 따라가는게 맞나요?
굿
당연히 다르게 해야지.. 그따위로 써놓으면 누가 알아먹겠냐고 중요한건 보는 사람이 이해할 수 있느냐야 본질을 잊지마
예 형님 감사합니다 근데 오늘 느낀게 이런 무수한 정보들 중에 뭐가 맞는지는 어떻게 판별하면 될까요.. 최대한 그 개념을 만들어낸 소스를 찾아내려고 하는게 좋을까요? 예를 들면 레퍼런스라던가
글고 정말 죄송한데 아니면 저 예제에서 메세지들을 왼쪽으로 한칸씩 옮겨서 액터가 고객 객체한데 orderFood 하는 식으로 방식을 바꿔도 되는거 맞나요? 고객이 orderFood 메서드 갖고
문법을 배우고 이해한 후, 제대로 이해했는지 여러가지 레퍼런스를 봐야지 레퍼런스가 혼란스러우면 더 크게 알려진 레퍼런스를 보는거고 그것마저도 말이 다 다르면 본질을 생각해봐야지
왜 자꾸 메소드라고 표현하는지 잘 모르겠네 상황에 따라 표현하는 단어가 달라지는데 그걸 꾸역꾸역 메소드라고 하니까 계속 헷갈리지 애초에 액터가 뭔데? 고객 객체의 대뇌가 액터임? 아니면 전화로 지시하는 배후세력?
ㅋㅋㅋㅋㅋㅋ죄송해요 첨 배울때 마치 책이 그림으로 오퍼레이션=메서드처럼 설명해놔서 고착화됐나봅니다
오퍼레이션이 메소드가 될수도 있기는 하지만, 메소드라는건 오퍼레이션이나 메시지들이 하고자 하는 바를 일반화시킨 개념이야 추상적인거랑 일반적인걸 1대1 매칭시켜서 이해하려니 이해가 안되는게 정상이지 시퀀스 다이어그램을 볼때는 메소드를 생각하지마
예 형님 답변 감사합니다!! 귀한 시간 내주셔서 고맙습니다요
대기형 근데 시퀀스 다이어그램은 크게 두가지 관점이잖아요? 형님이 말씀하신 1. 요청과 응답 관점 2. 객체의 동작(런타임 에서의) 이게 어떤 고객과 소통을 위한 목적이냐 아님 프로그래머를 위한 목적이냐에 따라 말씀하신 관점의 변화가 생길 수 있는거 맞나요? 고객과 소통이 중요하면 응답, 요청 관점에서 바라봐야 시스템 이해가 쉬울테고
프로그래머의 구현 관점이면 오퍼레이션을 메서드로 써주는게 더 이해하기 쉬운거 아닌지
구현 관점에서도 요청응답으로 바라보는게 제 소스코드를 남이 이해하기 더 쉬운가요? 현업에서
그렇긴 한데.. 프로그래머를 위한 목적이라 하더라도 메소드명으로 쓰진 않음 다시 말하지만 저건 코드가 아니야 추상화된 다이어그램이라고..
이미친새끼야 뇌가 있으면 생각을 해 그럴거면 그냥 소스코드를 써!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
아.. 그런데 코드가 아니긴 한데 결국 객체가 있다는건 코드가 구현돼있는 상황이고 시퀀스다이어그램은 그걸 이해하기 쉽게 하려고 따로 추상적으로 표현한 것임에도 그렇게 보는게 맞나요?
그래서 소스코드가 잘 구현돼있으면 저런 시퀀스 다이어그램도 필요가 없다던데 책에서..
답 달아보니 정답이 느왔네요? 감사합니다
니가 원하는건 액티비티 다이어그램이 아닐까 하는 생각도 드네
그렇군여 아직 클래스랑 시퀀스만 배워서.. 부족한 학식에게 좋은 관점 주셔서 감사합니다 어느정도 이해 된거 같습니다
시퀀스는 개발 전에 그릴수도 있고 후에 그릴수도 있지 코드란건 너무 복잡하고 다른 사정(최적화)에 의해 로직이 이상해져있을수도 있음 그럴때 담백하게 로직만 이해하고 싶으면 코드보다 각종 다이어그램을 그리는게 낫지
답변은 여기까지 한다 수고링
아하 그렇네요? 가끔 객체명 안 정해진 박스도 있던데 uml은 일반적으로 분석 설계에서 쓰는거니까
넵 감사합니다 정말!!
아오 스발 객체객체하니까 저게 뭔 자바 클래스 인스턴스인줄아냐 크게는 객체 하나가 시스템일수도 있어
ㅋㅋㅋㅋ하튜하튜