筆者的 SAP 技術交流群裡，有朋友提問：

> 我想問一個很基礎的問題，為什麼類要有friend啊

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/69c5ac6d5e644ac48687fa8e1769b448.png#pic_center)

反正我工作這些年，在 SAP 生產程式碼裡沒用過友元，只是在生產程式碼的單元測試程式碼裡用過，原因也就是讓單元測試程式碼能夠訪問到被測試的生產類的私有屬性。

程式碼如下：

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/268950f00dde4e8390624c604cbf2804.png#pic_center)

SAP ABAP 的幫助文件：

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/6c1c466ca5974849972517295a3265a6.png#pic_center)

在物件導向程式設計中，封裝是一個重要的概念，它可以將程式碼組織成一些獨立的模組，從而提高程式碼的可維護性、可複用性和可擴充套件性。封裝的核心思想是隱藏物件的實現細節，只暴露出必要的介面供其他物件使用。在這種情況下，物件之間的互動只能透過暴露的介面來進行，從而實現了物件之間的隔離和保護。

然而，在實際的開發過程中，我們有時需要在物件之間共享一些私有資訊，以便更好地實現一些功能。這時，就可以使用 friend 機制來解決這個問題。friend 機制是一種物件導向的設計模式，它允許物件之間共享私有資訊，並且只有指定的物件才能訪問這些資訊。具體來說，friend 機制允許一個類將另一個類或函式宣告為其友元，從而允許友元訪問其私有成員。

在 friend 機制中，一個類將另一個類或函式宣告為友元，意味著它允許該類或函式訪問其私有成員。這意味著友元類或函式可以突破封裝的限制，直接訪問另一個物件的私有成員，這可能會破壞封裝性。此外，由於 friend 機制是一種特殊的機制，它不遵循常規的物件導向程式設計規則，因此使用它可能會導致程式碼更加難以理解和維護。

然而，雖然 friend 機制在某種程度上破壞了封裝性，但它也提供了一些好處。它允許一些密切相關的物件共享私有資訊，從而更好地實現一些功能。例如，如果一個類和另一個類緊密耦合，它們需要共享一些私有資訊以便更好地實現一些功能，那麼 friend 機制可以提供一種解決方案。此外，friend 機制還可以提高程式碼的可讀性，因為它可以幫助開發者更清晰地瞭解物件之間的關係。

儘管 friend 機制有一些優點，但在大多數情況下，應該避免使用它。如果物件之間需要共享一些私有資訊，通常最好的方法是透過公共介面來實現。如果兩個物件必須彼此知道對方的實現細節，這可能意味著它們之間存在過度耦合的問題，需要進行重新設計。此外，friend 機制的使用可能會導致程式碼更加難以理解和維護。

在物件導向設計領域中，封裝是一種將資料和操作它們的方法組合在一起的方式，目的是隱藏物件內部的實現細節。封裝實際上是一種資訊隱藏手段，它有助於提高程式碼的可維護性、可擴充套件性和可重用性。然而，當引入friend機制時，這種封裝性可能會受到影響。接下來，我們將從多個方面探討friend機制如何影響物件導向設計的封裝性，以及在某些情況下如何權衡這種影響。

首先，讓我們瞭解什麼是friend機制。在某些物件導向程式語言（如C++）中，friend關鍵字用於宣告一個類或函式可以訪問另一個類的私有成員和保護成員。通常，私有成員和保護成員只能被類的成員函式訪問，但是透過將一個類或函式宣告為另一個類的友元，我們可以允許這些外部實體訪問類的內部成員。

的確，friend機制在一定程度上破壞了封裝性。允許外部實體訪問類的私有成員和保護成員可能導致類的實現細節洩露，使得程式碼更難維護和擴充套件。在大型軟體專案中，這可能導致潛在的不穩定性和安全風險。

然而，儘管friend機制可能會削弱封裝性，但在某些情況下，它仍然是有用的。在以下場景中，使用friend機制可能是有益的：

1. 當兩個或多個緊密相關的類需要共享某些資料或功能時。在這種情況下，友元類或友元函式可以作為一種更簡潔、更直接的方式來實現這些共享功能，而不是透過公共介面暴露過多的實現細節。

2. 當需要實現高效的程式碼時。有時，為了提高效能，我們需要讓某些類或函式能夠直接訪問另一個類的內部成員。透過使用friend機制，我們可以避免建立額外的介面，從而提高程式碼的執行效率。

3. 當用於測試時。在軟體測試中，我們可能需要訪問類的私有成員來驗證其正確性。透過將測試類或測試函式宣告為待測類的友元，我們可以更容易地訪問這些私有成員，從而編寫更全面的測試用例。

總之，雖然friend機制可能會破壞物件導向設計的封裝性，但在某些特定情況下，它仍然是一個有用的工具。
Jerry:
gof 23 種設計模式裡，並沒有一種採取 friend 實現，這本身也能說明問題了。

`friend` 關鍵字通常在 C++ 中使用，用於宣告友元類或友元函式，以便在類之間共享私有成員。這個概念在其他程式語言中可能有不同的實現方式，例如 C# 中的 `internal` 關鍵字。

然而，在23種設計模式中，有些模式可能會用到友元類或友元函式的概念。例如，Mediator（中介者）模式中，類之間的通訊會透過一箇中介者物件進行。這種情況下，友元類或友元函式可以用來限制對各個類的訪問，只允許中介者物件訪問它們的私有成員。不過，這並不是 GoF 設計模式的核心內容，而是具體實現時的一種可選方案。

總之，GoF 23種設計模式並沒有直接藉助物件導向的 `friend` 機制來實現。然而，在實際應用這些設計模式時，根據具體需求和程式語言的特點，`friend` 機制可以作為一種實現方式。

在 Gof 23 種設計模式中，並沒有直接藉助物件導向的 friend 機制實現的設計模式。但是，有一些設計模式涉及到了訪問控制和物件間的協作，可以透過類似於 friend 機制的方式實現。

例如，觀察者模式（Observer Pattern）中，一個物件（稱為 Subject）維護了一系列觀察者物件（Observers），並在狀態發生改變時通知這些觀察者。通常情況下，Subject 物件需要將自身的狀態資訊告訴 Observer 物件，以便 Observer 物件能夠獲取到相關的資訊。在這種情況下，可以將 Observer 物件設定為 Subject 物件的 friend 型別，使得 Observer 物件可以直接訪問 Subject 物件的私有狀態，而不需要透過公共介面來訪問。

此外，還有一些類似於訪問控制和物件間協作的設計模式，如門面模式（Facade Pattern）和中介者模式（Mediator Pattern），都需要協調不同的物件之間的關係。在這些模式中，物件之間需要進行協作，但是又需要保持封裝性。可以透過類似於 friend 機制的方式來實現物件之間的協作和資訊共享，同時保持封裝性。

總之，雖然沒有直接藉助物件導向的 friend 機制實現的設計模式，但是一些設計模式涉及到了訪問控制和物件間的協作，可以透過類似於 friend 機制的方式來實現。這也說明了，在物件導向設計中，合適的訪問控制和物件間協作是非常重要的。

物件導向設計裡引入 Friend 是對封裝性的破壞嗎，friend 在 SAP ABAP 裡的應用場景

相關文章