類別和方法結束後，今天要來說Access Modifier，存取修飾詞。
物件導向語言的三個特性，其中一個就是Encapsulation，封裝，就是沒必要公開的資訊就不要把它顯示出來。所以就開始了兩種Modifiers:

• public 類別可以供外界讀取到的屬性及方法
• Private 類別不可以供外界讀取到的屬性及方法

這個設計很重要，讓系統具備一定程度的隱私。但物件在使用時還是有像繼承或同系間的使用，因此每個語言間又會有一些不同的修飾詞，像

• protected 任何繼承的類別，都可以使用這個屬性或方法。算是半公開的修飾子：如果要用這個屬性，不能直接new一個出來：要創一個新的類別而且要繼承這個類別，變成自己人了才可以。
• internal C#獨創的一個修飾子，比protected還要嚴格：protected可以允許跨package/namespace，但internal必需要在同一個namespace繼承才可以。
• friend 差點忘了C++有這麼一個可愛的修飾詞，其實跟C#的internal一樣。

在我剛開始學物件導向的時候，這樣寫是不被允許的:

public class User
{
    public int UserId;
    public string Username;
}

有一派認為公開屬性是違反封裝原則，因為類別的細節被公開了，比較理想的寫法應該是

public class User
{
    private int _userId;
    private string _username;
    
    public string GetUsername
    {
        return _username;
    }
}

因為userId屬於不必要公開的資料，而username可以被讀取但不允許修改，所以會另外寫一個方法來讓讀取。
這個想法不能說有問題，但事實是愈來愈多的開發方法，會使用直接讀甚至寫屬性。

public class User
{
    private int _userId;
    // 可以直接讀Username, 但不能寫
    public string Username{get;private set;}; 
}

這個做法確實很考驗像我這種老頑固：真的可以嗎？沒有問題嗎？
這又要說回另一件事：就是物件之間的依存關係：兩個物件間相互間了解的資訊愈多，愈可能把彼此關係綁得愈緊，因此另一個比較好的解釋應該是decoupling(解耦合,脫鈎)：避免因為公開屬性的讀取造成兩個物件相互依存。

除了透過公開方法外，還有其他的方法嗎？有興趣的可以思考看看。

Access modifiers其實很重要，如果想精進開發能力，適時的運用不同的access modifiers：雖然public跟private就足以應付所有的情況，不過如果真的要發揮物件開發的能力，例如限制一個屬性或方法要如何被拓展，在繼承或使用時能不能更動裡面的屬性，或改寫方法...這些都是需要思考的。

鐵人賽進入下半局，不知道是不是寫的東西很生澀，所以沒什麼點閱，雖然覺得不意外，但其實這也正是我想做的。下半局的東西會開始進入和開發應用有關主題，敬請期待。