Re: [請益] 比物件導向更先進的程式設計思想？
依照目前看CodeReview
大部分人寫程式的方式
其實都披著OOP的皮
寫不是OOP的程式
甚至還看過很愛嘴別人的主管
寫著奇門遁甲的if else
只能說搖頭阿
多數的程式沒有要使用多型的跡象
版上的人一定會說
那是你公司爛阿
但本肥認真說還真的恭喜你
本肥在軟體業駐點到各種行業
再到目前歇腳的金融業
真的用OOP的
認真說不多
會運用GoF JavaEE的Pattern
還用錯的還不在少數
先不要討論有沒有新思維
真正落實OOP
才是目前台灣各產業資訊體系 軟體業
先跨出去的第一步
當然軟工當中的手段
也還是要落實啦
總歸一句
基本功才是神功
不要小瞧他了
-----
Sent from JPTT on my OPPO CPH1721.
--
OOP 還是算了吧，落實這個要幹嘛 = =
為什麼不落實？ 看來樓上是標準的能動就好工程師
事實上是一堆人連 SOLID 都沒聽過
我想問問 職場真的完全沒人看重 介面抽象嘛？
我以為是我非本科轉職 去的公司爛 才有一堆爛CODE
自己實力不足 去不到好公司 好奇知名公司也不管抽象化?
管抽象幹嘛 被爛 code 炸死的再換一個進來就好了阿
嗯 悲慘的就是對台灣的老闆來說 再洗一批便宜的牛肉就好了 再說抽象與多型 就我看到現在只有少數的公司 對於資料庫的設計 能夠曉得 ER Model和Class Diagram的差別 多數並沒有資料封裝 繼承 多型的概念 更遑論前端的Controller 明明做的都一樣 可以更抽象一點 大部分也還是一個Base Class 每個Controller繼承到底 然後理論上一個物件應該各司其職 但混著用的還是大多數
※ 編輯: jej (103.246.208.241 臺灣), 10/09/2020 14:16:23樓主這樣一說 讓我猶豫是否要繼續花時間研究 DDD
似乎花時間在刷題 比較可以去好公司
ER Model 和 Class Diagram 分不清也太扯了吧…？
真的不扯 可以請人把公司的資料庫設計 分別畫出他的ER Model 和Class Diagram 然後請他解釋這兩張圖 是不是幾乎一樣？ 甚至還會有人反饋回來 幹嘛畫Class Diagram 而且多的是套過架構 沒有深入架構讓他可以封裝繼承多型
另外最近意識到軟體業和資訊業是不同的，你是在資訊業
資訊業大多在開發內部營運用系統，鮮少程度好的人愛去
可以理解為 多數公司以資料庫驅動來專寫程式？
除非那是開發內部營運用系統產品的公司
既然程度好的不愛去，想去純軟賺更多那程式碼自然難好
而不是根據領域驅動開發程式
我認為若是去純軟駐點的話狀況應該會好一點吧
至少我最近接觸的純軟駐點不論設計或技術都滿新的
@x246libra 我猜他的意思是正規化做得不足？
或著那間公司能是用「單據」的思維在開發系統
而不是用工作流程的資訊流觀點在發展系統
以前公文或單據時代的資料欄位直接對應table欄位
然後你可能會看到一些正規化做得很奇怪的肥肥table
對應到系統 Entity 的時候就變成一個一個value object
於是才會得出「為何要畫類別圖？」的想法
想到這就覺得原PO看得清問題卻沒崩潰實在很強 XD
我一開始看到那種系統的時候覺得人生有夠灰暗 哈哈
回頭看發現自己講錯了 用工作流程的資訊流這說法不對
應該說那些公司可能只是作業電腦化，但沒重新設計流程
雖用電腦但流程沒變，只是資訊寫進電腦而非寫在單據上
如此一來物件導向做得差自然不令人意外
OOP是萬靈丹嗎？別人在檢討不要硬用OOP然後你在那邊要落
實
我知道反OO派 這讓我想到以前有個主管對我說過 與其誤用OO不如不用 甚至有些為了研究Pattern 走火入魔的也不在少數 反而增加維運上的困難
※ 編輯: jej (111.71.89.144 臺灣), 10/09/2020 15:05:05語言只是工具，C、perl、Java、Lua都有其各自擅長的特性
邏輯不好寫出一堆vulnerabilities的最會互相鄙視
「鄙視」是源自於對自身能力的不安全感 只好寄生在"語言"
"框架" "domain"等想像的共同體上來強化自尊 本質上是自卑
應該說...你見過的就只是會需要駐點的行業.自然不重視軟工
所有的選擇都是trade-off，沒什麼好比的
正確，看似很爛的科技在不同時空背景可能反而是首選
你在哪工作?
回某 x 如果所有你想要的就只是那種不需驗證的直覺的“
抽象化”，那你就繼續落實你的 Oh-Oh 吧
記得不需要看看外面的世界，然後要繼續把自己無法理解的
人都冠上一個讓你自己可以自嗨的標籤哦
然而這都只是理想 抽象用的好不好誰來定？ 我自己都
覺得如果底層都我自己寫的一定很精美摟 可惜現實上就
是一堆歷史共業摟
2
我個人主觀且偏見的覺得 OOP 不是聖杯，它只能管理一些些的複雜度，它雖好用但又沒那麼好用，它可以很容易跟其他技術結合在一起，所以起手式走oop 不見得不好，但也不用太過度期待用了能上天堂之類的 oop 就只是個工具，就像 solid 是個 guide（我也喜歡 solid，但現實世界總是不那麼美好），更別說是板上常見的 design pattern，我相信我們能從這些東西上面是可以學到一些東西，但也不用過度美化 如果真的要把程式寫好，我覺得練習寫能大量組合，無狀態，可驗證，又可高度抽象化的producedure，stateless，pipeline，wishful thinking programming 的方式會比較好，我反倒覺得這個聖杯存在很久了，只是很少人注意到 ----- Sent from JPTT on my Asus ASUS_I01WD.3
喜歡換一個思考模式嗎？歡迎進入 FP 1. compose 是 FP 語言中的基石 (O) 2. stateless FP 語言原則上沒變數概念，等號兩邊是等價的 (O) 3. 可驗證/高度抽象化，FP 的 type system 往往比 oo 系列的表達力更強 (O) ---6
OOP沒什麼不好啊 沒有OOP我們廣大的碼農們怎麼活下去 沒有OOP現在的軟體能發展成這樣嗎 每樣工具在其時代背景都有它的貢獻 沒有工具是完美的啊5
JavaScript 是一個基於原型(Prototype-based)的程式語言 在本質上很難將它歸類為程序導向語言，或是物件導向語言 類別： JavaScript 中沒有類別(Class)的概念，但是有物件(object)的概念 而這個物件概念的物件，則是以GUI的 Widget為主![Re: [請益] 比物件導向更先進的程式設計思想？](https://img.youtube.com/vi/KlPC3O1DVcg/mqdefault.jpg "Re: [請益] 比物件導向更先進的程式設計思想？")
5
在討論oop fp 或任何概念之前 需要討論的是你的使用情境(context) 沒有context就只是在討論信仰 一開始沒有討論context，所以後面討論一定是到處互打，大家都覺得自己對 所以回這篇文的時候麻煩先描述想討論的contextX
國外反OOP的人不在少數 OOP 是萬惡之源 OOP is the Root of All Evil - Jeff Ward OOP 是爛東西![Re: [請益] 比物件導向更先進的程式設計思想？](https://img.youtube.com/vi/748TEIIlg14/mqdefault.jpg "Re: [請益] 比物件導向更先進的程式設計思想？")
8
物件導向其實是很偉大的發明 不知道酸民有沒有注意到--- 建築的預鑄工法, 其實也是物件導向 先把牆, 梁柱預鑄好, 搬到工地組合起來就好 所以現在蓋房子都超快的8
阿 是不是什麼王Ｘ歸來、邁向Ｘ手之路、拉近和Ｘ神之路、最強入門邁向Ｘ手之路之類的書？還是有附插畫的那種？ 或者某些業者或教學單位新花樣, 賦予新名詞之類的，例如： 後Ｘ情時代、ＸＧ製造、智Ｘ製造、Ｘ捷開發、Ｘ石開發、Ｘ布開發、Ｘ端工程師、Ｘ個月轉職、Ｘ經驗工程師。 我覺得我地圖砲開太大ＸＤ，「完全取代」根本比不上「相容舊版」來的有用，薪水也不會比較多。3
幾個迷思 很多人會講C沒有OOP 實際上C有 OOP是一種paradigm 本質上還是工程師的抽象化能力 有OOP思想的人去寫C 就會有OOP的味道 腦袋裝義大利麵的寫C++還是Java C# Swift 出來都是義大利麵5
近 : 幾十年來，從來沒有比物件導向實現更先進的程式設計實現在新程式語言中全面取代物 件 : 導向思想。 : 上面是某程式語言教學書看到的
35
[心得] C#基礎名詞解釋會發這篇文主要是面試被洗臉 我都會做啊 但我就不會解釋啊 雖然是寫給自己看的 但就分享出來吧![[心得] C#基礎名詞解釋](https://s0.wp.com/i/blank.jpg "[心得] C#基礎名詞解釋")
38
Re: [討論] 怎樣算是一個合格的junior cpp programme個人淺見，這點不見得是必要的，template 的 code 常常不好讀不好除錯 正確使用能寫出高彈性高效能的程式，但用過多維護跟閱讀起來會很痛苦 即便不用 template，日常大多數的事情都還是可以完成的， 如果是多人一起維護程式，有時為了提升可讀性，反而會避免太炫麗的 template 技巧 新人的話推薦不妨投資點時間，學習如何改善可讀性和與別人協作20
Re: [分享] 用一個簡單的數學公式來幫忙設計OOP類別先講結論: 我反對原文的結論「OOP易學難精」 就我個人到現在的感受是「難學易精」 為什麼呢? 以下分享個人看法![Re: [分享] 用一個簡單的數學公式來幫忙設計OOP類別](https://i.ytimg.com/vi/KIto1OQxwsY/maxresdefault.jpg "Re: [分享] 用一個簡單的數學公式來幫忙設計OOP類別")
13
Re: [請益] 多型用在哪本魯 OO 不太好 但你這例子多型嗎 這就只是子類別繼承父類別的屬性吧 多型比較像這樣吧 class DataLoader {4
Re: [請益] 多型用在哪ㄛ現在ㄉ想法4 沒有多型 只有介面 多型的用例之一 for(auto p_actor : actors) p_actor->act() 對ㄛ來縮 p_actor實際上到底是什麼 並不重要