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

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

jquery插件的封裝

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

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

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

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

每個(gè)使用的地方就 new 一下好了：

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

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

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

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