qwerty

目標

一對多的依賴關係，當物件狀態改變時，所有依賴者會被通知

有一觀測工作站數據的物件，在數據異常時可以通知到多個平台(email, 簡訊, app)
且使用者可以自由調整各平台的通知設定

架構

• Subject: 主題
  • 當資料改變，就會通知觀察者
  • 新增/移除觀察者: Attach(Observer), Detach(Observer)
  • 通知觀察者主題有更新: Notify(data)
• Observer: 觀察者
  • 訂閱主題，以便在更新時收到通知
  • 觀察者收到通知: Update(Subject)

    分析

設計守則：盡量讓需要互動的物件的關係鬆綁

• 主題和觀察者鬆綁
  • 主題只知道觀察者有實作特定介面(Observer)，不用知道觀察者的具體類別
  • 任何時候都可以加入新的觀察者，且主題的程式碼不需修改

實作

• 觀察者之間彼此獨立，不可依頼通知觀察者的順序
• 主題可以控制改變的定義(如溫度變化超過1度)
• Push model/Pull model
  • Push model
    • 推送所有資料給Observer
    • Subject要知道Observer需要什麼，彈性較差
    • Observer會接收到不必要的資料
  • Pull model
    • 提供必要的資料或其來源(如data id或Subject本身)給Observer，由Observer自行取得相關資料
    • 每個Observer都要重新取得資料，效率較差
• C#的實作：委託，可看作對函數的抽象，是函數的類別
  • 委託物件所搭載的方法並不需要屬於同一個類別(即不需要Observer介面)
• 可以實作一個Subject管理員

用途

當一個物件的改變需要同時改變其他物件時

• 訂閱服務
• MVC架構: 後端資料更新、前端顯示資料
• UI操作: OnClick, OnHover
• 觸發事件

其他

RSS可取得所有資料，目前的社群網站則是使用通知(篩選並提供部份資料)

參考

• Wiki
• Head-First Design Pattern
• 大話設計模式
• 設計模式與遊戲開發的完美結合
• https://notfalse.net/10/observer-pattern

異體字

異體字為意思一樣、但寫法不同的字集合。
因為漢字在多個國家使用，每個國家的正式寫法不同，且在歷史中會出現字形改變的情形，自然字形也不同。

原文：C# Coding Conventions (C# Programming Guide)

最近發現 VM 和遠端主機的使用空間都太大了，找到一些相關處理方法

簡介

PTT 上常有支語警察

也常發現 google 翻譯的中文常常會翻譯成中國慣用語

所以就寫了一個支語警察的網站：支語警察

基本的 README 組成

• 一句話解釋模組的目的
• 簡潔可運行的範例
• 詳細的API文件
• 安裝說明
• 注意事項和限制
• 授權條款
• 必要的背景資料或連結
• 專業術語的資訊

因為mustache語法(雙大括號)會被判斷成render命令，改成全形符號

簡介

採用簡潔的模板語法來宣告式地將資料渲染進 DOM 的系統

1
2
3
4

<!-- html part -->
<div id="app">
  ｛｛ message ｝｝
</div>

1
2
3
4
5
6
7
8
9
10
11
12
13

//js part
var app = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue.js!'
    todo: []
  },
  methods: {
    reverseMessage: function () {
      this.message = this.message.split('').reverse().join('')
    }
  }
})

在 html tag 中 加入v-開頭的attributes以實作邏輯

不用免費架站服務的理由

若只是要純粹建blog，用github page + hexo 即可。

更簡單的方法就是用痞客邦、Blogger等免費部落格。

不過自架有以下優點

import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea – let’s do more of those!