很多人念了生物，甚至是分子生物學
但是都不知道DNA，RNA跟protien之間到底是什麼關係
這篇就是用簡單的比喻來說明他們的關係

---

先來引用一下維基百科的圖

常常我們說DNA是生命的藍圖，DNA其實是"這種分子"的名字
不如我們把細胞想成是一台車子，DNA就是這台車子的設計總藍圖
他很大很大一張，裏面寫滿了各式各樣車子零件的設計圖還有要怎麼組裝起來
RNA就是從設計總藍圖 (DNA)上複製下來的某個零件的藍圖
protien就是根據零件的藍圖 (RNA)製作出來的零件本身

那我們開始囉~~
DNA要轉錄 (transcription)成RNA，也就是把零件的藍圖從總藍圖裡抄寫出來
RNA polymerase佔了很重要的角色，因為他就是那個抄寫員
他會一字不漏的把DNA上的訊息都抄寫成RNA
接著呢在他開始抄寫的時候，會在零件藍圖的開頭加個註記 (capping)
在他超寫完畢的時候呢，會在零件藍圖的結尾加個註記 (polyA tail)
加上這些註記之後，就可以避免這張藍圖被回收人員 (RNase)當成垃圾清掉
大家以為到這邊這張零件藍圖就算完整了嗎
其實不是，這張藍圖還需要做客製化修改 (splicing)，修改的過程有點複雜
但是簡單的講，就是依據細胞目前的需求跟狀態，把RNA稍稍修改成他的設計
如此一來，零件藍圖 (messenger RNA)就算是完成了

那從零件藍圖 (messenger RNA)做成零件 (protien)呢
這位工匠就是ribosome (核醣體)大大拉~~~
這位工匠會依據RNA上的設計打造 (translation)一個新的零件
他把amino acid (胺基酸)抓來串起來成為peptide (胜肽鍊)
peptide只是零件的雛型而已，需要加以修飾才會變成真正的零件
這些零件的雛型會被送到細胞核外進行修飾 (post-translational modification)、折疊 (folding)

在DNA上纏繞著一些組蛋白 (histone)
他就像總藍圖的捲軸一樣，會把藍圖捲起來
如此一來，RNA polymerase這個抄寫員就無法抄寫 (transcription)某部份的藍圖 (DNA)
這樣細胞就可以依據環境的改變或是需求改變，去調整該製造出哪些零件
這個領域的學問被稱為epigenetics (表觀遺傳學)

我們都知道gene (基因)在DNA上，然而gene跟gene之間是會互動的！
這個我們稱為基因之間的互相調控，也就是當某些protien變得比較多的時候，他就會告訴gene不要製造這麼多出來，以達到一個平衡
我們再回到汽車零件的比喻，當我生產過多的螺絲零件 (protien)的時候，當然會覺得我用不到這麼多螺絲，所以會跟上游的
製造商溝通，要他們不要製造這麼多
所以細胞當中無時不刻都在進行這種溝通 (調控；gene regulation)

現在發現不只是protien會去調控基因，RNA也會調控基因
所以細胞就處於一種互相調控的網路當中，維持著平衡

如果我們可以了解細胞當中，各種分子是怎麼溝通的話，我們就有辦法去告訴細胞一些事情
例如避免細胞轉變成癌細胞等等事情

留言與分享

我們在日常生活中常常需要溝通
溝通之餘，如果有意見相左的情況，就會想要試著說服對方站在自己的立場
但通常我們以為的說服需要的是理性的力量
就是將事情條理分明的說明清楚，並且加以分析清楚
我們以為如此一來就可以讓對方站在自己的立場

這招有時有用有時沒用
畢竟人類相信一件事並不是因為理性或是邏輯而相信
人類的相信其實是建立在感情面上的

理性並不會讓人信服

你需要的是同理心的力量
同理心可以從感性的一面切入問題點

同理心vs同情心

(有空補)

留言與分享

很多初學java的人都會有這樣的疑問：

我該用類別, 抽象類別還是介面?

尤其在學 java 之前沒有碰過物件導向概念的人。
在多種選擇的情況下，我該用哪一個比較好呢？

我們可以分幾個觀點來看這個問題

概念解釋觀點

在物件導向的語言裏面，物件跟類別是被抽象化的概念。
也得力於這樣的抽象化，我們可以把某些東西廣義化應用到不同的層面。
這樣的抽象化有賴於封裝、繼承、多型的落實。
封裝可以將概念相同的程式碼放在一起，這些程式碼做同一件事，所以他們代表同一個概念。
同時也比較好維護。
繼承可以提高 reusabiity 的機會，同時也展現了概念上的相似性。
多型就是一種同中求異的概念。
位於同一個繼承體系之下，可以有不同的行為。

承續我先前寫過的文章
繼承是is-a的概念，而實作介面是has-a的概念。
這些概念是不相違背的，所以我們可以簡單的把類別、抽象類別、介面分開。
類別跟抽象類別應該位於繼承體系之下，因為抽象類別也有is-a關係。
但是相對於（具體）類別，抽象類別是不允許被實體化（instantiate）的。

為什麼？
舉個例，Cat 跟 Dog 都繼承於 Animal，因為 Cat is an Animal and Dog is an Animal.
這時我們會把 Animal 寫成抽象類別，因為 Animal 被實體化之後不具任何意義。
他只是我們在繼承體系上或是概念上的類別，他並不是一個具體的物件，不具屬性跟行為。
所以 Animal 不應該被寫成（具體）類別。

那不能被實體化的類別我還需要去定義他的屬性跟方法嗎？
當然要！
回到我們的例子，通常只要是 Animal 就會 eat()、move()，或是我想給 Animal id 或是 name。
這時我們不會把這些東西寫在 Cat 或是 Dog 裏面。
我們會把他通通寫到 Animal 裏面，如此一來下面的子類別就可以簡單的具有這些屬性跟方法了。

這時我們來講講介面，就如同我前面提到的。
介面的實作是has-a的關係。
所以他提供了在一個繼承體系之外的功能性。
他可以讓繼承於 Animal 的 Bird 擁有 fly() 的行為。
他可以讓繼承於 Animal 的 Turtle 擁有 swim() 的行為。
這些都是無法從 Animal 繼承過來的東西。

那無法繼承過來的話，自己寫就好阿，大驚小怪！
錯！
這時我們就會看到
會 fly()（飛）的 Bird（鳥）。
會 transport()（運輸）的 Airplane（飛機）。
會 swing()（拍翅膀）的 Swan（天鵝）。
但是他們想表達的都是在天上飛的概念。
所以介面可以達到統一格式的效果。
大家都實作同樣的方法來表達同樣的行為。
或許行為的實際內容不一樣，但是在概念上是相同的。

軟體工程觀點

在前一個觀點當中提到抽象化。
抽象化使得同樣的一段程式碼可以提高他使用的頻率。
也達到**reusability (重複利用性)**的效果。

我們有了繼承體系來提高 reusability。
在程式碼上，子類別不用重寫同樣的程式碼，只要從父類別繼承來就好。
相對於同樣的程式碼散落在各個子類別，當要維護的時候就要一個一個修改。
這樣父類別就控制了子類別的行為。
如果父類別的方法被修改的話，也會影響到子類別。

如果你不希望父類別的改變影響到子類別的話，這時請確認兩者是否真的要使用繼承關係。
如果是繼承關係但又不希望受影響，那就用多型吧！

我們使用介面來提高系統的flexibility (靈活性)。
當你需要有相同概念的方法時只要實作同樣的介面就可以達到。
同時規定同樣的介面便於管理維護。
只要實作同樣的介面就可以簡單地擴充模組。
這是一個靈活的系統該有的特徵。

相對於多重繼承 (ex. C++)

相對於C++的多重繼承，java 只允許單一繼承。
在多重繼承當中，可以讓一個類別擁有很多身份。
一個類別可以是很多種東西。
這樣的概念其實可以讓人容易了解這個類別在做些什麼。
像是Computer is a Machine and Computer is a Calculator.
這樣我們可以理解電腦是一種會計算的機器。
但是相對應的他也帶來一些不必要的副作用。
繼承於多樣的父類別，也同時繼承到了父類別的屬性跟方法，但是並不是所有的屬性跟方法都是有用的，甚至有些屬性或方法根本用不到。
當你沒有要使用到的時候卻又繼承了太多的東西，這就造成了另一種的設計不良的狀況。
這會讓別人誤解子類別有擁有父類別的某些方法，但卻不知道那是不應該出現的。
造成誤用問題就更大了。
這樣的問題小至程式錯誤，大至系統崩潰，這就成了系統的弱點之一了。

留言與分享

So far, I’ve touched or been familiar with several programming language:

Some I familiar with are Java, Python, Julia

Some I’ve played are C/C++, Haskell, Matlab, R, Perl, Lisp, Prolog, javascript, php

And took a lesson of Programming Language and Software Engineering

Read lots of book about Software Engineering…

Recall the basic programming lesson you’ve took

The quiz or exam would always be:

What does **** stands for?

or

Please write down a program to ****

Just some what like that…

But!

If you pass these kind of quizes or exams, can you say that you can program in this programming language?

As my aspect, a good programmer must understand what compiler says.

That is, an excellent programmer must know what happened while the compile error is thrown out

And he must have the ability to deal with it.

An excellent programmer must know about what will compiler act.

An excellent programmer must know how to tune the perfromance.

An excellent programmer must familiar with the basic syntax without the help of IDEs.

An excellent programmer must have some basic concept about hardware, at least the machine you’re using.

So…

If you think that you become an excellent programmer after taking some lessons of one language
And you cannot do above of these.

Well…

It’s still a long way to go.

留言與分享

自從在雙主修時修了軟體工程之後，一直受益於這個領域，而且最近也會看一些軟體工程的書。

覺得軟體工程強調的是彈性。

彈性

• 可擴充性 (scalability)：如何設計系統讓系統在擴充功能或是應用範圍變大的時候變得簡單
• 可移植性 (portability)：如何設計系統讓系統在不同的環境中也能夠順利運作
• 低耦合性及高內聚性 (low-coupling and high-cohesion)：如何設計系統讓系統內部的模組 (module)之間具有此項特質

可擴充性

就像是一個建築師可以好好的完成一間小屋子。

但是他有沒有辦法把小屋子延伸成摩天大樓？

或是已經完成的屋子能不能在添加其他的功能上去？

可移植性

同樣一張小屋子的設計圖，是否可以在不同的環境下建出同樣的屋子？

在沙漠中？在冰原中？在高山中？

如果可以，稱為可移植性。

低耦合性

小屋子當中的各個房間有不同的功能。

各房間通常是打通的呢？或是隔開的？

最好是不要把房間的功能都混在一起。

像是想在廚房看書然後就把廚房放個書櫃。

明明書櫃就該放在書房的，為什麼會出現在廚房。

或許可能會覺得這樣對使用者比較方便。

但是在軟體工程的角度來說，這是不好的示範。

高內聚性

小屋子當中相同功能性的東西最好都放在同一個房間比較好。

這個是相對於低耦合的良好示範。

那如何去決定哪些功能該跟哪些功能放在一起。

這就是工程師該去傷腦筋的了。

留言與分享