Cấu trúc như các đối tượng trong Java

Có hoàn toàn chống lại cách Java để tạo cấu trúc như các đối tượng không?

class SomeData1 {
    public int x;
    public int y;
}

Tôi có thể thấy một lớp với các trình truy cập và trình biến đổi giống Java hơn.

class SomeData2 {
    int getX();
    void setX(int x);

    int getY();
    void setY(int y);

    private int x;
    private int y;
}

Các lớp từ ví dụ đầu tiên là thuận tiện về mặt lý thuyết.

// a function in a class
public int f(SomeData1 d) {
    return (3 * d.x) / d.y;
}

Điều này không thuận tiện.

// a function in a class
public int f(SomeData2 d) {
    return (3 * d.getX()) / d.getY();
}

Đây là một chủ đề thường được thảo luận. Hạn chế của việc tạo các trường công khai trong các đối tượng là bạn không có quyền kiểm soát các giá trị được đặt cho nó. Trong các dự án nhóm nơi có nhiều lập trình viên sử dụng cùng một mã, điều quan trọng là tránh các tác dụng phụ. Bên cạnh đó, đôi khi tốt hơn là trả lại một bản sao của đối tượng trường hoặc biến đổi nó bằng cách nào đó, v.v. Bạn có thể chế giễu các phương thức đó trong các thử nghiệm của mình. Nếu bạn tạo một lớp mới, bạn có thể không thấy tất cả các hành động có thể. Nó giống như lập trình phòng thủ - một ngày nào đó getters và setters có thể hữu ích, và nó không tốn nhiều chi phí để tạo / sử dụng chúng. Vì vậy, chúng đôi khi hữu ích.

Trong thực tế, hầu hết các lĩnh vực có getters và setters đơn giản. Một giải pháp khả thi sẽ như thế này:

public property String foo;   
a->Foo = b->Foo;

Cập nhật: Rất khó có khả năng hỗ trợ thuộc tính sẽ được thêm vào trong Java 7 hoặc có lẽ đã từng. Các ngôn ngữ JVM khác như Groovy, Scala, v.v ... hiện đã hỗ trợ tính năng này. - Alex Miller

Dường như nhiều người Java không quen thuộc với Nguyên tắc mã hóa Sun Java, nói rằng nó khá phù hợp để sử dụng biến cá thể công khai khi lớp về cơ bản là "Struct", nếu Java hỗ trợ "struct" (khi không có hành vi).

Mọi người có xu hướng nghĩ rằng getters và setters là cách Java, như thể họ là trung tâm của Java. Đây không phải là như vậy. Nếu bạn tuân theo Nguyên tắc mã hóa Sun Java, sử dụng các biến thể hiện công khai trong các tình huống thích hợp, bạn thực sự đang viết mã tốt hơn so với làm lộn xộn nó với các getters và setters không cần thiết.

Các quy ước về mã Java từ năm 1999 và vẫn không thay đổi.

10.1 Cung cấp quyền truy cập vào các biến thể lập thể và lớp

Đừng biến bất kỳ trường hợp hoặc biến lớp nào thành công khai mà không có lý do chính đáng. Thông thường, các biến đối tượng không cần phải được đặt hoặc nhận rõ ràng - thường xảy ra như là một tác dụng phụ của các cuộc gọi phương thức.

Một ví dụ về các biến thể hiện công khai thích hợp là trường hợp lớp về cơ bản là cấu trúc dữ liệu, không có hành vi. Nói cách khác, nếu bạn đã sử dụng một cấu trúc thay vì một lớp (nếu Java được hỗ trợ cấu trúc), thì nó phù hợp để biến các biến đối tượng của lớp thành công khai .

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html#177

http://en.wikipedia.org/wiki/Plain_old_data_structure

http://docs.oracle.com/javase/1.3/docs/guide/collections/designfaq.html#28

Sử dụng thông thường thực sự. Nếu bạn có một cái gì đó như:

public class ScreenCoord2D{
    public int x;
    public int y;
}

Sau đó, có rất ít điểm trong việc gói chúng trong getters và setters. Bạn sẽ không bao giờ lưu trữ tọa độ x, y trong toàn bộ pixel theo bất kỳ cách nào khác. Getters và setters sẽ chỉ làm bạn chậm lại.

Mặt khác, với:

public class BankAccount{
    public int balance;
}

Bạn có thể muốn thay đổi cách tính số dư tại một thời điểm nào đó trong tương lai. Điều này thực sự nên sử dụng getters và setters.

Luôn luôn tốt hơn để biết lý do tại sao bạn áp dụng thực hành tốt, để bạn biết khi nào nên chấp nhận các quy tắc.

Để giải quyết mối quan tâm về tính biến đổi, bạn có thể khai báo x và y là cuối cùng. Ví dụ:

class Data {
  public final int x;
  public final int y;
  public Data( int x, int y){
    this.x = x;
    this.y = y;
  }
}

Gọi mã cố gắng ghi vào các trường này sẽ nhận được lỗi thời gian biên dịch của "trường x được khai báo là cuối cùng; không thể được chỉ định".

Mã khách hàng sau đó có thể có sự tiện lợi 'tay ngắn' mà bạn đã mô tả trong bài đăng của mình

public class DataTest {
    public DataTest() {
        Data data1 = new Data(1, 5);
        Data data2 = new Data(2, 4);
        System.out.println(f(data1));
        System.out.println(f(data2));
    }

    public int f(Data d) {
        return (3 * d.x) / d.y;
    }

    public static void main(String[] args) {
        DataTest dataTest = new DataTest();
    }
}

Không được dùng public các trường

Không sử dụng publiccác trường khi bạn thực sự muốn bao bọc hành vi nội bộ của một lớp. Lấy java.io.BufferedReaderví dụ. Nó có trường sau:

private boolean skipLF = false; // If the next character is a line feed, skip it

skipLFđược đọc và viết trong tất cả các phương pháp đọc. Điều gì xảy ra nếu một lớp bên ngoài chạy trong một luồng riêng biệt đã sửa đổi độc hại trạng thái skipLFở giữa một lần đọc? BufferedReaderchắc chắn sẽ đi haywire.

Sử dụng publiccác lĩnh vực

Lấy Pointlớp này làm ví dụ:

class Point {
    private double x;
    private double y;

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }

    public double getX() {
        return this.x;
    }

    public double getY() {
        return this.y;
    }

    public void setX(double x) {
        this.x = x;
    }

    public void setY(double y) {
        this.y = y;
    }
}

Điều này sẽ làm cho việc tính khoảng cách giữa hai điểm rất khó viết.

Point a = new Point(5.0, 4.0);
Point b = new Point(4.0, 9.0);
double distance = Math.sqrt(Math.pow(b.getX() - a.getX(), 2) + Math.pow(b.getY() - a.getY(), 2));

Lớp học không có bất kỳ hành vi nào khác ngoài getters và setters đơn giản. Có thể chấp nhận sử dụng các trường công khai khi lớp chỉ đại diện cho cấu trúc dữ liệu và không có và sẽ không bao giờ có hành vi (getters và setters mỏng không được coi là hành vi ở đây). Nó có thể được viết tốt hơn theo cách này:

class Point {
    public double x;
    public double y;

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }
}

Point a = new Point(5.0, 4.0);
Point b = new Point(4.0, 9.0);
double distance = Math.sqrt(Math.pow(b.x - a.x, 2) + Math.pow(b.y - a.y, 2));

Dọn dẹp!

Nhưng hãy nhớ rằng: Không chỉ lớp học của bạn phải vắng mặt trong hành vi, mà nó cũng không có lý do để có hành vi trong tương lai.

(Đây chính xác là những gì câu trả lời này mô tả. Để trích dẫn "Các quy ước mã cho ngôn ngữ lập trình Java: 10. Thực tiễn lập trình" :

Một ví dụ về các biến thể hiện công khai thích hợp là trường hợp lớp về cơ bản là cấu trúc dữ liệu, không có hành vi. Nói cách khác, nếu bạn đã sử dụng structthay vì một lớp (nếu được Java hỗ trợ struct), thì nó phù hợp để biến các biến đối tượng của lớp thành công khai.

Vì vậy, tài liệu chính thức cũng chấp nhận thực hành này.)

Ngoài ra, nếu bạn thêm chắc chắn rằng các thành viên của Pointlớp trên sẽ không thay đổi, thì bạn có thể thêm finaltừ khóa để thực thi nó:

public final double x;
public final double y;

Nhân tiện, cấu trúc mà bạn đưa ra làm ví dụ đã tồn tại trong thư viện lớp cơ sở Java như java.awt.Point. Nó có x và y là các trường công khai, hãy tự kiểm tra .

Nếu bạn biết những gì bạn đang làm và những người khác trong nhóm của bạn biết về nó, thì có thể có các lĩnh vực công cộng. Nhưng bạn không nên dựa vào nó bởi vì chúng có thể gây đau đầu vì các lỗi liên quan đến các nhà phát triển sử dụng các đối tượng như thể chúng là các cấu trúc được phân bổ ngăn xếp (các đối tượng java luôn được gửi đến các phương thức dưới dạng tham chiếu chứ không phải là bản sao).

Re: aku, izb, John Topley ...

Coi chừng các vấn đề về tính đột biến ...

Nó có vẻ hợp lý để bỏ qua getters / setters. Nó thực sự có thể ổn trong một số trường hợp. Vấn đề thực sự với mô hình đề xuất được hiển thị ở đây là tính đột biến.

Vấn đề là một khi bạn vượt qua một tham chiếu đối tượng có chứa các trường công khai, không phải là chung kết. Bất cứ điều gì khác với tham chiếu đó là miễn phí để sửa đổi các lĩnh vực. Bạn không còn có quyền kiểm soát trạng thái của đối tượng đó nữa. (Hãy nghĩ điều gì sẽ xảy ra nếu Chuỗi có thể thay đổi.)

Nó trở nên tồi tệ khi đối tượng đó là một phần quan trọng của trạng thái nội bộ của người khác, bạn vừa tiếp xúc với việc thực hiện nội bộ. Để ngăn chặn điều này, một bản sao của đối tượng phải được trả lại thay thế. Điều này hoạt động, nhưng có thể gây ra áp lực GC lớn từ hàng tấn bản sao sử dụng một lần được tạo.

Nếu bạn có các trường công khai, hãy xem xét làm cho lớp chỉ đọc. Thêm các trường làm tham số cho hàm tạo và đánh dấu các trường cuối cùng. Mặt khác, đảm bảo bạn không để lộ trạng thái nội bộ và nếu bạn cần xây dựng các thể hiện mới cho giá trị trả về, hãy đảm bảo rằng nó sẽ không được gọi quá mức.

Xem: " Java hiệu quả " của Joshua Bloch - Mục số 13: Bất biến bất lợi.

PS: Cũng lưu ý, tất cả các JVM ngày nay sẽ tối ưu hóa getMethod nếu có thể, dẫn đến chỉ một lệnh đọc trường duy nhất.

Tôi đã thử điều này trong một vài dự án, trên lý thuyết rằng các getters và setters làm lộn xộn mã với ngữ nghĩa vô nghĩa về mặt ngữ nghĩa và các ngôn ngữ khác dường như chỉ làm tốt với việc ẩn dữ liệu dựa trên quy ước hoặc phân vùng trách nhiệm (ví dụ python).

Như những người khác đã lưu ý ở trên, có 2 vấn đề mà bạn gặp phải và chúng không thực sự có thể khắc phục được:

• Chỉ cần về bất kỳ công cụ tự động nào trong thế giới java đều dựa vào quy ước getter / setter. Ditto, như được lưu ý bởi những người khác, thẻ jsp, cấu hình lò xo, công cụ nhật thực, v.v ... ... Chống lại những gì công cụ của bạn mong đợi là một công thức cho các phiên dài trolling thông qua google cố gắng tìm ra cách khởi tạo không chuẩn đó đậu xuân. Thực sự không đáng để gặp rắc rối.
• Khi bạn có ứng dụng được mã hóa thanh lịch của mình với hàng trăm biến công khai, bạn có thể sẽ tìm thấy ít nhất một tình huống khi chúng không đủ - nơi bạn thực sự cần bất biến hoặc bạn cần kích hoạt một số sự kiện khi biến được đặt hoặc bạn muốn ném một ngoại lệ trên một thay đổi biến vì nó đặt trạng thái đối tượng thành một cái gì đó khó chịu. Sau đó, bạn bị mắc kẹt với các lựa chọn không thể chối cãi giữa việc làm lộn xộn mã của bạn với một số phương thức đặc biệt ở khắp mọi nơi mà biến được tham chiếu trực tiếp, có một số hình thức truy cập đặc biệt cho 3 trong số 1000 biến trong ứng dụng của bạn.

Và đây là trường hợp tốt nhất để làm việc hoàn toàn trong một dự án tư nhân khép kín. Khi bạn xuất toàn bộ sang thư viện có thể truy cập công khai, các vấn đề này sẽ còn lớn hơn nữa.

Java rất dài dòng và đây là một điều hấp dẫn để làm. Đừng làm điều đó.

Nếu cách Java là cách OO, thì có, việc tạo một lớp với các trường công khai phá vỡ các nguyên tắc xung quanh việc che giấu thông tin nói rằng một đối tượng nên quản lý trạng thái bên trong của chính nó. (Vì vậy, vì tôi không chỉ nói về thuật ngữ của bạn, một lợi ích của việc che giấu thông tin là hoạt động bên trong của một lớp được ẩn sau một giao diện - giả sử bạn muốn thay đổi cơ chế mà lớp struct của bạn đã lưu một trong các trường của nó, có lẽ bạn sẽ cần phải quay lại và thay đổi bất kỳ lớp nào sử dụng lớp ...)

Bạn cũng không thể tận dụng sự hỗ trợ cho các lớp tuân thủ đặt tên JavaBean, điều này sẽ gây tổn hại nếu bạn quyết định sử dụng lớp trong Trang máy chủ Java được viết bằng Ngôn ngữ biểu thức.

Bài viết JavaWorld Tại sao Phương thức Getter và Setter là Ác cũng có thể khiến bạn quan tâm khi nghĩ đến việc không nên thực hiện các phương thức accessor và mutator.

Nếu bạn đang viết một giải pháp nhỏ và muốn giảm thiểu số lượng mã liên quan, cách Java có thể không đúng cách - tôi đoán nó luôn phụ thuộc vào bạn và vấn đề bạn đang cố gắng giải quyết.

Không có gì sai với loại mã đó, với điều kiện tác giả biết rằng chúng là cấu trúc (hoặc con thoi dữ liệu) thay vì các đối tượng. Rất nhiều nhà phát triển Java không thể phân biệt sự khác biệt giữa một đối tượng được hình thành tốt (không chỉ là một lớp con của java.lang.Object, mà là một đối tượng thực sự trong một miền cụ thể) và một quả dứa. Ergo, cuối cùng họ viết các cấu trúc khi họ cần các đối tượng và ngược lại.

Vấn đề với việc sử dụng truy cập trường công cộng cũng giống như sử dụng phương thức mới thay vì phương thức xuất xưởng - nếu bạn đổi ý sau này, tất cả các cuộc gọi hiện tại đều bị hỏng. Vì vậy, từ quan điểm tiến hóa API, thông thường nên cắn viên đạn và sử dụng getters / setters.

Một nơi mà tôi đi theo một cách khác là khi bạn kiểm soát mạnh mẽ quyền truy cập vào lớp, ví dụ như trong một lớp tĩnh bên trong được sử dụng làm cấu trúc dữ liệu nội bộ. Trong trường hợp này, việc sử dụng truy cập trường có thể rõ ràng hơn nhiều.

Nhân tiện, theo khẳng định của e-bartek, IMO rất khó có khả năng hỗ trợ tài sản sẽ được thêm vào trong Java 7.

Tôi thường sử dụng mẫu này khi xây dựng các lớp bên trong riêng để đơn giản hóa mã của mình, nhưng tôi không khuyên bạn nên phơi bày các đối tượng như vậy trong API công khai. Nói chung, bạn càng thường xuyên có thể làm cho các đối tượng trong API công khai của mình trở nên tốt hơn và không thể xây dựng đối tượng 'giống như cấu trúc' của bạn theo cách không thay đổi.

Bên cạnh đó, ngay cả khi tôi đang viết đối tượng này như một lớp bên trong riêng tư, tôi vẫn sẽ cung cấp một hàm tạo để đơn giản hóa mã để khởi tạo đối tượng. Phải có 3 dòng mã để có được một đối tượng có thể sử dụng khi một người sẽ làm chỉ là lộn xộn.

Một câu hỏi rất cũ, nhưng hãy để tôi đóng góp ngắn. Java 8 đã giới thiệu các biểu thức lambda và các tham chiếu phương thức. Biểu thức Lambda có thể là các tham chiếu phương thức đơn giản và không khai báo phần thân "đúng". Nhưng bạn không thể "chuyển đổi" một trường thành một tham chiếu phương thức. Như vậy

stream.mapToInt(SomeData1::x)

không hợp pháp, nhưng

stream.mapToInt(SomeData2::getX)

Là.

Tôi không thấy tác hại nếu bạn biết rằng nó sẽ luôn là một cấu trúc đơn giản và bạn sẽ không bao giờ muốn gắn hành vi với nó.

Đây là một câu hỏi về Thiết kế hướng đối tượng, không phải ngôn ngữ Java. Nói chung, đó là cách tốt để ẩn các loại dữ liệu trong lớp và chỉ hiển thị các phương thức là một phần của API lớp. Nếu bạn để lộ các loại dữ liệu nội bộ, bạn không bao giờ có thể thay đổi chúng trong tương lai. Nếu bạn ẩn chúng, nghĩa vụ duy nhất của bạn đối với người dùng là các kiểu đối số và trả về của phương thức.

Ở đây tôi tạo một chương trình để nhập Tên và Tuổi của 5 người khác nhau và thực hiện sắp xếp lựa chọn (tuổi khôn ngoan). Tôi đã sử dụng một lớp hoạt động như một cấu trúc (như ngôn ngữ lập trình C) và một lớp chính để thực hiện thao tác hoàn chỉnh. Dưới đây tôi đang cung cấp mã ...

import java.io.*;

class NameList {
    String name;
    int age;
}

class StructNameAge {
    public static void main(String [] args) throws IOException {

        NameList nl[]=new NameList[5]; // Create new radix of the structure NameList into 'nl' object
        NameList temp=new NameList(); // Create a temporary object of the structure

        BufferedReader br=new BufferedReader(new InputStreamReader(System.in));

        /* Enter data into each radix of 'nl' object */

        for(int i=0; i<5; i++) {
            nl[i]=new NameList(); // Assign the structure into each radix

            System.out.print("Name: ");
            nl[i].name=br.readLine();

            System.out.print("Age: ");
            nl[i].age=Integer.parseInt(br.readLine());

            System.out.println();
        }

        /* Perform the sort (Selection Sort Method) */

        for(int i=0; i<4; i++) {
            for(int j=i+1; j<5; j++) {
                if(nl[i].age>nl[j].age) {
                    temp=nl[i];
                    nl[i]=nl[j];
                    nl[j]=temp;
                }
            }
        }

        /* Print each radix stored in 'nl' object */

        for(int i=0; i<5; i++)
            System.out.println(nl[i].name+" ("+nl[i].age+")");
    }
}

Đoạn mã trên không có lỗi và được kiểm tra ... Chỉ cần sao chép và dán nó vào IDE của bạn và ... Bạn biết gì không ??? :)

Bạn có thể tạo một lớp đơn giản với các trường công khai và không có phương thức nào trong Java, nhưng nó vẫn là một lớp và vẫn được xử lý theo cú pháp và về mặt phân bổ bộ nhớ giống như một lớp. Không có cách nào để tái tạo thực sự các cấu trúc trong Java.

Đôi khi tôi sử dụng lớp như vậy, khi tôi cần trả về nhiều giá trị từ một phương thức. Tất nhiên, đối tượng như vậy là ngắn ngủi và tầm nhìn rất hạn chế, vì vậy nó sẽ ổn.

Như với hầu hết mọi thứ, có quy tắc chung và sau đó có những trường hợp cụ thể. Nếu bạn đang thực hiện một ứng dụng đã đóng, bị bắt để bạn biết cách sử dụng một đối tượng cụ thể, thì bạn có thể thực hiện nhiều tự do hơn để ưu tiên khả năng hiển thị và / hoặc hiệu quả. Nếu bạn đang phát triển một lớp sẽ được sử dụng công khai bởi những người khác ngoài tầm kiểm soát của bạn, thì hãy nghiêng về mô hình getter / setter. Như với tất cả mọi thứ, chỉ cần sử dụng thông thường. Bạn có thể thực hiện một vòng ban đầu với công chúng và sau đó thay đổi chúng thành getter / setters sau đó.

Lập trình hướng theo khía cạnh cho phép bạn bẫy các bài tập hoặc tìm nạp và gắn logic chặn vào chúng, mà tôi đề xuất là cách đúng đắn để giải quyết vấn đề. (Vấn đề liệu chúng nên được công khai hay được bảo vệ hoặc được bảo vệ theo gói là trực giao.)

Do đó, bạn bắt đầu với các trường không bị chặn với vòng loại truy cập phù hợp. Khi các yêu cầu chương trình của bạn phát triển, bạn đính kèm logic để có thể xác thực, tạo một bản sao của đối tượng được trả về, v.v.

Triết lý getter / setter áp đặt chi phí cho một số lượng lớn các trường hợp đơn giản mà không cần thiết.

Cho dù phong cách khía cạnh là sạch hơn hay không là một phần định tính. Tôi sẽ thấy dễ dàng khi chỉ nhìn thấy các biến trong một lớp và xem logic riêng biệt. Trên thực tế, lý do để lập trình theo định hướng Apect là nhiều mối quan tâm đang xuyên suốt và ngăn chặn chúng trong cơ thể lớp không phải là lý tưởng (đăng nhập là một ví dụ - nếu bạn muốn đăng nhập tất cả, Java sẽ muốn bạn viết một loạt các getters và giữ chúng đồng bộ nhưng AspectJ cho phép bạn một lớp lót).

Vấn đề của IDE là cá trích đỏ. Nó không phải là quá nhiều gõ vì nó là ô nhiễm đọc và hình ảnh phát sinh từ get / bộ.

Các chú thích có vẻ tương tự như lập trình hướng theo khía cạnh ngay từ cái nhìn đầu tiên, tuy nhiên chúng yêu cầu bạn phải liệt kê triệt để các điểm cắt bằng cách đính kèm các chú thích, trái ngược với đặc tả kỹ thuật cắt điểm giống như thẻ hoang dã trong AspectJ.

Tôi hy vọng nhận thức về AspectJ ngăn mọi người giải quyết sớm các ngôn ngữ động.