天天看點

為什麼要學好資料結構和算法

資料結構:資料元素之間存在特定的關系

是一種抽象資料類型

資料結構如何影響程式設計?

解決實際問題時,搞清資料對象及其之間的關系後存入到記憶體中,讓計算機能幫助我們處理,資料是以何種方式存入到記憶體的,将直接影響我們算法的實作過程。不同的資料結構,不同的算法,帶來不同的執行效率!

學資料結構的目的:

1、解決問題的時候,能夠選擇最适合問題的資料結構(資料元素之間一一對應的關系,主要執行修改操作,元素個數已知,我們可以選擇順序表;又如,對資料對象的操作滿足先進後出,利用棧來存儲資料元素;又比如,我們的需求是頻繁的查找,此時我們可以将資料元素視為線性結構,一個個比對,也可以利用二叉樹在存儲資料元素的時候就為我們後續的查找做好鋪墊,為了利用高性能的算法而選擇二叉樹。而進階語言已經為我們實作好這些個現成的輪子,我們可以直接利用,将我們注意力放在業務邏輯的實作而不是相對底層的操作上),此時我們可能僅僅需要了解每一種資料結構的優缺點

引用:

作者:darkhorse pxf

連結:https://www.zhihu.com/question/29587605/answer/44895115

來源:知乎

著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請注明出處。

個人認為資料結構是程式設計最重要的基本功沒有之一!學了順序表和連結清單,你就知道,在查詢操作更多的程式中,你應該用順序表;而修改操作更多的程式中,你要使用連結清單;而單向連結清單不友善怎麼辦,每次都從頭到尾好麻煩啊,怎麼辦?你這時就會想到雙向連結清單or循環連結清單。學了棧之後,你就知道,很多涉及後入先出的問題,例如函數遞歸就是個棧模型、Android的螢幕跳轉就用到棧,很多類似的東西,你就會第一時間想到:我會用這東西來去寫算法實作這個功能。學了隊列之後,你就知道,對于先入先出要排隊的問題,你就要用到隊列,例如多個網絡下載下傳任務,我該怎麼去排程它們去獲得網絡資源呢?再例如作業系統的程序(or線程)排程,我該怎麼去配置設定資源(像CPU)給多個任務呢?肯定不能全部一起擁有的,資源隻有一個,那就要排隊!那麼怎麼排隊呢?用普通的隊列?但是對于那些優先級高的線程怎麼辦?那也太共産主義了吧,這時,你就會想到了優先隊列,優先隊列怎麼實作?用堆,然後你就有疑問了,堆是啥玩意?自己查吧,敲累了。總之好好學資料結構就對了。我覺得資料結構就相當于:我塞牙了,那麼就要用到牙簽這“資料結構”,當然你用指甲也行,隻不過“性能”沒那麼好;我要擰螺母,肯定用扳手這個“資料結構”,當然你用鉗子也行,隻不過也沒那麼好用。學習資料結構,就是為了了解以後在IT行業裡搬磚需要用到什麼工具,這些工具有什麼利弊,應用于什麼場景。以後用的過程中,你會發現這些基礎的“工具”也存在着一些缺陷,你不滿足于此工具,此時,你就開始自己在這些資料結構的基礎上加以改造,這就叫做自定義資料結構。而且,你以後還會造出很多其他應用于實際場景的資料結構。。你用這些資料結構去造輪子,不知不覺,你成了又一個輪子哥。

2、别人的輪子無法解決我們目前的問題,自己設計資料結構,這個時候,需要學習資料結構設計過程中思想。這次讀書學習的主要方向,學習設計資料結構的思想!

資料結構和算法不可分離的,特定的資料結構着對應特定的算法,他們相輔相成一同提高程式性能!

下面這個例子就想說,為了達到程式高效性從一開始就好好的選擇資料存儲方式。

什麼是資料呢? 你的鑰匙, 你的工卡, 你的銀行卡, 這些物品都可以看做是資料。 從這個意義上來講, 資料結構就是這些物品的擺放和存儲方式。

我有個不好的習慣, 喜歡亂擺放東西, 這件事已經被老伴罵過多次。 某天找工卡一直找不到, 浪費大半天時間。 最近又在找某張卡, 到處找, 又找不到。 經過反思, 我發現這些資料(鑰匙, 工卡, 銀行卡)的結構(放置方式)太糟糕了, 東邊一個, 西邊一個, 到要找它們的時候, 像個無頭蒼蠅。


   其實, 何不想想計算機科學中的資料結構呢? 根據需要, 資料有條理地存放着, 需要通路、取用它們的時候, 自然友善多了。 說白了:

   資料結構就是: 鑰匙、工卡、銀行卡等物品的存儲擺放方法。 做到井井有條可以友善後續查找和使用。

   算法就是: 查找、擷取、使用上述物品的方法。


   很多時候, 資料結構定了, 其對應的算法集基本上就定了。 是以, 在編碼中, 根據實際需求, 選擇合适的資料結構尤為重要。 而在實際生活中, 讓自己的物品井井有條, 用起來自然友善而容易, 提高了效率。
           

作者:stpeace

來源:CSDN

原文:https://blog.csdn.net/stpeace/article/details/47785555

版權聲明:本文為部落客原創文章,轉載請附上博文連結!

繼續閱讀