类别 全部

作者:余小章 's 6 年以前

1071

ALM-開發 for C#

物件導向程式設計強調物件的生命週期、狀態和行為,並且這些物件能夠被識別和管理。轉型是物件導向中的一個重要概念,允許物件在不同型別之間進行轉換。這可以通過隱含轉型或明確轉型來實現,如 Boxing 和 Unboxing 操作。良好的軟體開發需要一致的開發方式,通常採用分層架構,如三層架構。三層架構包括資料存取層、展現層和商業邏輯層,各層次分工明確,有助於提高系統的可維護性和可測試性。

ALM-開發 for C#

ALM-開發 for C#

結論

案例

釋放
隔離WebService
動態建立執行個體
Compare Object
Clone Object
StringBuilder
Exception
NLog
InnerException
理解例外堆疊
只有處理Message是不夠的

匿名

用一次就拋棄
匿名方法

擴充方法

傳值 vs 傳參考

傳參考
傳參考out

例:int.TryParse

由內部建立執行個體

傳參考ref

由外部建立執行個體

預設是傳值

關鍵字

Nullable
允許實質型別為null
params
一個方法只能有一個
要放在最後面
可變參數
dynamic
dynamic 型別可簡化對 COM API (例如 Office 自動化 API)、動態 API (例如 IronPython 程式庫) 及 HTML 文件物件模型 (DOM) 的存取。
dynamic 執行時期檢查,沒有 IntelliSense
var
不知道等號右邊的型別時使用
var 編譯時期檢查,強型別,有 IntelliSense
或稱右(後)決議型別
由等號的右邊決定型別;編譯器幫你決定的
用在區域變數
隱含宣告
partail
必須要同一個Namespace
類別 (Class)、結構 (Struct)、介面或方法的定義,都可以分割為兩個或兩個以上的原始程式檔 (Source File)。 每個原始程式檔都包含型別或方法定義的區段,而且所有部分會在應用程式進行編譯時組合起來。
struct
沒有建構函數
修飾詞
static

不能繼承

生命週期起始於應用程式

不需要new

成員修飾詞

override 覆寫基底類別的虛擬(virtual) 成員

new 明確隱藏繼承自基底類別的成員,或稱為遮蔽

virtual 允許在衍生類別中覆寫此成員

sealed 必須一律和 override 搭配使用 其衍生類別將無法再覆寫此成員

abstract 表示為抽象成員,此成員實做不完整,在其衍生類別中必須實做其 內容

類別修飾詞

sealed 類別 : 表示密封類別,此類別無法再被繼承

abstract 表示抽象類別,不具有公開建構式

存取修飾詞

protected internal

protect

internal (命名空間預設)

private (類別預設)

public

不能有靜態成員
可繼承多個介面
視為一種合約規範,抽象,沒有任何的實作

轉型

Boxing & Unboxing
例如:Datatable
效能損耗
System.Object與實質型別之間的轉換
轉型的方式
System.Object轉強型別

明確轉型

隱含轉型 先 is 再 as

System.Object轉實質型別
字串轉實質型別
為什麼要轉型?

元件的成員

Namespace
nest class
class

事件(event)

委派(delegate)

解構函數

建構函數(contructor)

屬性(property)

公開讓外部使用

靈活控制讀寫權限

set、get 方法

欄位(field)

一般而言不會公開

類別等級的全域變數

常數(constant)

編譯時期常數const

效能較好

可用在方法

數字跟字串

執行階段常數readonly

靈活性、方便性較高

任意型別

不可修改

應用程式等級的全域變數

方法(method)

方法宣告

不回傳 void

回傳 return

命名規則

正確的建立方案

元件參考
from Nuget
或是放在方案目錄下
正確的作法是把檔案加入專案內,然後參考專案內的檔案
不要參考磁碟的檔案,比如bin資料夾
建立專案

一致性開發方式

Framework
Log
EF
Value Object

Plain Old CLR Object(POCO)

Plain Old Java Object(POJO)

Data Transfer Object (DTO)

序列化

只有屬性,沒有方法

物件彼此之間資料傳遞方式

3 Layer

3 Layer 缺點

分層無法封裝所有的東西,例如因應需求要在前端介面增加 輸入欄位,必須要在表現層、商業邏輯層、資料存取層都做 相對應的修改

不合理的分層使得不同層次的程式碼耦合在一起,相依性增加,使得程式越來越難以隨著需求變更而進行相應調整

不合理的分層將會導致軟體開發品質下降

過多的分層會影響效能

3 Layer 優點

分流

IO瓶頸

網路

記憶體

平行開發

各層之間具有一定的"獨立性",維持之間溝通的介面不變,各層可以根據具體問題各自實作,而不需要其他層也必須做出相應調整

合理的分層有助於分工開發與維護,哪一層壞了就改哪一層

可提高抽換性、可維護性、可測試性

有利於標準化

可以將各層次間的相依性減到最低

以替換某一層的具體實現,只要前後提供的服務相同即可

3 Layer 職責

資料倉儲

Text

Excel

SQL

I/O

DataAccess Layer 存取資料 Repository/Data Access/Persistence/PO/DAO

Value Object 各Layer之間的資料模型定義

Business Logic Layer 商業邏輯,流程控制

Presentatioin Layer 展現層,使用者操作介面,介面的連動效果

Coding Stytle
資料庫設計原則
程式碼命名原則
OOA/OOD/OOP
物件設計原則

甚麼是物件導向

六大原則:SOLID
D:依賴反轉原則,抽象化。(Dependency Inversion Principle) 高層模組不應依賴低層模組,兩者都應依賴其抽象 抽象不應依賴細節 細節應依賴抽象
I:介面隔離原則,介面要特定目的、易懂、可再用性高。(Interface Segregation Principle) 客戶端不應該依賴他不需要的介面,類別間的依賴關係應該建立在最小的介面上。
L:最少知識原則,(Least Knowledge Principle, LKP),又稱狄米特法則(Law of Demeter, LoD) 一個物件應對其他物件有最少的了解。通俗來說就是我只要知道你提供這麼多public方法,其他我都一概不關心。
L:里氏替換原則,類別間的相容性。(Liskov’s Substitution Principle) 父類別能出現的地方,子類別就可以出現,而且替換成子類別不會造成錯誤或異常。
O:開放封閉原則,開放擴充、封閉修改。(Open-Closed Principle,OCP) 應該透過擴展來實做變化,而不是修改已有的程式碼來實作變化
S:單一職責原則,單一類別單一責任、低耦合 (Single Responsibility Principle,SRP) 用“職責”或“變化原因”來衡量介面或類別設計,也可以套用到方法
二大抽象
abstract
interface
三大特型
多型

特設多型 (ad hoc polymorphism)

強制同型 (coercions)

多載 (overloading)

運算子多載 operator

程序多載,同一個名稱但有不同的參數

廣義多型 (universal polymorphism)

參數式多型 (parametric)

泛型

繼承式多型 (inclusion)

繼承

.NET的繼承

多個介面

只能一個類別

繼承者擁有被繼承者的行為,靜態成員除外

封裝

隱藏行為、訊息不讓外界知道

甚麼是抽象化

沒有程式碼
分類的基本技巧就是抽象化
抽象化是為了降低複雜度,用較簡單的概念,讓人們能以綜觀的角度來了解。

甚麼是類別

定義物件的藍圖
透過分類將一群類似的物件抽象化

甚麼是型別

有幾個種類
實質型別

int、enum、struct、Nullable

記憶體放在stack

變數本身的內容就是物件

實作Syetem.ValueType

struct已經實作System.ValueType

反編譯int只看的到struct

匿名型別

使用情境:LINQ的select回傳

不需要先定義

參考型別

好多名詞

組合型別

複雜型別

強型別

記憶體放在Heap

變數的內容存放記憶體位置(指標)

實作System.Object

描述物件的類型

甚麼是物件

也可以稱為執行個體
能對自己負責
有生命週期,能夠被創造和消滅
有狀態和行為
可以被識別

不當設計的根源

在前人的架構上疊床架屋
大公司

為了穩定無法使用新技術,與業界脫節

分工細

過度分工,減弱創新力道

穀倉效應

人力派遣

雇主也很難把最核心的部份交給他,最後他最擅常的程式能力大約就是查詢、新增、修改、刪除。對於架構設計或是效能調校比較不擅常

對需求的不瞭解
網路上隨便抄一段,不求甚解, 程式碼會動就好
到處都是相似代碼
不是說不能抄,而是要了解這段程式碼的優缺點
對物件導向的基本概念薄弱
對API一知半解

常見的誤解

先求有再求好
Legacy Code越多,成本就越高
沒有限制,很容易失控

透過使用案例解套

程式會動就好
衍生技術債導致可能會導致成本增加

sdssdfsdfsf

Subtopic

小心不當設計所帶來的後果

使用者觀感不佳

打擊開發團隊,開發團隊士氣低迷

怨聲載道

資料不一致

系統不穩定

效能低落,無法優化

把共用的類別全部寫在一個類別,叫做OOP
OOP寫起來很花時間