前端什么時候會需要面向?qū)ο缶幊蹋?/h1>

現(xiàn)實開發(fā)中，基本不會自己寫個對象，封裝屬性和方法，基本上都是寫邏輯代碼（寫寫點擊事件，ajax請求之類的是最多的了）。不知道面向?qū)ο蟮膶懛▽嶋H運用的場景是哪些？還請各位大佬指點迷津。

1. 不知道你平時寫業(yè)務(wù)會不會用到框架，如果用了Vue、React、Angular，你基本都是在寫面向?qū)ο蟮臇|西。
2. 如果是前后端分離的項目，前后端的通信肯定是需要建立在同一的數(shù)據(jù)模型之上的，那么可以在前端嘗試用service的方式給前端組件提供數(shù)據(jù)，通常寫service會用到面向?qū)ο蟮木幊?/li>

1.這還是看題主項目大小，如果題主是自己一人做的一個小項目，邏輯簡單，直接寫邏輯代碼也是沒問題的。
2.如果題主公司要做個中大型的項目，多人合作開發(fā)，而且后期需求一般是不斷增加的，你的項目產(chǎn)品會不斷的迭代開發(fā)，代碼會越寫越多，一個JS文件里寫了幾萬行代碼，耦合性太高，不知道題主會不會覺得頭疼，出了BUG調(diào)試的時候是不是方便，找方法是不是快捷，增加一個新需求都要改文件里的好幾處方法中的代碼，新來的人屢邏輯都要好長時間。
這其中就涉及到代碼的可維護(hù)性，開閉原則，快遞調(diào)試定位BUG修復(fù)BUG等等問題，所以要用軟件工程學(xué)的方法和面向?qū)ο蟮乃枷肴ラ_發(fā)項目，其中涉及MVC,MVVM等模式,還有發(fā)布訂閱、命令模式等等多種設(shè)計模式實現(xiàn)項目的可維護(hù)性，可擴展性，出了需求可以寫新代碼，保證最小改動和新人接手知道項目遵循的基本思路，方便交接等等。
3.會了這么多框架和設(shè)計模式，還可以提高裝B能力…………

jquery插件的封裝

你可以抽空看一下啊我的一個jquery業(yè)務(wù)封裝的輪子 地址

你把你寫的所有代碼根據(jù)業(yè)務(wù)需求封裝成插件，然后不斷調(diào)優(yōu)。

假設(shè)你的頁面里有一個異步列表，他的主要功能包含1、異步請求數(shù)據(jù)，2、將相應(yīng)數(shù)據(jù)渲染到頁面上。這種情況直接把代碼邏輯寫頁面里沒什么問題。
之后，需求要在頁面里再加個異步列表，你會發(fā)現(xiàn)兩個列表代碼差不多嘛，不同的地方就是請求地址或參數(shù)不一樣，把第一個列表的代碼復(fù)制過來改下也可以。
一旦用到這個列表的地方變多，列表代碼的 copy 也變多。某天突然發(fā)現(xiàn)第一個列表里面有個 bug，那之后的 n 處 copy 就有 n 處 bug。改起來是會得黑眼圈的。
這時候，面向?qū)ο蟮膬?yōu)勢就出來了，所有列表相同的行為：請求數(shù)據(jù)、渲染數(shù)據(jù)都用對象的方法實現(xiàn)，不同的地方：請求地址或參數(shù)就用對象件用于區(qū)分差異的屬性來保存，這樣就有了一個異步列表的類了：

// 偽代碼
class AsyncList {
  url,
  params，
  getData(),
  renderData(),
}

每個使用的地方就 new 一下好了：

var list1 = new AsyncList(/* 參數(shù)啥的 */);
var list2 = new AsyncList(/* ... */);
// ...

后面相關(guān)的維護(hù)也只要修改 AsyncList 這一處就好了。

總結(jié)下：
當(dāng)你的代碼規(guī)模達(dá)到一定程度，且發(fā)現(xiàn)有很多需要封裝復(fù)用的代碼，這樣的場景下使用面向?qū)ο缶涂梢砸欢ǔ潭壬辖档痛a組織的復(fù)雜度。

面向?qū)ο筮€是要看場景，不要為了面向?qū)ο蠖嫦驅(qū)ο?/em>