di 和 ioc
di和ioc是差不多的概念。
乙個重要特徵是介面依賴，是把物件關係推遲到執行時去確定.
di是乙個初始化例項的過程，分為三種1.setter based 2.constructor based 3.inte***ce based,在spring 中就是應用前兩種;但又不僅僅是初始化例項，而且是運用介面的概念去實現這種注入依賴。靜態地看，只是依賴乙個介面，但實際執行起來，是依賴乙個實現了該介面的具體類。
ioc就是面向介面程式設計的應用
1.乙個通常的做法（非面向介面程式設計的方法），物件a依賴物件b，b會作為a的屬性，可以理解為a直接控制b;
2.ioc的做法，物件a依賴於介面c，而不直接依賴於實現了介面c的b，也就是a不能直接控制是哪個具體實現了c的b去做相應的事情，而是由我們控制可以由哪個實現了介面c的b去處理，也就是控制反過來了，是由b來決定了，而不是由a，實現就是面向介面程式設計。
aopaop是動態**的應用，將具體業務和相應的其它方面（比如日誌，許可權之類的）劃分開來，業務不會知道還有沒有其它的功能來輔助，需要的話我就給他加上乙個配置就可以，而不用去修改業務**。
原先是這個樣子
｛//日誌
//許可權
//業務**｝現在
｛//業務**
｝而許可權和日誌則寫在其它的類advice中，只要在配置中說明在呼叫業務方法時（或前，或後，或別的），呼叫一下advice就ok了。很容易把乙個方面，比如許可權或日誌從業務**中剝離出來。
在spring中，實現aop的流程如下：
1.定義業務介面
2.定義業務實現類
3.定義interceptor注入類
4.配置bean，設定class為proxyfactorybean
設定其三個屬性1.）proxyinte***ces為1
2.）interceptornames為3
3.）target為2
一點一點進步
requestparam,是獲取前端傳遞給後端的引數，可以使get方式，也可以是post方式。若前端傳遞的引數和後端接收的引數名稱不一致，則必須要標註。pathvariable,是獲取get方式，url後面引數，進行引數繫結。1.裝箱就是講基本資料型別轉換為包裝類，拆箱就是自動將包裝類轉換為基本資料...
想的多一點，想得少一點和想的大一點和，想的小一點
前幾天在江西的鯊魚回來了，公司整體開了個會，以來是歡迎這位coo的回歸，雖然我真的很不清楚coo是幹嘛的，但是目前了解到他的作用是管理客服和負責員工交流不暢的時候找他報告他來交流，別問我為什麼會知道後面這個職責，因為我和公司的ui鬧過彆扭，直接告到了boss那，然後鯊魚來交流了。哦對了，客服是我們b...
他們寫的，一點思考，一點敬意
技術的正宗與野路子 我們的大腦好比記憶體。既然是記憶體，就裝不下所有的知識。但應該能裝下對於知識的索引，否則我們便沒法工作了。啊，我的程式為啥卡住啦 本文簡答介紹在linux環境下如何利用gdb來分析卡住的程式，本文使用的python為cpython2.7。2019，能否解開時間的困局？通常在年初的...