三言兩語說透設計模式的藝術-簡單工廠模式
一、寫在前面工廠模式是最常見的一種創建型設計模式，通常說的工廠模式指的是工廠方法模式，是使用頻率最高的工廠模式。簡單工廠模式又稱為靜態工廠方法模式，不屬于GoF 23種設計
大家好，我卡頌。
最近尤大的一個推文引起了不小熱議，大概經過是：
尤大在推上的發言一直比較耿直，這次又涉及到React這個老對手，關注度自然不低。
再加上國內前端自媒體的一波引導發酵，比如知乎下這個話題相關的問題中的措辭是「怒噴」，懂得都懂。
在這樣氛圍與二手信源的影響下，會給人一種「大佬都親手下場撕了」的感覺，自然會引來React、Vue各自擁躉的一番激烈討論。
年年都是一樣的套路，毫無新意......
面對這樣的爭吵，我們應該做什么呢？
首先，回到源頭本身，尤大diss的有道理么？有。
React的心智負擔重么？確實重。比如useEffec這個API，你能想象文檔中一個章節居然有6篇文章是教你如何正確使用useEffec的么？
造成這一現象的原因有很多，比如：
當我們繼續往前回溯，「Hooks必須顯式聲明依賴」是「React更新機制」決定的，而「React更新機制」又是React實現原理的核心。
本質來說，還是React既往的成功、龐大的社區生態讓他積重難返，無法從底層重寫。
這是歷史必然的進程，如果Vue所有新特性都在Vue2基礎上迭代（而不是完全重寫的Vue3），我相信也是同樣的局面。
所以，當前React的迭代方向是 —— 支持上層框架（比如Next.js、Remix），寄希望于靠這些框架的封裝能力彌補React自身心智負擔重的缺點。這個策略顯然也是成功的。
回到這次爭吵本身，尤大不知道React文檔為什么要花大篇幅幫開發者避坑（以及背后反映的積重難返）么？他顯然是知道的。
他如此回復是因為他所處的位置是「框架作者」，React是他的競爭對手。設想一下，如果你的競爭對手在一些方面確實不如你，但他的用戶對此的反應不是“太難用了，我要換個好用的”，而是“一定是我用的姿勢不對，你快出個文檔好好教教我”
面對這樣的用戶，換誰都得有一肚子牢騷吧～
讓我們再把視角轉到「React的用戶」（也就是我們這些普通開發者）上。我們為什么選擇React呢？
可能有些人是處于喜好。但大部分開發者之所以用React，完全是因為公司要求用React。
用React的公司多，招React的崗位多，自然選擇React的開發者就多了。
那么為什么用React的公司多呢？這顯然是多年前React在先發優勢、社區生態兩場戰役取勝后得到的結果。
所以，我們需要尊重兩個事實：
兩者并不矛盾，他們都是歷史進程的產物。
Vue、React之間的討論，即使是從技術層面出發，最后也容易陷入“React心智負擔這么重，你們還甘之如飴，你們React黨是不是傻”這樣的爭吵中。
這顯然就是忽略了歷史的進程。
正確的應對方式是多關心關心自己未來的發展：
本文鏈接：http://www.www897cc.com/showinfo-26-58976-0.html當別人因為React、Vue吵起來時，我們應該做什么
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Go語言常見錯誤—將接口定義在實現方一側
下一篇： 詳解Rust編程中的生命周期
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號