Tại sao các trường riêng là riêng tư cho loại, không phải là trường hợp?

Trong C # (và nhiều ngôn ngữ khác), việc truy cập các trường riêng của các trường hợp khác cùng loại là hoàn toàn hợp pháp. Ví dụ:

public class Foo
{
    private bool aBool;

    public void DoBar(Foo anotherFoo)
    {
        if (anotherFoo.aBool) ...
    }
}

Vì đặc tả C # (phần 3.5.1, 3.5.2) cho biết quyền truy cập vào các trường riêng là trên một loại, không phải là một thể hiện. Tôi đã thảo luận vấn đề này với một đồng nghiệp và chúng tôi đang cố gắng đưa ra lý do tại sao nó hoạt động như thế này (thay vì hạn chế quyền truy cập vào cùng một ví dụ).

Đối số tốt nhất chúng ta có thể đưa ra là về kiểm tra đẳng thức trong đó lớp có thể muốn truy cập các trường riêng để xác định đẳng thức với một thể hiện khác. Có bất kỳ lý do khác? Hoặc một số lý do vàng hoàn toàn có nghĩa là nó phải hoạt động như thế này hoặc một cái gì đó sẽ hoàn toàn không thể?

Tôi nghĩ một lý do nó hoạt động theo cách này là vì các công cụ sửa đổi truy cập hoạt động vào thời gian biên dịch . Như vậy, việc xác định có hay không một đối tượng nhất định cũng là đối tượng hiện tại không dễ thực hiện. Ví dụ, hãy xem xét mã này:

public class Foo
{
    private int bar;

    public void Baz(Foo other)
    {
        other.bar = 2;
    }

    public void Boo()
    {
        Baz(this);
    }
}

Trình biên dịch có thể nhất thiết phải tìm ra đó otherlà thực sự this? Không phải trong mọi trường hợp. Người ta có thể lập luận rằng điều này chỉ không nên biên dịch sau đó, nhưng điều đó có nghĩa là chúng ta có một đường dẫn mã trong đó một thành viên cá thể của cá thể đúng không thể truy cập được, điều mà tôi nghĩ còn tồi tệ hơn.

Chỉ yêu cầu mức độ loại chứ không phải mức độ hiển thị của đối tượng đảm bảo rằng vấn đề có thể xử lý được, cũng như tạo ra một tình huống có vẻ như nó sẽ hoạt động thực sự hoạt động.

EDIT : Quan điểm của Danilel Hilgarth rằng lý luận này ngược có giá trị. Các nhà thiết kế ngôn ngữ có thể tạo ra ngôn ngữ họ muốn và các nhà văn biên dịch phải tuân theo nó. Điều đó đang được nói, các nhà thiết kế ngôn ngữ có một số động lực để giúp các nhà văn biên dịch dễ dàng thực hiện công việc của họ hơn. (Mặc dù trong trường hợp này, thật dễ dàng để tranh luận rằng các thành viên tư nhân sau đó chỉ có thể được truy cập thông qua this(mặc nhiên hoặc rõ ràng)).

Tuy nhiên, tôi tin rằng điều đó làm cho vấn đề trở nên rắc rối hơn mức cần thiết. Hầu hết người dùng (trong đó có tôi) sẽ thấy nó unneccessarily hạn chế nếu mã ở trên không làm việc: sau khi tất cả, đó là tôi dữ liệu tôi đang cố gắng để truy cập! Tại sao tôi phải trải qua this?

Nói tóm lại, tôi nghĩ rằng tôi có thể đã phóng đại trường hợp vì nó "khó" đối với trình biên dịch. Điều tôi thực sự muốn vượt qua là tình huống trên có vẻ như là một điều mà các nhà thiết kế muốn có công việc.

Bởi vì mục đích của loại đóng gói được sử dụng trong C # và các ngôn ngữ tương tự * là để giảm sự phụ thuộc lẫn nhau của các đoạn mã khác nhau (các lớp trong C # và Java), chứ không phải các đối tượng khác nhau trong bộ nhớ.

Ví dụ, nếu bạn viết mã trong một lớp sử dụng một số trường trong một lớp khác, thì các lớp này được liên kết rất chặt chẽ. Tuy nhiên, nếu bạn đang xử lý mã trong đó bạn có hai đối tượng cùng lớp, thì không có phụ thuộc thêm. Một lớp học luôn phụ thuộc vào chính nó.

Tuy nhiên, tất cả lý thuyết về đóng gói này đều thất bại ngay khi ai đó tạo các thuộc tính (hoặc các cặp get / set trong Java) và phơi bày tất cả các trường trực tiếp, điều này làm cho các lớp được ghép nối như thể dù sao chúng cũng đang truy cập các trường.

_{* Để làm rõ về các loại đóng gói, xem câu trả lời tuyệt vời của Abel.}

Khá nhiều câu trả lời đã được thêm vào chủ đề thú vị này, tuy nhiên, tôi hoàn toàn không tìm thấy lý do thực sự tại sao hành vi này lại diễn ra như vậy. Hãy để tôi thử

Quay trở lại những ngày

Ở đâu đó giữa Smalltalk trong thập niên 80 và Java vào giữa những năm 90, khái niệm về hướng đối tượng đã trưởng thành. Việc che giấu thông tin, ban đầu không được coi là một khái niệm chỉ có sẵn cho OO (được đề cập đầu tiên vào năm 1978), được giới thiệu trong Smalltalk vì tất cả dữ liệu (các trường) của một lớp là riêng tư, tất cả các phương thức đều công khai. Trong nhiều phát triển mới của OO trong những năm 90, Bertrand Meyer đã cố gắng chính thức hóa phần lớn các khái niệm OO trong cuốn sách mang tính bước ngoặt Xây dựng phần mềm hướng đối tượng (OOSC) mà sau đó được coi là một tài liệu tham khảo chính xác về các khái niệm OO và thiết kế ngôn ngữ .

Trong trường hợp tầm nhìn riêng tư

Theo Meyer, một phương thức nên được cung cấp cho một nhóm các lớp xác định (trang 192-193). Điều này rõ ràng mang lại độ chi tiết ẩn rất cao, tính năng sau đây có sẵn cho classA và classB và tất cả con cháu của họ:

feature {classA, classB}
   methodName

Trong trường hợp privateanh ta nói như sau: không khai báo rõ ràng một loại là hiển thị với lớp của chính nó, bạn không thể truy cập tính năng đó (phương thức / trường) trong một cuộc gọi đủ điều kiện. Tức xlà nếu là một biến,x.doSomething() không được phép. Tất nhiên, quyền truy cập không đủ điều kiện được cho phép, bên trong lớp.

Nói cách khác: để cho phép truy cập theo một thể hiện của cùng một lớp, bạn phải cho phép phương thức truy cập theo lớp đó một cách rõ ràng. Điều này đôi khi được gọi là cá thể-riêng so với lớp-riêng.

Instance-private trong ngôn ngữ lập trình

Tôi biết ít nhất hai ngôn ngữ hiện đang sử dụng sử dụng ẩn thông tin cá nhân trái ngược với ẩn thông tin riêng tư lớp. Một là Eiffel, một ngôn ngữ được thiết kế bởi Meyer, đưa OO đến những thái cực nhất. Cái còn lại là Ruby, một ngôn ngữ phổ biến hơn nhiều hiện nay. Trong Ruby, privatecó nghĩa là: "riêng tư trong trường hợp này" .

Lựa chọn thiết kế ngôn ngữ

Nó đã được đề xuất rằng cho phép cá nhân-private sẽ khó cho trình biên dịch. Tôi không nghĩ vậy, vì nó tương đối đơn giản khi chỉ cho phép hoặc không cho phép các cuộc gọi đủ điều kiện đến các phương thức. Nếu cho một phương thức riêng tư, doSomething()được cho phép vàx.doSomething() không, thì một nhà thiết kế ngôn ngữ đã xác định hiệu quả khả năng truy cập chỉ đối tượng cho các phương thức và trường riêng.

Từ quan điểm kỹ thuật, không có lý do để chọn cách này hay cách khác (đặc biệt khi xem xét rằng Eiffel.NET có thể làm điều này với IL, ngay cả với nhiều kế thừa, không có lý do cố hữu nào để không cung cấp tính năng này).

Tất nhiên, đó là vấn đề của hương vị và như những người khác đã đề cập, khá nhiều phương pháp có thể khó viết hơn nếu không có tính năng hiển thị cấp độ của các phương thức và trường riêng.

Tại sao C # chỉ cho phép đóng gói lớp và không đóng gói cá thể

Nếu bạn xem các chủ đề internet về đóng gói cá thể (một thuật ngữ đôi khi được sử dụng để chỉ thực tế là một ngôn ngữ xác định các công cụ sửa đổi truy cập ở cấp độ cá thể, trái ngược với cấp độ lớp học), khái niệm này thường được sử dụng. Tuy nhiên, xem xét rằng một số ngôn ngữ hiện đại sử dụng đóng gói cá thể, ít nhất là cho công cụ sửa đổi truy cập riêng tư, khiến bạn nghĩ rằng nó có thể và được sử dụng trong thế giới lập trình hiện đại.

Tuy nhiên, C # đã thừa nhận là khó nhất đối với C ++ và Java về thiết kế ngôn ngữ. Trong khi Eiffel và Modula-3 cũng có mặt trong bức tranh, xem xét nhiều tính năng của Eiffel bị thiếu (nhiều kế thừa), tôi tin rằng họ đã chọn cùng một tuyến đường với Java và C ++ khi nói đến công cụ sửa đổi truy cập riêng.

Nếu bạn thực sự muốn biết lý do tại sao bạn nên cố gắng nắm giữ Eric Lippert, Krzysztof Cwalina, Anders Hejlsberg hoặc bất kỳ ai khác làm việc theo tiêu chuẩn của C #. Thật không may, tôi không thể tìm thấy một ghi chú dứt khoát trong Ngôn ngữ lập trình C # được chú thích .

Đây chỉ là ý kiến ​​của tôi, nhưng thực tế, tôi nghĩ rằng nếu một lập trình viên có quyền truy cập vào nguồn của một lớp, bạn có thể tin tưởng họ một cách hợp lý với việc truy cập các thành viên riêng của cá thể lớp. Tại sao ràng buộc một lập trình viên tay phải khi ở bên trái của bạn, bạn đã trao cho họ chìa khóa của vương quốc?

Lý do thực sự là kiểm tra bình đẳng, so sánh, nhân bản, quá tải toán tử ... Sẽ rất khó để thực hiện toán tử + trên các số phức, chẳng hạn.

Trước hết, điều gì sẽ xảy ra với các thành viên tĩnh tư nhân? Họ chỉ có thể được truy cập bằng phương pháp tĩnh? Bạn chắc chắn sẽ không muốn điều đó, bởi vì sau đó bạn sẽ không thể truy cập vào consts của bạn .

Đối với câu hỏi rõ ràng của bạn, hãy xem xét trường hợp của a StringBuilder, được triển khai như một danh sách các trường hợp được liên kết của chính nó:

public class StringBuilder
{
    private string chunk;
    private StringBuilder nextChunk;
}

Nếu bạn không thể truy cập các thành viên riêng của các phiên bản khác của lớp của riêng bạn, bạn phải thực hiện ToStringnhư sau:

public override string ToString()
{
    return chunk + nextChunk.ToString();
}

Điều này sẽ hoạt động, nhưng đó là O (n ^ 2) - không hiệu quả lắm. Trong thực tế, điều đó có thể đánh bại toàn bộ mục đích có một StringBuilderlớp học ngay từ đầu. Nếu bạn có thể truy cập các thành viên riêng của các phiên bản khác của lớp của riêng bạn, bạn có thể thực hiện ToStringbằng cách tạo một chuỗi có độ dài phù hợp và sau đó thực hiện một bản sao không an toàn của từng đoạn đến vị trí thích hợp trong chuỗi:

public override string ToString()
{
    string ret = string.FastAllocateString(Length);
    StringBuilder next = this;

    unsafe
    {
        fixed (char *dest = ret)
            while (next != null)
            {
                fixed (char *src = next.chunk)
                    string.wstrcpy(dest, src, next.chunk.Length);
                next = next.nextChunk;
            }
    }
    return ret;
}

Việc triển khai này là O (n), làm cho nó rất nhanh và chỉ có thể nếu bạn có quyền truy cập vào các thành viên riêng của các phiên bản khác của lớp .

Điều này là hoàn toàn hợp pháp trong nhiều ngôn ngữ (C ++ cho một). Các sửa đổi truy cập đến từ nguyên tắc đóng gói trong OOP. Ý tưởng là để hạn chế truy cập ra bên ngoài , trong trường hợp này bên ngoài là các lớp khác. Bất kỳ lớp lồng nhau nào trong C # chẳng hạn cũng có thể truy cập vào các thành viên riêng của cha mẹ.

Trong khi đây là một sự lựa chọn thiết kế cho một nhà thiết kế ngôn ngữ. Việc hạn chế quyền truy cập này có thể làm phức tạp một số tình huống rất phổ biến mà không đóng góp nhiều vào sự cô lập của các thực thể.

Có một cuộc thảo luận tương tự ở đây

Tôi không nghĩ rằng có một lý do chúng ta không thể thêm một mức độ riêng tư khác, trong đó dữ liệu là riêng tư cho mỗi trường hợp. Trong thực tế, điều đó thậm chí có thể cung cấp một cảm giác tốt đẹp về sự hoàn chỉnh cho ngôn ngữ.

Nhưng trong thực tế, tôi nghi ngờ nó sẽ thực sự hữu ích. Như bạn đã chỉ ra, tính riêng tư thông thường của chúng tôi rất hữu ích cho những việc như kiểm tra bình đẳng, cũng như hầu hết các hoạt động khác liên quan đến nhiều phiên bản của Loại. Mặc dù, tôi cũng thích quan điểm của bạn về việc duy trì sự trừu tượng hóa dữ liệu, vì đó là một điểm quan trọng trong OOP.

Tôi nghĩ rằng xung quanh, cung cấp khả năng hạn chế quyền truy cập theo cách như vậy có thể là một tính năng hay để thêm vào OOP. Nó thực sự hữu ích? Tôi muốn nói là không, vì một lớp sẽ có thể tin tưởng vào mã của chính nó. Vì lớp đó là thứ duy nhất có thể truy cập các thành viên tư nhân, không có lý do thực sự nào cần sự trừu tượng hóa dữ liệu khi xử lý một thể hiện của lớp khác.

Tất nhiên, bạn luôn có thể viết mã của mình như thể áp dụng riêng cho các thể hiện. Sử dụng các get/setphương pháp thông thường để truy cập / thay đổi dữ liệu. Điều đó có thể sẽ làm cho mã dễ quản lý hơn nếu lớp có thể chịu sự thay đổi bên trong.

Câu trả lời tuyệt vời được đưa ra ở trên. Tôi sẽ nói thêm rằng một phần của vấn đề này là việc khởi tạo một lớp bên trong chính nó thậm chí còn được cho phép ngay từ đầu. Ví dụ, nó thực hiện trong một vòng lặp "for" logic đệ quy để sử dụng loại mẹo đó miễn là bạn có logic để kết thúc đệ quy. Nhưng khởi tạo hoặc vượt qua cùng một lớp bên trong chính nó mà không tạo ra các vòng lặp như vậy một cách hợp lý sẽ tạo ra những nguy hiểm riêng của nó, mặc dù mô hình lập trình được chấp nhận rộng rãi. Ví dụ, Lớp C # có thể khởi tạo một bản sao của chính nó trong hàm tạo mặc định của nó, nhưng điều đó không phá vỡ bất kỳ quy tắc nào hoặc tạo các vòng lặp nguyên nhân. Tại sao?

BTW .... vấn đề tương tự này cũng áp dụng cho các thành viên "được bảo vệ". :

Tôi chưa bao giờ chấp nhận mô hình lập trình đó một cách đầy đủ bởi vì nó vẫn đi kèm với một loạt các vấn đề và rủi ro mà hầu hết các lập trình viên không nắm bắt được cho đến khi các vấn đề như vấn đề này xuất hiện và gây nhầm lẫn cho mọi người và bất chấp toàn bộ lý do để có thành viên riêng.

Khía cạnh "kỳ quặc và kỳ quặc" này của C # vẫn là một lý do nữa khiến lập trình tốt không liên quan gì đến kinh nghiệm và kỹ năng, mà chỉ cần biết các thủ thuật và bẫy ..... như làm việc trên xe hơi. Đối số của nó là các quy tắc có nghĩa là bị phá vỡ, đó là một mô hình rất xấu cho bất kỳ ngôn ngữ điện toán nào.

Dường như với tôi rằng nếu dữ liệu là riêng tư đối với các trường hợp khác cùng loại, thì nó không nhất thiết phải cùng loại nữa. Nó dường như sẽ không cư xử hoặc hành động giống như các trường hợp khác. Hành vi có thể dễ dàng được sửa đổi dựa trên dữ liệu nội bộ riêng tư đó. Điều đó sẽ chỉ lan truyền sự nhầm lẫn trong quan điểm của tôi.

Nói một cách lỏng lẻo, cá nhân tôi nghĩ rằng các lớp viết xuất phát từ một lớp cơ sở cung cấp chức năng tương tự như bạn đang mô tả với "có dữ liệu riêng tư trên mỗi thể hiện". Thay vào đó, bạn chỉ có một định nghĩa lớp mới cho mỗi loại 'duy nhất'.