책임6 객체지향의 사실과 오해 - 기능과 구조의 통합 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 도메인 모델, 유스케이스 그리고 책임-주도 설계 시스템이라는 것은 사용자가 첫번째로 만나게 되는 객체이다. 사용자 입장에서 시스템은 자신과의 협력에서 자신의 요청을 처리하는 하나의 객체로 볼 수 있다. 시스템은 자신안에 더 작은 객체들을 갖고 있으며, 사용자로부터 받은 책임을 더 작은 객체들로 적절하게 분배해야 한다. 여기에서 책임-주도 설계가 등장한다. 유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 볼 수 있게 한다. 즉 사용자로 부터 처음으로 메시지를 수신하는 출발점의 역할을 한다. 그 이후에는 시스템이 안정적인 도메인 모델에 기반하여 기능을 수용하고 객체들로 책임을 분배한다.. 2021. 8. 28. 객체지향의 사실과 오해 - 역할, 책임, 협력 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 협력 협력은 한 사람이 다른 사람에게 도움을 요청할 때 시작한다. 요청받은 사람은 일을 처리한 후 요청자에게 응답하는데 만약 자신이 혼자서 처리할 수 없는 일을 맞이하면 다른사람에게 요청한다. 이처럼 협력은 다수의 연쇄적인 요청과 응답으로 구성되어 있다. 이상한 나라의 엘리스에서 하트 잭은 파이를 훔쳤다는 혐의로 재판을 받는다. 판사 역할을 맡은 왕은 토끼에게 증인을 부르라고 명령한다. 모자장수가 증인으로 등장하고 증언을 마친 후 퇴장한다. 이렇게 하트 잭을 재판하는 과정은 일종의 협력이라고 볼 수 있다. 위의 다이어그램은 재판의 과정을 도식화하여 나타낸 UML 협력 다이어그램이다. 재판.. 2021. 8. 13. 객체지향의 사실과 오해 - 협력하는 객체들 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - God Object: https://en.wikipedia.org/wiki/God_object - 개요 개발자나 설계자는 실세계의 사물이나 상황을 소프트웨어로 구현하고 사물의 속성과 행동을 클래스의 속성과 메소드로 구현하는것이 "객체지향적"이라고 생각하지만 실상은 소프트웨어와 실세계 사물간의 거리가 먼 것이 일반적이다. 그렇다면 컴퓨터공학을 전공하면서 지겹도록 듣던 붕어빵틀과 붕어빵은 도대체 뭘까? 엄청나게 똑똑해서 박사과정을 수료 하고 전공서적을 쓴 사람들은 헛소리를 한 것일까? 그것은 실세계의 모방이라는 관점으로 설명하는것이 객체 지향의 첫 발을 들여놓는 입문자들에게 객체 지향의 개념.. 2021. 8. 8. 설계원칙 - SOLID(SRP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 단일 책임 원칙은 가장 많은 오해를 사고 있는 원칙이다. 이름만 보면 마치 하나의 모듈은 하나의 일만 해야하는 것처럼 느껴진다. 하지만 이는 오해이다. 하나의 모듈은 하나의 액터(사용자 및 이해관계자)에 대해서만 책임져야 한다. 모듈이란 보통의 경우엔 소스파일이다. SRP를 위반하는 원칙들을 살펴보면서 SRP를 이해해보자. - 징후: 우발적 증복 급여 어플리케이션에서 Employee 클래스가 있고, 해당 클래스에서 calculatePay(), reportHours(), save() 메소드를 제공한다고 해보자. 이 클래스는 SRP를 위반한다고 할 수 있는데, diag.. 2021. 2. 10. UML - 클래스 다이어그램 고급 - 키워드, 책임, static - 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다. - 개요 사실 앞의 클래스 다이어그램편에서 언급한 표기법을 사용할 줄 안다면 이미 대부분을 사용하고 있는것이다. 고급편에서는 적절한 곳에 사용하면 유용한 그 외의 표기법을 소개한다. - 키워드 그래픽언어의 단점은 심볼을 모두 외워야 한다는것이다. UML에는 키워드라는것이 있다. 만약 모델링을 위해 UML을 사용하는데 비슷한 기호만 존재할 때, 해당 기호를 사용하고 키워드로 표시하면 사용자에게 해당기호를 어떤 의미로 사용했다고 어필할 수 있다. UML 인터페이스는 몸체가 없는 public 오퍼레이션만 정의되어 있다. 이것을 클래스의 특별한 타입이라고 본다면, 클래스 기호를 사용하고 키워드로 표시해주면 해당 의도를 표현할 수 .. 2021. 2. 10. UML - 시퀀스 다이어그램 - 동기, 비동기호출 - 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다. - 동기와 비동기 메시지 UML 에서 내부가 채워진 화살표는 동기 메시지를 나타내고, 선으로만 나타낸 화살표는 비동기 메시지를 나타낸다. 동기 메시지를 보낼 경우 호출하는쪽에서는 메시지가 끝날때까지 기다려야 한다. 반면 비동기메시지를 보낸 경우에는 응답을 기다릴 필요가 없다. 위 그림처럼 동기(sync) 라면 활성바가 생기며, 비동기(async) 라면 활성바가 생기지 않는다. - 시퀀스 다이어그램은 언제 사용하는가? 시퀀스 다이어그램은 1개 유스케이스에서 여러 객체의 행동을 볼 때 사용한다. 우리가 앞서 그려왔던 다이어그램을 보면 알 수 있듯이 여러 객체간의 협력을 보여주는데에 유용하다. 만약 여러개의 유스케이스에서 객체 .. 2021. 2. 10. 이전 1 다음
