最近在寫一個Side Project
發現自己的函式和類別能力好弱
在寫Side Project時
效率低
擴充能力差
要增加功能時經常要整個改寫
而且寫不太出
容易繼承的父類別
自己寫class去繼承別人的套件時
也挺有障礙的
想請教如何增進自己類別和函式的能力
或者有什麼好文章分享能讓我學習的
如何規劃好函式跟物件
真要教起來很多,但我就用比較簡單初階的小觀點先給你知道一下。
函式:
一般這邊我會規劃的東西,是與我的專案內不會觸到到他的資料或零件相關。
而是單純將一些重覆性常用的事。處理一個函式。
如:數字千位化、數字國字化.....等等轉換類的
不過,現在函式庫大多數已經不太需要再自已寫了
我目前自已寫的,也只有自已的加解密方式,跟隨機字元生成。還有生成自已的對應碼。
其它幾乎都是用原生的函式了。
物件(你說的類別)
這要先區分好功用還是零件。
一般來說,功用性的物件,我會將其叫做service。
零件式的就隨意了。
我這邊依簡單的db來說明
class DB {
protected $dbData;//處理資料的容器(只是例子)
public function __construct(){
$this->connect(???); //還需要一些判斷
}
//連線
public function connect($host,$dbName,$dbPassword,$db,$port=3306){
}
public function set(){} //設定
public function get(){ } //取得資料
public function add(){ } //加入資料
public function update(){ } //更新資料
public function delete(){ } //刪除資料
}
設計一個物件,先做好對應的規劃如何。單一性還是多重性。
多重物件中,要做好set的規劃。好能所有的東西都能對應。
如我上面的基本應用。其後4個方法,是所有db都會用到的。
再處理一個set,來決定要處理的db為何。
並在載入該物件時,就順便處理連線的問題。
這就是一般物件規劃要思考到的問題。
等先學好如何規劃單一元件的情況下。
再來決定繼承相關的規劃。
一步一步來
是比較想知道的是 >> 你是寫什麼 Side Project 內容來決定你的 "函式和類別能力好弱"??
自己創做的 函式 只是為了當初以需求而寫出來的,經過一段時間的累積後再將這些函式再進行大量的整理與 UPDATE 並整理好寫出 技術文件 等等,以做為參考或是做為下次專案再拿來使用,能夠下次再重覆的再使用的函式就是最好的函式。
資料前處裡
有兩個目標
一個是同樣相似的資料能套進去處理
第二個目標是
因為做資料科學
很多是try and error
想要產出不同的資料出來嘗試
但有時突然想到某些方法
有大部分相似的地方
但想加進去
卻要整個改寫
再來是直接設計多種參數調整
能產出不同的資料
容易撞牆
不然就是容易把程式寫死
如果以你所提到的幾點
但我提供的建議只會是在 "我的經驗上所碰到的" 來提供建議,但不一定是適合您,您可以參考看看...
我會以 "表單設計/電子表單" 來建議您設計方向,這方式提供了很多彈性化的資料串接的應用,如果您可以了解 JSON 的應用可以做到更多不同的應用方式。
電子表單設計是希望以 "由單位人員提供(需求) 從需求中去定義此表單的用途是什麼??" 再從定義好的資料內容再去轉換出其他的需求,像是人事、倉管 與其他零零種種的項目與系統來做為交換的條件與申請。從這些資料中去提取出相關資料再進行處理,應用層面廣泛並且透過這樣子的設計後續產生出來的表單(單位25個) 每年會產生 1.5 萬份的申請資料來進行處理的動作。
如果你可以設計 "交換資料" 的輸出入的話?? 每一個系統與 API 等等都會有交換的 "條件" 而條件是為了此次的服務所需要的內容來進行交換。那就可以先從資料本身來進行初步的處理,或著是您能從 資料庫/資料結構 先分析並轉換到 "符合你的需求" 來進行初步資料的交換條件。要交換的過程中,當然您要先了解到 "交換條件是什麼??" 才能夠先了解交換分析出什麼內容出來?? 並且有交換的以據等等...
所以這部份 "先了解您要的資料是什麼要拿到的是什麼,拿到之後要做的是什麼"??
"卻要整個改寫" ,您可以以版本號來做處理...
例如: A 表單版本號 1.0 輸人的資料內容為 "電子訂單" 但這訂單內容想再增加 贈品 的部份,在 A 表單 1.0 之下增加 "贈品表單" 並進行關連與前端設計師溝通設計出來輸入項目出來。 A 表單版本號會從 1.0 變成 1.1
所以輸入端會提供 1.0 版與 1.1 版的資料進來,當您碰到版本號為 1.1 版時只要針對 1.1 版的需求進行 "增加功能" 的設計即可,並不需要為一個需求改寫這麼多項目。只有不斷的累積下來,就算 1.1 版要下架也不會影響到後續的程序。 當然前端的輸入要先溝通與測試好才會穩定。
表單內容與欄位的設計,我會有 "用途、欄位名稱、欄位型態、輸入型態、資料內容"
用途:選擇 衣服 SIZE
欄位名稱:size
欄位型態:nvarchar(60) << 還是要有格式定義
輸入型態:SELECT
資料內容:Red|S,Red|M,Red|L,Red|XL,Red|2XL,Red|3XL
顯示內容:紅色 S,紅色 M,紅色 L,紅色 XL,紅色 2XL,紅色 3XL
導出結構
{
"version":"1.0",
"SIZE":{
"InBox_ID":100,
"InBox_RowsNAME":"nvarchar",
"InBox_RowsNumber":60,
"InBox_Style":"SELECT",
"InBox_Data":"Red|S,Red|M,Red|L,Red|XL,Red|2XL,Red|3XL",
"InBox_ShowInfo":"紅色 S,紅色 M,紅色 L,紅色 XL,紅色 2XL,紅色 3XL",
"InBox_Quantity":"1"
},
"Stock":[
{
"InBox_ID":100,
"StockNumber":"10"
}
]
}
導入資料
{
"version":"1.0",
"SIZE":{
"ID":100,
"Data":"Red|2XL",
"Quantity":1
}
}
--------------填加需求---------------------------
用途:贈品-贈送高級筆
欄位名稱:Gifts
欄位型態:nvarchar(60) << 還是要有格式定義
輸入型態:SELECT
資料內容:Red|1,white|1,blue|3
顯示內容:紅色,白色,藍色
導出結構
{
"version":"1.1",
"InputStructure":[
{
"SIZE":{
"InBox_ID":100,
"InBox_RowsNAME":"nvarchar",
"InBox_RowsNumber":60,
"InBox_Style":"SELECT",
"InBox_Data":"Red|S,Red|M,Red|L,Red|XL,Red|2XL,Red|3XL",
"InBox_ShowInfo":"紅色 S,紅色 M,紅色 L,紅色 XL,紅色 2XL,紅色 3XL",
"InBox_Quantity":"1"
},
"Gifts":{
"InBox_ID":101,
"InBox_RowsNAME":"nvarchar",
"InBox_RowsNumber":60,
"InBox_Style":"SELECT",
"InBox_Data":"Red|1,white|1,blue|3",
"InBox_ShowInfo":"紅色,白色,藍色",
"InBox_Quantity":"1"
}
}
],
"Stock":[
{
"InBox_ID":100,
"StockNumber":"10"
},
{
"InBox_ID":101,
"StockNumber":"20"
}
]
}
導入資料
{
"version":"1.1",
"Inputdata":[
{
"SIZE":{
"ID":100,
"Data":"Red|2XL",
"Quantity":1
},
"Gifts":{
"ID":101,
"Data":"red",
"Quantity":1
}
}
]
}
以上,前端輸入己經知道導入的結構是 1.0 版 會以結構內容寫出 html 來給於使用者進行選擇,接收到 1.1 版時也了解到結構是什麼,以同樣的方式提供選擇。結構與資料都己經了解了就會以 "導入資料" 將資料導向後端來進行處理。
後續就可以以 version 來做什麼動作,像是庫存量夠不夠或是己經沒這產品了。還有更細膩的設計就看您自己是要如何做了。
感謝分享
要增進無他法:多寫、多測、多失敗,從失敗中找出原因;
多看他人的code當然很快速,但看了自己如果不吸收,無用;
我看他人的code,主要是看他人的邏輯觀念,而非照抄原始碼,
自己想過,失敗中得到經驗,才是不二法門
以上個人見解
最近在寫一個Side Project
發現自己的函式和類別能力好弱
在寫Side Project時
效率低
擴充能力差
要增加功能時經常要整個改寫
而且寫不太出
容易繼承的父類別
自己寫class去繼承別人的套件時
也挺有障礙的想請教如何增進自己類別和函式的能力
或者有什麼好文章分享能讓我學習的
你需要的是讀書,你的問題在 Clean Architecture 書上都有解答。
我推薦你讀以下兩本書:
Clean Code: https://www.tenlong.com.tw/products/9789862017050
Clean Architecture: https://www.tenlong.com.tw/products/9789864342945
兩本都是必讀經典。Clean Code 跟這篇的問題沒什麼關係,但我推測你會問這問題代表你很可能沒讀過 Clean Code,而你會需要它的。