近況分享
先前有寫過好幾篇文章關於編程、電腦科學的相關知識，但其實都有點失敗，因為它們都嘗試用教學、教程的方式去整理，然而畢竟我根本沒有時間去持續整理出有脈絡的系列文章，大多寫作時間都是碎片化的。再加上先前的文章都對文章主題的分類都有點太細了，但很多內容其實都是跨主題，整理難度有點太高，正確的做法不應該用分類(Category)，而應該用標籤(Tag)才對，因此之後的相關內容都乾脆放在這個《編程101》的系列文章裡，而且會回歸到一些更隨筆性的、思考性的內容。
數據
已故Pascal的原始開發者Niklaus Wirth曾着有一書，名叫《Algorithms + Data Structures = Programs》，意指一切程式都是由演算法和數據結構組成，實際上所有的程式，簡單至一個Console App到一個上十萬行Code的遊戲，都是由數據和運算數據的演算法組成的。包括像是怪物的血量、獲得物品的機率等都是數據的一環，而攻擊後減少的血量、計算是否成功獲得物品則是演算法的一環。
而有趣的是實際上所有的演算法，或者用更簡白的語言—所有的指令實際上在電腦的角度而言，同樣都只是儲存起來的數據，例如在x86/x64架構的組成語言裡的JMP，在Opcode上其實就只是16進制的FF再加上/4的Notation而已，本質上也是一段數據。
記憶體
既然數據如此重要，那便要有一個位置把這一切數據進行儲存，而且還要可以快速獲取和修改，那地方便是RAM(Random Access Memory)。
單例
然而，記憶體雖然確實能實現快速獲取和修改，但當我們從理論回歸到開發的現實上卻有一個巨大的問題，那便是在記憶體裡的數據根本不知道其他存在於記憶體裡數據的真實身份，例如有一段數據是角色的攻擊力，而另一段數據是敵人的血量，但在電腦的角度而言，無論是攻擊力、血量、哪怕是那些無意義、未被佔領的記憶區塊都是差不多的存在。
可以想像躺在記憶體裡的數據們，其實就像是寒武紀前的生物一樣沒有什麼有效的對外感官，就像生活在一個黑暗森林，彼此不會知道對方的位置、樣貌，當你告訴生物A要去攻擊生物B時，它也理所當然的不會知道要如何才能攻擊到生物B。
此時此刻有兩種做法，一是為每一個記憶體裡的數據都加上「其他生物位資訊」，但這是不切實際的，這需要多用到的數據量有多大簡直都難以想像，那二便是為記憶體裡的數據蓋一個中央轉換站，而那便是所謂的單例(Singleton)。因此實際上所有的程式都一定會用到單例，差別單純只是單例在程式裡的呈現方式皫不同罷了，像是什麼Event Bus、Physics Engine、本質上都是一個單例，Event Bus裝的是事件的數據，而Physics Engine裝的是各個物件的位置、速度等向量數據。