Re: [請益] 比物件導向更先進的程式設計思想？

[jej (賊一賊)]

依照目前看CodeReview

大部分人寫程式的方式

其實都披著OOP的皮

寫不是OOP的程式




甚至還看過很愛嘴別人的主管

寫著奇門遁甲的if else

只能說搖頭阿

多數的程式沒有要使用多型的跡象



版上的人一定會說

那是你公司爛阿



但本肥認真說還真的恭喜你

本肥在軟體業駐點到各種行業

再到目前歇腳的金融業

真的用OOP的

認真說不多




會運用GoF JavaEE的Pattern

還用錯的還不在少數




先不要討論有沒有新思維

真正落實OOP

才是目前台灣各產業資訊體系 軟體業

先跨出去的第一步




當然軟工當中的手段

也還是要落實啦



總歸一句

基本功才是神功

不要小瞧他了

-----
Sent from JPTT on my OPPO CPH1721.

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 103.246.208.241 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1602219798.A.AB5.html
推 CoNsTaR: OOP 還是算了吧，落實這個要幹嘛 = =
→ x246libra: 為什麼不落實？ 看來樓上是標準的能動就好工程師
推 tonytonyjan: 事實上是一堆人連 SOLID 都沒聽過
→ x246libra: 我想問問 職場真的完全沒人看重 介面抽象嘛？
→ x246libra: 我以為是我非本科轉職 去的公司爛 才有一堆爛CODE
→ x246libra: 自己實力不足 去不到好公司 好奇知名公司也不管抽象化?
→ Nitricacid: 管抽象幹嘛  被爛 code 炸死的再換一個進來就好了阿
嗯 悲慘的就是對台灣的老闆來說

再洗一批便宜的牛肉就好了



再說抽象與多型

就我看到現在只有少數的公司

對於資料庫的設計

能夠曉得 ER Model和Class Diagram的差別

多數並沒有資料封裝 繼承 多型的概念



更遑論前端的Controller

明明做的都一樣

可以更抽象一點

大部分也還是一個Base Class

每個Controller繼承到底

然後理論上一個物件應該各司其職

但混著用的還是大多數
※ 編輯: jej (103.246.208.241 臺灣), 10/09/2020 14:16:23
推 x246libra: 樓主這樣一說 讓我猶豫是否要繼續花時間研究 DDD
→ x246libra: 似乎花時間在刷題 比較可以去好公司
推 dream1124: ER Model 和 Class Diagram 分不清也太扯了吧…？
真的不扯

可以請人把公司的資料庫設計

分別畫出他的ER Model

和Class Diagram

然後請他解釋這兩張圖

是不是幾乎一樣？

甚至還會有人反饋回來

幹嘛畫Class Diagram



而且多的是套過架構

沒有深入架構讓他可以封裝繼承多型


→ dream1124: 另外最近意識到軟體業和資訊業是不同的，你是在資訊業
→ dream1124: 資訊業大多在開發內部營運用系統，鮮少程度好的人愛去
→ x246libra: 可以理解為 多數公司以資料庫驅動來專寫程式？
→ dream1124: 除非那是開發內部營運用系統產品的公司
※ 編輯: jej (103.246.208.241 臺灣), 10/09/2020 14:31:05
→ dream1124: 既然程度好的不愛去，想去純軟賺更多那程式碼自然難好
→ x246libra: 而不是根據領域驅動開發程式
→ dream1124: 我認為若是去純軟駐點的話狀況應該會好一點吧
→ dream1124: 至少我最近接觸的純軟駐點不論設計或技術都滿新的
→ dream1124: @x246libra 我猜他的意思是正規化做得不足？
→ dream1124: 或著那間公司能是用「單據」的思維在開發系統
→ dream1124: 而不是用工作流程的資訊流觀點在發展系統
→ dream1124: 以前公文或單據時代的資料欄位直接對應table欄位
→ dream1124: 然後你可能會看到一些正規化做得很奇怪的肥肥table
→ dream1124: 對應到系統 Entity 的時候就變成一個一個value object
→ dream1124: 於是才會得出「為何要畫類別圖？」的想法
→ dream1124: 想到這就覺得原PO看得清問題卻沒崩潰實在很強 XD
→ dream1124: 我一開始看到那種系統的時候覺得人生有夠灰暗 哈哈
→ dream1124: 回頭看發現自己講錯了 用工作流程的資訊流這說法不對
→ dream1124: 應該說那些公司可能只是作業電腦化，但沒重新設計流程
→ dream1124: 雖用電腦但流程沒變，只是資訊寫進電腦而非寫在單據上
→ dream1124: 如此一來物件導向做得差自然不令人意外
推 tsao1211: OOP是萬靈丹嗎？別人在檢討不要硬用OOP然後你在那邊要落
→ tsao1211: 實
我知道反OO派

這讓我想到以前有個主管對我說過

與其誤用OO不如不用

甚至有些為了研究Pattern

走火入魔的也不在少數

反而增加維運上的困難
※ 編輯: jej (111.71.89.144 臺灣), 10/09/2020 15:05:05
推 balaking: 語言只是工具，C、perl、Java、Lua都有其各自擅長的特性
→ balaking: 邏輯不好寫出一堆vulnerabilities的最會互相鄙視
→ drajan: 「鄙視」是源自於對自身能力的不安全感 只好寄生在"語言"
→ drajan: "框架" "domain"等想像的共同體上來強化自尊 本質上是自卑
推 alihue: 應該說...你見過的就只是會需要駐點的行業.自然不重視軟工
推 balaking: 所有的選擇都是trade-off，沒什麼好比的
推 drajan: 正確，看似很爛的科技在不同時空背景可能反而是首選
推 clamperni: 你在哪工作?
噓 CoNsTaR: 回某 x 如果所有你想要的就只是那種不需驗證的直覺的“
→ CoNsTaR: 抽象化”，那你就繼續落實你的 Oh-Oh 吧
→ CoNsTaR: 記得不需要看看外面的世界，然後要繼續把自己無法理解的
→ CoNsTaR: 人都冠上一個讓你自己可以自嗨的標籤哦
→ superpandal: 然而這都只是理想 抽象用的好不好誰來定？ 我自己都
→ superpandal: 覺得如果底層都我自己寫的一定很精美摟 可惜現實上就
→ superpandal: 是一堆歷史共業摟