Re: [請益] 菜鳥問一下大家的開發模式
※ 引述《a304035566 (jar)》之銘言:
: 剛轉職幾個月
: 公司是在做人事相關的系統
: 看前人留下來的專案看的頭很痛
: 不知道各位開發時會這樣嗎?
: 1.超多class 每個出來的資料都要用一個class去接
如果是物件導向設計的話都是用class
: 2.串接API
: 就是主專案寫一個class然後透過這個去調用API去抓資料回來之後再放到主專案的class: 去調用。
現在有db class還有DTO Class所以算正常了
: 3.專案下分超多方案
: 這個我不太會解釋
: 就是我連DB的可能會寫成一個方案
: 然後要接的Model再寫成另一個方案
: 每次要看要連哪一個跟要用什麼接都還要看在哪一個方案底下,然後每一個又有交叉參考我現在看的教學影片都分
DataAccess,Server,Business,Common,Model,Shared這麼多了
這還是教學用的
: 各位前輩這樣算是正常的嗎?
我只能說你就熟習習慣你公司的做法吧
業界還有更糟的事情
想當初在某家公司負責的專案
把.net webform當winform寫
整個網站一個function五千行
是要怎麼維護
你的問題算好解決的啦
--
※ PTT留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 150.117.88.42 (臺灣)
※ PTT 網址
→
你說的這些 全部加上I 然後99%都只有一個實作
→
啥意思?業界不是加上I不知道實作能幹嘛?
→
沒辦法 IOT就是要I的樣子
→
IOC
→
MSDN自己的DI範例都長那樣啦 interface一定加個I
→
就算現在只有一個實作也不保證未來不會改阿?
推
感謝b大文章分享
推
感謝b大
27
[請益] 如何快速用java寫出卡牌對戰遊戲對java的物件導向概念始終感到很迷茫,有點難想像class之間怎麼傳那麼多層,要怎麼傳過去,更遑論設計遊戲流程,看別人的code能看懂,但自己寫不太出來。 然而期末小組專題期限將近,要設計web畫面的卡牌遊戲,玩家與電腦對戰。 前端老師已經寫好,遊戲初始畫面我已經做好,但覺得寫得有點亂。玩家點擊卡片到移動攻擊、進階攻擊方法則還沒有,如果用js我有信心能做出來。 同學聽到我們組的情況有好心借我看她寫的部分的code。其實越看越emo,她的code寫的好乾淨。 其實具體也不知道要問什麼問題,目前想法是先把架構想明白再來開發,但是問題是想不太清楚需要再加哪些class,又需要給哪些功能,最難的還是知道資料怎麼流的,語法也不熟,感覺這兩天開發是學到了很多,已經不求寫完整,只求弄明白,我想只是需要有人能指引方向,感謝。28
[討論] 同一個程式碼段落超過一人以上在修改如題,好奇想問一下 基本上在有正常版控的條件下 這種情況是不是根本不該發生? 尤其是開發周期尚未結束,沒有要交接 每個人負責的部分12
Re: [心得]以策略模式重構switch case或if (影片)終於有空來加入討論啦~ 這邊有 markdown 好讀版: 這邊我也來提一下我的看法。為了閱讀方便我把一些 code snippet 複製在這邊: ```java= public double shippingFee(String shipper, double length, double width, double9
Re: [請益] 比物件導向更先進的程式設計思想?依照目前看CodeReview 大部分人寫程式的方式 其實都披著OOP的皮 寫不是OOP的程式 甚至還看過很愛嘴別人的主管7
[討論] 在 .NET 使用 Pythonnet 的應用情境板上各位大大好 最近工作有接觸到 Pythonnet 想請教一下有使用過 Pythonnet 大大的經驗 我們部門軟體的核心架構是使用.NET ( UI, Custom Class, Custom Collection... ) 為了使程式外部化,將部分功能的模組寫在 Python3
Re: [請益] 比物件導向更先進的程式設計思想?喜歡換一個思考模式嗎?歡迎進入 FP 1. compose 是 FP 語言中的基石 (O) 2. stateless FP 語言原則上沒變數概念,等號兩邊是等價的 (O) 3. 可驗證/高度抽象化,FP 的 type system 往往比 oo 系列的表達力更強 (O) ---3
Re: [討論] 請大家聊聊靜態語言的缺點借題發揮一下:static typed for the win 不過還是先切題回答「靜態語言的缺點」: 在大部分常用的靜態語言中,的確可能出現 valid program 不好標注 type 的情況 不過到底有多難標注就完全看是哪個語言跟哪個版本了 -----3
Re: [心得]以策略模式重構switch case或if (影片)上回用 Java + IntelliJ 來重構一堆 if/else 的計算運費範例, 這次改用 C# + Rider 來重構一樣的例子,方便習慣 C# 的朋友參考與練習, 不過這次刻意改用 Func<T> 來當作 strategy 的實作內容, 以 function 來取代,省去 class + interface 的部份。 兩種作法適用場景不同,東西夠小夠單純,想要少一點 class/interface 等 elements,1
Re: [心得]以策略模式重構switch case或if (影片)原原 PO 用 interface 的好處是,shipper 有新的行為時。 可以很簡單的在 interface 加新的 function。 同時可以檢查有 implement Shipper 的 class 要加入新的 function。 感覺上,彈性更好。 缺點嘛... 如果 shipper 很多時每個都要再補 function 是比較累一點。