Laying a Foundation
좋은 그래픽 디자인은 색,질감,형태를 잘 이용하므로서 페이지에서 나올것 같은 이미지를 만든다.이와같이 좋은 추상화,잘만들어진 오브젝트,전체적으로 잘된 구조는 좋은 오브젝트 디자인을 만드는데 요구된다.


(1)A Process for Finding Objects

1.초보자의 오브젝트를 찾기 위한 초기전략
  1)시스탬을 위한 요구사항들을 글로 써라
    -underline 명사는 object
    -underline 동사는 method
  2)This strategy is inadequate because finding good objects involves
    finding abstractions that are going to be useful for your application.
    (해석이 잘안됨..ㅡ,.ㅡ;)
    -몇몇의 추상화되 개념은 실제세계를 반영하지 않을수 있다.
    -비록 우리가 domain concepts에 포함했더라도 어떻게 전체적으로
      어플리케이션에 적절히 사용할수 있는지 결정해야한다.
2.하지만 체계적으로 할수 없는것을 의미하는것은 아니다.
  1)우리는 아래를 통해 오브젝트를 찾을수 있다.
     -우리의 어플리케이션 도매인의 지식
     -우리의 어플리케이션 동작에 대한 지식
     -패턴과 같은 다른 디자이너로부터 학습된 내용
     -우리의 지난 디자인 경험

(2)The process

   1.간단히 디자인 이야기를 적어라
     :어플리케이션의 대해 중요한것들을 기술해라
   2.몇몇의 주요핵심을 적은 이글을 이용하여 어플리케이션을 위한 주요쟁점을
     기술해라
   3.각주제를 구성하고 있는 후보오브젝트를 찾는다.
   4.각 후보 오브젝트들이 주요domain concept을 나타내는지 확인하다.
   5.주요domain concept과 연관되어 에플리케이션에 돕고있는 후보자를 찾는다.
   6.각 후보 오브젝트의 이름을 짓고,묘사하며,특징을 짓는다
   7.후보오브젝트를 조직화해라
     :같이 문제를 해결할수 있는 오브젝트 클러스터를 찾아라
   8.각각의 오브젝트들이 적절한지를 다시 체크해라
   9.각각의 오브젝트를 결정하기 위한 이유를 정해라
   10.찾는것이 느리다면,책임과 협력을 찾는것으로 움직여라.

(3)Discussion

   1.다시 말하지만 이것은 순서적으로 진행되지 않는다.
     너는 한번에 몇단계를 넘을수 있고,몇몇의 오브젝트를 버릴수 있고
     다시 시작하는등 순서적으로 진행되지 않는다.
   2.Wirfs-Brock and McKean는 design story부터 하라고 권한다.
   3.그리나 여기의 목표는 너의 시스탬을 기반으로 기초적인 추상화개념이 나타내어
     초기 오브젝트를 구성하는것이다.

(4)Find Object First

1.너의 첫번째 후보 오브젝트는 중심 오브젝트이거나 역활을 가져야한다.
     1)후보 오브젝트는 smart해야한다.
       -그들은 시스탬에 어떤일을 한다.
       -뿐만아니라 그들은 너의 시스탬에 대해서 알고 있는것들이다
        그러나 그들이 알고 있는것에 대해서 일을한다.
     2)그래서 그들이 책임과 그들의 관계가 명확할때 첫번째의 명확한 역확을 가진
       다른 오브젝트를 찾는다.
2.너의 디자이인에서 연관된 키를 이해하고 중심오브젝트를 충분히 가진뒤에
     클래스와 인터페이스를 찾을것이다.
      1)일반적인 속성과 행동 그리고 일반적인 책임을 갖는 오브젝트가 무엇인지를
         명확히 해라

(5)Getting Started : Design Story

1.보다 쉽게 오브젝트를 찾을수 있게만든다.
     :너의 어플리케이션에 대해 stroy를 쓰는것은 쉽게 후보 오브젝트를 찾을수있는
     프래임워크를 만든다.
     1)이것은 적절하게 후보오브젝트를 정의할수 있게 하고 너의 story에 다양한
        관점을 제공한다.
     2)story는 오직 기술적것을 포함하지 않는다 하지만 아래 디자인은 소프트웨어에
        대한 관점을 가지는 목표들 있다.
       어떠것이 좋은 것인가?,하기위해 무슨 노력을하고 있는가?불확실한것들은
       무엇인가?
        -다양한 소스들,유즈케이스나 다른 요구사항,시스탬 아키택쳐,사용자들 등
          로부터 정보를 취합하도록 노력해라.

(6)Design Stroies : How to do it

1.대충 글을 써라:많게나 적게 한단락으로
     1)많은시간을 들여 정정하거나 다듬지 말아라
     2)어플리케이션의 특징은 무엇인가? 무엇을 해야하는가?
     3)실세계와 연결되어있는가?
     4)전에 비슷한것을 해본적이 있는가?
2.만약에 사람이 많은 디자인 팀이라면
     1)먼저 너의 자신의 이야기를 적고 다른사람들의 이야기와 합쳐라
3.각 이야기의 중요한 주제를 정의하도록 노력해라.

(7)Search Strategies

   1.디자인 스토리들은 후보자를 찾기위해 이끌어준다.
   2.후보오브젝트는 아래 카테고리들중 하나에 속할것이다.
     1)시스탬을 실행하는 일을한다.
     2)바로 영향을 미치거나 연결되어 어플리케이션에 일을한다.
     3)information은 소프트웨어를 통해 흐른다.
     4)making,control and/or coordination 활동들을 결정한다.
     5)Structure 과 그룹화된 오브젝트
     6)도메인 영역들
   3.위 카테고리말고 남아있는거은 무엇인가?

(8)Role Stereotypes

1.토론하기 전에,오브젝트는 명확한 역확을 가지고 있고 그역활은 대부분
   stereotypes과 매치될것이다.
     1)만약에 시스탬을 실행되도록 일한다면 , service provider를 찾아라
     2)시스탬 다른시스탬과 연결되어있다면, interfacers를 찾아라
     3)시스탬의 많은 이벤트를 관리한다면 ,controller를 찾아라
     4)시스탬의 많은 정보를 조작한다면, structure를 찾아라

(9)What's in a Name

1.후보 오브젝트는 명확한이름이 필요하다.
     -오브젝트의 이름을 말할때,디자이너들은 오브젝트의 역활에 대해서 무엇인지를
       예측할수 있어야한다.
2.오브젝트의 이름은 책임들의 적절한 이름으로 만들어야한다.
3.Wirfs-Brock 과 McKean은 후보 오브젝트이름을 정하는 몇가지 교수법을 알려준다.
     -한 어플리케이션에 동시에 복잡한 naming systems을 존재하는것을 적었다.

(10)Naming Heuristics

1.일반적인 이름을 선정해라
      1)책임들의 일반적인것과 행동들의 특별한 점을 둘다 고려한다.
        -Calendar vs. GregorianCalendar vs. JulianCalender
2.이름에는 오직 두드러지거나 표출된 사실들을 포함한다.
     -Timer vs.MillisecondTimerAccurateWithinPlusOrMinusTwoMilliseconds(x)
3.service providers들은 worker이름을 짓는다.
     -StringTokenizer, SystemClassLoader, AppletViewer, etc.
4.이름이 책임들은 폭넓게 가지고 있으면 추가적인 오브젝트를 적용한다.
     -AccountingService는 유용한 이름이긴 하지만 실질적으로 더 특징적인 서비스들로
      바꾸어져야한다.->PaymentService or TransferFundsService
     -일반적인 이름을 유지하기 위해서는 최소한 3가지의 특별한점을 생각해야된다.
       반면에 이름을 잊어버릴수있다.
     -전체의 지나치게 제한하는 않는 충분한 의미를 전달하는 이름을 골라라,
       이것은 마술이다.
5.현재 디자인 context에 적당한 이름을 골라라.
6.이름을 중복해서 쓰지 말아라
     -비록 OO언어에서 지원하긴하지만 쓰지말아라.
7.형용사를 추가하거나 유사어을 이용하여 이름의 중복을 피해라
8.빠르게 이해할수 있는 이름을 골라라.

(11)Describing Candidates

1.CRC카드를 이용하여 후보 오브젝트를 묘사해라
     -이름,description, role stereotypes 기록해라
2.후보오브젝트를 묘사할때는 패턴들을 사용해라

(12)Connecting Candidates

1.클러스트된 후보오브젝트들은 새로운것들을 찾고 명확한것을 정한는데 도움을 준다.
2.새로운 시야로 클러스트된 후보오브젝트들은 재정렬하는것은 자유다.
3.아래와 같이 클러스트하도록 노력해라.
      -application layer
      -use case
      -stereotype role
      -object neighborhood
      -abstraction level
      -application theme

(13)Looking for Common Ground

1.지난번에 다른 후보오브젝트를 묶는것을 했지만 이번에는 공통점을 찾는데
   노력할 시간이다.
2.공통점은 너가 classes and interfaces을 정의하는데 도움을 준다.
3.전략
      1)공통적인 규칙과 강력한 추상화를 찾아라
        -Car, Boat, Bike, Tractor ! Vechicle
      2)적당한 추상화의 레벨을 찾아라.
        -ChessMove vs. PawnMove, RookMove, etc.
      3)공통역활로 대신할수 있다면 후보오젝트는 버려라.
        -Book, CDs, DVDs, etc. ! InventoryItem

(14)Defending Candidates

1.왜 각각의 후보 오브젝트 가치를 유지해야하는지를 말할수있어야한다.
2.아래의 예라면 후보오브젝트를 유지할수있다.
      -좋은 이름을 가졌다.
      -정의하고 stereotype이 있다.
      -유즈케이스에서 사용할수 있음을 보여주었다.
      -하나 나 둘의 책임을 가지고 있다.
      -다른 오브젝트가 이 오브젝트를 이해할수 있다.
      -비슷한 후보오브젝트 로 부터 분리됬다.
3.아래와 같은 경우는 후보오브젝트를 버려라.
      -다른 후보오브젝트와 책임이 겹치는데 그책임이 다른 오브젝트가 더 좋은때.
      -모호함을 가질때
      -scope의 밖을 벗어난것 같은때
      -디자인으로 부터 추가된 가치가 없을때
      -별거아니거나,별로 똑똑하지 않거나, 필요한것을 만들기위해 너무 많을때.

CRC Card
사용자 삽입 이미지

원글:Finding Objects
Posted by 전용우
,