胖蛋对《浮现式设计》的笔记(3)

胖蛋
胖蛋 (小撸怡情大撸伤身强撸灰飞烟灭)

读过 浮现式设计

浮现式设计
  • 书名: 浮现式设计
  • 作者: Scott L.Bain
  • 副标题: 专业软件开发的演进本质
  • 页数: 278
  • 出版社: 人民邮电出版社
  • 出版年: 2011-8
  • Chapter 2
    关于设计spacecraft的例子比衣橱的例子更好。
    ——————————————————————
    p18
    when we develop, follow the steps:
    analysis, implementation, testing.
    i always go straight to implementation part. need more analysis, not just a rough idea, but think in a design way and flexible way. making things work is the least good way.
    also think more and be more respective to testing.
    ————————————————
    p25, table 2.1
    Design decision driven by 3 types of forces:
    [Contextual forces] something about the subjective background/environment, something we can't change. Similar as background.
    [Implementation forces] based on the contextual forces, we may have to consider something when implementing it. To my opinion, this cannot be changed either.
    [Consequent forces] as its name suggests, the result, or what we should consider after used.
    ——————————————
    p26
    after we have the pattern, whenever we have the requirements from clients, we can:
    1, identify the problem
    2, find the patterned solution
    3, beware about certain things (as problems are not all the same)
    4, and seek for possible alternatives.
    2013-03-12 16:37:38 回应
  • Chapter 3
    p37
    Define the success of a software:
    1, on time
    2, within budget (cost)
    3, functioning as expected
    4, free of bugs
    5, valuable (getting used by clients)
    ——————————————————
    p40
    The following is NOT what we want to do:
    1, analyze the problem
    2, get the design on how to solve it with given constraints
    3, write the code based on the design
    4, QA
    5, release
    ++++
    BUT this is what we are doing... except the part where we demo-ed our prototype to VPs and then got the feature killed was probably not correct.... but I thought this is how it should be...
    The author says this is how engineers would do, but not for coders....
    Not yet finished but this is getting really interesting.
    2013-03-13 17:01:58 回应
  • Chapter 4
    p56
    The more difficult part is integrating the new code into the existing system instead of writing new code, which appears to be more fun and easier.
    p59
    an OO approach tends to replace code logic with object structure. Put another way, when you do things in an OO way, you usually end up with less code. Less code means less work, and less opportunity for introducing bugs during maintenance.
    p60
    Cons about the pattern: may create more object instances.
    Pros:
    * separate objects, encapsulated each other, so reducing side effects
    * '''strong cohesion''', easier understand and test.
    * client object is simpler and no need to understand which one to call.
    p61
    Question about Alan Shalloway's Law. Why at most N-1, and why N-2 for the author?
    p66
    Question:
    convert it to Spanish
    let's think about how to do it with Strategy pattern.
    A:
    have another Factory so that each message sender can use to get the correct language.
    p67
    Question: Chain of Responsibility pattern v.s Factory + Strategy pattern?
    A:
    so for Chain of Responsibility pattern, it's like an event-manager, multiply listeners will listen to the same event, but doing different things.
    While for Factory, each time only one instance will be created/constructed.
    2013-11-18 07:19:22 回应