SW core/객체지향12 객체지향의 사실과 오해 - 개념, 명세, 구현 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 개념, 명세, 구현 UML 관련 서적중 마틴 파울러의 UML Distilled 2판 에서는 객체 지향 설계를 개념 관점, 명세 관점, 구현 관점으로 구분한다. 우선 개념 관점은 도메인안에 존재하는 개념과 개념간의 관계를 나타낸것이다. 도메인은 앞에서 말했듯이 사용자가 관심을 가지는 분야를 의미한다. 이 관점에서는 실제 도메인의 규칙을 최대한 유사하게 반영하는것이 핵심이다. 명세 관점부터는 소프트웨어의 세계로 넘어온다. 명세 관점에서는 What/Who 사이클에서 What 에 해당하는 무엇에 초점을 맞추어서 객체의 인터페이스에 해당하는 관점에 집중한다. 구현 관점은 우리와 같은 프로그래머가 .. 2021. 8. 29. 객체지향의 사실과 오해 - 기능과 구조의 통합 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 도메인 모델, 유스케이스 그리고 책임-주도 설계 시스템이라는 것은 사용자가 첫번째로 만나게 되는 객체이다. 사용자 입장에서 시스템은 자신과의 협력에서 자신의 요청을 처리하는 하나의 객체로 볼 수 있다. 시스템은 자신안에 더 작은 객체들을 갖고 있으며, 사용자로부터 받은 책임을 더 작은 객체들로 적절하게 분배해야 한다. 여기에서 책임-주도 설계가 등장한다. 유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 볼 수 있게 한다. 즉 사용자로 부터 처음으로 메시지를 수신하는 출발점의 역할을 한다. 그 이후에는 시스템이 안정적인 도메인 모델에 기반하여 기능을 수용하고 객체들로 책임을 분배한다.. 2021. 8. 28. 객체지향의 사실과 오해 - 기능 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 유스케이스 기능적 요구사항이라는 말을 들어본적이 있을것이다. 기능적 요구사항이란 시스템이 사용자에게 제공해야하는 기능의 목록이다. 시스템은 사용자의 목표를 달성하기 위해 기능들을 제공하는데 사용자가 시스템에 작업을 요청하고 시스템은 이 요청을 처리하여 응답한다. 이러한 과정은 사용자가 목표를 이루거나 에러가날 때까지 계속된다. 유스케이스는 사용자의 목표 달성을 위해 사용자와 시스템간의 상호작용의 흐름을 텍스트로 정리한것이다. 시스템이 제공해야 하는 기능 목록을 모두 만족하면 사용자의 목표를 이룰 수 있는데 왜 굳이 유스케이스 라는 것을 따로 작성해야 하는가? 시스템이 제공해야하는 기능 목.. 2021. 8. 27. 객체지향의 사실과 오해 - 구조 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 도메인 모델 은행에서는 고객의 자산을 관리하고 보호하기 위해, 게임에서는 재미를 위해 또 병원에서는 환자의 진료 및 업무 관리를 위해 소프트웨어를 사용한다. 이처럼 사용자가 프로그램을 사용하는 대상 분야를 도메인이라고 한다. 모델은 복잡한 세상속에서 필요한 것들을 추려낸것이다. 만약 필요한 것만 추려내고 문제와 관련없는 나머지 세부사항들을 무시하는 추상화를 한 모델이 없다면 너무나 복잡하고 고려할것이 많아서 프로젝트 기간이 아무리 길다 한들 개발자들은 소프트웨어를 만들어내지 못할것이다. 이렇게 도메인과 모델의 정의를 고려할 때 도메인 모델이란 사용자가 소프트웨어를 사용하는 대상 분야에서 .. 2021. 8. 26. 객체지향의 사실과 오해 - 기능과 구조 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 문제를 접근하는 두 가지 방법 낯선 여행지에서 목적지를 찾아가는 방법에는 여러 가지가 있다. 어떤 사람은 모르는 사람에게 길을 묻고, 어떤 사람은 지도를 보고 목적지를 찾아간다. 모르는 사람에게 길을 물으면서 찾아가는 해결법은 '기능적이고 해결책 지향적인 접근법(functional, solution-directed approach)' 라고 할 수 있다. 가령 '길을 따라 얼마쯤 가다가 어떤 랜드마크가 보이면 다른길로 가세요'와 같은 식이다. 반면 지도를 이용하는 방법은 '구조적이고 문제 지향적인 접근법(structural, problem-directed approach)' 이다. 지도는 .. 2021. 8. 26. 객체지향의 사실과 오해 - 인터페이스 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 인터페이스 인터페이스에는 3 가지 특징이있다. 우선 사용법만 익히면 내부 구조나 동작방식을 몰라도 된다. 또한 내부 구조나 동작방식을 바꾸더라도 사용자에게 영향을 미치지 않는다. 그리고 인터페이스를 변경하지 않으면 사용자와 의사소통에 전혀 문제가 없다는것이다. 앞에서 우리는 메시지의 중요성을 재차 강조했었다. 객체가 다른 객체와 상호작용할 수 있는 유일한 방법은 메시지를 주고 받는것이기 때문에 인터페이스란 객체가 수신할 수 있는 메시지의 목록이라고 할 수 있다. - 책임, 메시지, 인터페이스 여태까지 살펴본 책임, 메시지, 인터페이스를 잠시 정리하는 시간을 가져보자. 맨 먼저 객체의 자율.. 2021. 8. 24. 객체지향의 사실과 오해 - 객체지향의 핵심 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 객체지향의 핵심, 메시지 객체지향이라는 단어를 들으면 가장 먼저 생각나는것은 클래스이다. 프로그램을 구현하라고 하면 우리가 가장 먼저 하는 일은 클래스를 선언하고 속성과 메소드를 채워넣는것이다. 그리고 클래스간의 의존성을 관리하며 상속도 사용한다. 하지만 객체지향의 강력함은 객체들이 주고 받는 메시지에서 나온다. 따라서 객체들의 속성과 행위를 먼저 식별해야 한다. 클래스는 단지 객체들의 특성과 행위를 정적으로 표현하는 추상화 도구일뿐이다. 문제는 클래스보다 객체를 우선시한다고 해결되지 않는다는 것이다. 객체들의 속성과 행위를 먼저 식별해야 한다는 말을 개별적인 객체에 집중하라는 의도로 오.. 2021. 8. 18. 객체지향의 사실과 오해 - 메시지와 메소드 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 책임 객체는 다른 객체로 부터 요청을 수신하였을 때 이 요청을 자율적으로 처리할 수 있는 존재여야 한다. 그리고 이때 객체가 처리하기 위해 수행하는 행동을 책임이라고 부른다. 앞의 역할,책임,협력 글에서 왕은 모자장수에게 '증언하라' 는 메시지를 전달했다. 메시지는 수신자의 책임을 암시하므로 모자장수는 증언해야할 책임이 생긴다. 왕은 모자장수가 증언만 수행할 수 있다면 어떤식으로 하든지 방법에는 신경쓰지 않는다. 말이나 글로 혹은 영상 녹화본이 있다면 영상을 제출할 수도 있다. 만약 왕이 모자장수에게 요청하는 내용이 아주 세부적이라면 어떻게 될까? 간결하게 '증언하라' 라고 요청했을 때와.. 2021. 8. 16. 객체지향의 사실과 오해 - 역할, 책임, 협력 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 협력 협력은 한 사람이 다른 사람에게 도움을 요청할 때 시작한다. 요청받은 사람은 일을 처리한 후 요청자에게 응답하는데 만약 자신이 혼자서 처리할 수 없는 일을 맞이하면 다른사람에게 요청한다. 이처럼 협력은 다수의 연쇄적인 요청과 응답으로 구성되어 있다. 이상한 나라의 엘리스에서 하트 잭은 파이를 훔쳤다는 혐의로 재판을 받는다. 판사 역할을 맡은 왕은 토끼에게 증인을 부르라고 명령한다. 모자장수가 증인으로 등장하고 증언을 마친 후 퇴장한다. 이렇게 하트 잭을 재판하는 과정은 일종의 협력이라고 볼 수 있다. 위의 다이어그램은 재판의 과정을 도식화하여 나타낸 UML 협력 다이어그램이다. 재판.. 2021. 8. 13. 객체지향의 사실과 오해 - 타입과 추상화 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - Javascript 프로토타입 상속: https://developer.mozilla.org/ko/docs/Web/JavaScript/Inheritance_and_the_prototype_chain - 추상화와 복잡성 초기의 지하철 노선도는 실제 지형을 참조한 곡선의 경로와 역간의 위치 거리 등의 정보를 충실하게 반영했었다. 하지만 현재 노선도는 직선 형태이며 역간의 거리도 실제 거리와는 무관하다. 그럼에도 목적지까지 이동하는데 불편함이 없다. 추상화의 본질은 사용자의 목적을 달성할 수만 있다면 복잡한 정보를 제거함으로써 본질을 드러내게 하는것이다. 복잡성을 다루기 위해 추상화는 두 가지 .. 2021. 8. 12. 이전 1 2 다음
