人人網qq空間
前些時間我曾經翻譯過一篇叫做《這裡我說了算!》的文章,裡面作者講述了關於「命令,不要去詢問(tell, don』t ask)」原則:
我看到的最多被違反的原則是「命令,不要去詢問(tell, don』t ask)」原則。這個原則講的是,乙個物件應該命令其它物件該做什麼,而不是去查詢其它物件的狀態來決定做什麼(查詢其它物件的狀態來決定做什麼也被稱作『功能嫉妒(feature envy)』)。這篇文章裡有個很生動的例子,我至今記憶猶新:
if (person.getaddress().getcountry() == 「australia」) {非常的明了。今天我又看到乙個關於「tell, don』t ask」原則的文章,裡面提供了4個關於這個原則的例子,都很有價值。這違反了得墨忒耳定律,因為這個呼叫者跟person過於親密。它知道person裡有乙個address,而address裡還有乙個country。它實際上應該寫成這樣:
if (person.livesin(「australia」)) {
不好:
<% if current_user.admin? %>好:<%= current_user.admin_welcome_message %>
<% else %>
<%= current_user.user_welcome_message %>
<% end %>
<%= current_user.welcome_message %>
不好:
def check_for_overheating(system_monitor)好:if system_monitor.temperature > 100
system_monitor.sound_alarms
endend
system_monitor.check_for_overheating不好:class systemmonitor
def check_for_overheating
if temperature > 100
sound_alarms
endend
end
class post好:def send_to_feed
if user.is_a?(twitteruser)
user.send_to_feed(contents)
endend
end
class post不好:def send_to_feed
user.send_to_feed(contents)
endendclass twitteruser
def send_to_feed(contents)
twitter_client.post_to_feed(contents)
endendclass emailuser
def send_to_feed(contents)
# no-op.
endend
def street_name(user)好:if user.address
user.address.street_name
else
'no street name on file'
endend
def street_name(user)好的物件導向程式設計是告訴物件你要做什麼,而不是詢問物件的狀態後根據狀態做行動。資料和依賴這些資料的操作都應該屬於同乙個物件。user.address.street_name
endclass user
def address
@address || nulladdress.new
endendclass nulladdress
def street_name
'no street name on file'
endend
命令,不要去詢問!
不要去羨慕別人
有這麼一則寓言 豬說假如讓我再活一次,我要做一頭牛,工作雖然累點,但名聲好,讓人愛憐 牛說假如讓我再活一次,我要做一頭豬,吃罷睡,睡罷吃,不出力,不流汗,活得賽神仙 鷹說假如讓我再活一次,我要做乙隻雞,渴有水,餓有公尺,住有房,還受人保護 雞說假如讓我再活一次,我要做乙隻鷹,可以翱翔天空,雲遊四海,...
盡量不要去小公司
看到乙個論壇,乙個哥們發帖說去小公司被坑。2020年因為一時想掙快錢,所謂的 體現價值,結果能力水平不濟,快錢也沒掙到,反而因為裸辭降薪了。加上小老闆一言堂,有換崗被辭退的,也有試用期前一周被辭退的,重新重新整理了三觀。當然,好處是學會了ue4,不要急於體現價值,水平不行也體現不出來。這點要實事求是...
請不要去泯滅他們的夢想
軟體這個行業說好也好說壞也壞,曾幾何時 某某軟體工程師年薪百萬,但是曾幾何時 又是聽到某某程式設計師因工作勞累而致死的噩耗!面對這樣二重的壓力,如果對於你來說還是乙個剛步入職場的碼農or菜鳥 能有什麼感慨呢?先談談個人經歷吧!我一直是乙個比較自卑的人,而且不善於溝通,性格也屬於大多程式設計師那樣比較...