Sử dụng công cụ sửa đổi cuối cùng của bất cứ khi nào có thể áp dụng trong Java [đã đóng]

Trong Java, có một thực hành khai báo mọi biến (cục bộ hoặc lớp), tham số cuối cùng nếu chúng thực sự là.

Mặc dù điều này làm cho mã dài hơn rất nhiều, nhưng điều này giúp đọc / nắm mã dễ dàng và cũng ngăn ngừa các lỗi vì ý định được đánh dấu rõ ràng.

Suy nghĩ của bạn về điều này và những gì bạn làm theo?

Tôi nghĩ rằng tất cả phải làm với phong cách mã hóa tốt. Tất nhiên bạn có thể viết các chương trình tốt, mạnh mẽ mà không cần sử dụng nhiều công cụ finalsửa đổi ở bất cứ đâu, nhưng khi bạn nghĩ về nó ...

Thêm finalvào tất cả những thứ không nên thay đổi chỉ đơn giản là thu hẹp các khả năng mà bạn (hoặc lập trình viên tiếp theo, làm việc với mã của bạn) sẽ hiểu sai hoặc sử dụng sai quy trình suy nghĩ dẫn đến mã của bạn. Ít nhất nó nên rung một số tiếng chuông khi họ muốn thay đổi điều bất biến trước đây của bạn.

Lúc đầu, có vẻ hơi lúng túng khi thấy rất nhiều finaltừ khóa trong mã của bạn, nhưng chẳng mấy chốc bạn sẽ ngừng chú ý đến từ đó và sẽ nghĩ đơn giản rằng, điều đó sẽ không bao giờ thay đổi từ điểm này trên (bạn có thể lấy nó từ tôi ;-)

Tôi nghĩ rằng đó là thực hành tốt. Tôi không sử dụng nó mọi lúc, nhưng khi tôi có thể và nó có ý nghĩa để gắn nhãn một cái gì đó finaltôi sẽ làm điều đó.

Ám ảnh:

• Các trường cuối cùng - Đánh dấu các trường là cuối cùng buộc chúng phải được đặt khi kết thúc xây dựng, làm cho tham chiếu trường đó không thay đổi. Điều này cho phép xuất bản các trường an toàn và có thể tránh sự cần thiết phải đồng bộ hóa trong các lần đọc sau. (Lưu ý rằng đối với tham chiếu đối tượng, chỉ tham chiếu trường là bất biến - những điều mà tham chiếu đối tượng đề cập đến vẫn có thể thay đổi và điều đó ảnh hưởng đến tính bất biến.)
• Các trường tĩnh cuối cùng - Mặc dù bây giờ tôi sử dụng enums cho nhiều trường hợp tôi đã sử dụng các trường tĩnh cuối cùng.

Cân nhắc nhưng sử dụng thận trọng:

• Các lớp cuối cùng - Thiết kế khung / API là trường hợp duy nhất mà tôi xem xét nó.
• Phương thức cuối cùng - Về cơ bản giống như các lớp cuối cùng. Nếu bạn đang sử dụng các mẫu phương thức mẫu như điên và đánh dấu thứ cuối cùng, có lẽ bạn phụ thuộc quá nhiều vào tính kế thừa và không đủ cho việc ủy ​​quyền.

Bỏ qua trừ khi cảm thấy hậu môn:

• Các tham số của phương thức và các biến cục bộ - Tôi RARELY làm điều này phần lớn vì tôi lười biếng và tôi thấy nó làm tắc mã. Tôi sẽ hoàn toàn thừa nhận rằng việc đánh dấu các tham số và các biến cục bộ mà tôi sẽ không sửa đổi là "sáng hơn". Tôi ước nó là mặc định. Nhưng nó không phải là và tôi thấy mã khó hiểu hơn với trận chung kết. Nếu tôi ở mã của người khác, tôi sẽ không rút chúng ra nhưng nếu tôi viết mã mới, tôi sẽ không đưa chúng vào. Một ngoại lệ là trường hợp bạn phải đánh dấu thứ gì đó cuối cùng để bạn có thể truy cập nó từ bên trong một lớp bên trong vô danh.

Bạn thực sự cần phải hiểu toàn bộ việc sử dụng từ khóa cuối cùng trước khi sử dụng nó. Nó có thể áp dụng và có ảnh hưởng khác nhau đến các biến, trường, phương thức và lớp

Tôi khuyên bạn nên kiểm tra bài viết được liên kết đến bên dưới để biết thêm chi tiết.

Từ cuối cùng trên từ khóa cuối cùng

Công cụ finalsửa đổi, đặc biệt là cho các biến, là một phương tiện để trình biên dịch thực thi một quy ước thường hợp lý: đảm bảo một biến (cục bộ hoặc thể hiện) được gán chính xác một lần (không hơn không kém). Bằng cách đảm bảo một biến chắc chắn được gán trước khi nó được sử dụng, bạn có thể tránh các trường hợp phổ biến của NullPointerException:

final FileInputStream in;
if(test)
  in = new FileInputStream("foo.txt");
else
  System.out.println("test failed");
in.read(); // Compiler error because variable 'in' might be unassigned

Bằng cách ngăn chặn một biến được chỉ định nhiều lần, bạn không khuyến khích phạm vi vượt quá. Thay vì điều này:

 String msg = null;
 for(int i = 0; i < 10; i++) {
     msg = "We are at position " + i;
     System.out.println(msg);
 }
 msg = null;

Bạn được khuyến khích sử dụng điều này:

 for(int i = 0; i < 10; i++) {
     final String msg = "We are at position " + i;
     System.out.println(msg);
 }

Một số liên kết:

• Câu chuyện cuối cùng (chương miễn phí của cuốn sách "Hardcore Java")
• Một số mẫu cuối cùng
• Nhiệm vụ xác định

Tôi khá giáo điều về việc khai báo mọi biến có thể final. Điều này bao gồm các tham số phương thức, các biến cục bộ và hiếm khi, các trường đối tượng giá trị. Tôi có ba lý do chính để khai báo các biến cuối cùng ở mọi nơi:

1. Khai báo ý định: Bằng cách khai báo một biến cuối cùng, tôi nói rằng biến này chỉ được viết một lần. Đó là một gợi ý tinh tế cho các nhà phát triển khác và là một gợi ý lớn cho trình biên dịch.
2. Thực thi các biến sử dụng một lần: Tôi tin vào ý tưởng rằng mỗi biến chỉ nên có một mục đích trong cuộc sống. Bằng cách chỉ cung cấp cho mỗi biến số một mục đích, bạn giảm thời gian tìm kiếm mục đích của biến đó trong khi gỡ lỗi.
3. Cho phép tối ưu hóa: Tôi biết rằng trình biên dịch được sử dụng để có các thủ thuật nâng cao hiệu suất, đặc biệt dựa trên tính bất biến của một tham chiếu biến. Tôi muốn nghĩ rằng một số thủ thuật hiệu suất cũ (hoặc những cái mới) sẽ được trình biên dịch sử dụng.

Tuy nhiên, tôi nghĩ rằng các lớp và phương thức cuối cùng gần như không hữu ích như các tham chiếu biến cuối cùng. Các finaltừ khóa, khi được sử dụng với những tuyên bố đơn giản là cung cấp rào chắn để kiểm tra tự động và việc sử dụng mã của bạn theo những cách mà bạn có thể chưa bao giờ dự đoán.

Java hiệu quả có một mục có nội dung "Ưu tiên các đối tượng bất biến". Khai báo các trường là cuối cùng giúp bạn thực hiện một số bước nhỏ đối với điều này, nhưng tất nhiên có nhiều hơn đối với các đối tượng thực sự bất biến hơn thế.

Nếu bạn biết rằng các đối tượng là bất biến, chúng có thể được chia sẻ để đọc giữa nhiều luồng / máy khách mà không phải lo lắng về đồng bộ hóa, và sẽ dễ dàng hơn để lý giải về cách chương trình chạy.

Tôi chưa bao giờ ở trong tình huống có một từ khóa cuối cùng trên một biến đã khiến tôi không mắc lỗi, vì vậy hiện tại tôi nghĩ rằng đó là một sự lãng phí rất lớn thời gian.

Trừ khi có một lý do thực sự để làm điều đó (vì trong bạn muốn đưa ra một quan điểm cụ thể về biến đó là cuối cùng) tôi sẽ không làm điều đó vì tôi thấy nó làm cho mã ít đọc hơn.

Tuy nhiên, nếu bạn không tìm thấy nó làm cho mã khó đọc hơn hoặc dài hơn để viết thì bằng mọi cách hãy tìm nó.

Chỉnh sửa: Để làm rõ (và một nỗ lực để giành lại phiếu bầu), tôi không nói không đánh dấu các hằng số là cuối cùng, tôi đang nói đừng làm những việc như:

public String doSomething() {
  final String first = someReallyComplicatedExpressionToGetTheString();
  final String second = anotherReallyComplicatedExpressionToGetAnother();

  return first+second;
}

Nó chỉ làm cho mã (theo ý kiến ​​của tôi) khó đọc hơn.

Cũng đáng nhớ rằng tất cả các trận chung kết đều ngăn bạn gán lại một biến, điều đó không làm cho nó bất biến hay bất cứ điều gì tương tự.

Cuối cùng nên luôn luôn được sử dụng cho hằng số. Nó thậm chí còn hữu ích cho các biến có thời gian tồn tại ngắn (trong một phương thức) khi các quy tắc xác định biến là phức tạp.

Ví dụ:

final int foo;
if (a)
    foo = 1;
else if (b)
    foo = 2;
else if (c)
    foo = 3;
if (d)        // Compile error:  forgot the 'else'
    foo = 4;
else
    foo = -1;

Nghe có vẻ như một trong những tranh luận lớn nhất đối với việc sử dụng từ khóa cuối cùng là "nó không cần thiết" và nó "lãng phí không gian".

Nếu chúng tôi thừa nhận nhiều lợi ích của "cuối cùng" như được chỉ ra bởi nhiều bài đăng tuyệt vời ở đây, trong khi thừa nhận nó cần nhiều thao tác gõ và không gian hơn, tôi sẽ lập luận rằng Java nên tạo các biến "cuối cùng" theo mặc định và yêu cầu mọi thứ phải được đánh dấu " có thể thay đổi "nếu lập trình viên muốn.

Tôi sử dụng finaltất cả thời gian cho các thuộc tính đối tượng.

Các finaltừ khóa có ngữ nghĩa tầm nhìn khi được sử dụng trên các thuộc tính đối tượng. Về cơ bản, việc thiết lập giá trị của thuộc tính đối tượng cuối cùng xảy ra - trước khi hàm tạo trả về. Điều này có nghĩa là miễn là bạn không để thistham chiếu thoát khỏi hàm tạo và bạn sử dụng finalcho tất cả các thuộc tính của mình, thì đối tượng của bạn (theo ngữ nghĩa Java 5) được bảo đảm để được xây dựng chính xác và vì nó cũng có thể được xuất bản một cách an toàn để chủ đề khác.

Đối tượng bất biến không chỉ là về an toàn luồng. Chúng cũng làm cho lý do dễ dàng hơn nhiều về lý do chuyển trạng thái trong chương trình của bạn, bởi vì không gian của những gì có thể thay đổi là có chủ ý và, nếu được sử dụng một cách nhất quán, chỉ giới hạn triệt để những thứ nên thay đổi.

Đôi khi tôi cũng thực hiện các phương thức cuối cùng, nhưng không thường xuyên. Tôi hiếm khi làm cho lớp học cuối cùng. Tôi thường làm điều này bởi vì tôi có ít nhu cầu. Tôi thường không sử dụng thừa kế nhiều. Tôi thích sử dụng các giao diện và thành phần đối tượng thay thế - điều này cũng cho vay một thiết kế mà tôi thấy thường dễ kiểm tra hơn. Khi bạn mã hóa các giao diện thay vì các lớp cụ thể, thì bạn không cần sử dụng tính kế thừa khi kiểm tra, vì nó là, với các khung như jMock, việc tạo các đối tượng giả với giao diện dễ dàng hơn nhiều so với các lớp cụ thể.

Tôi đoán tôi nên làm cho phần lớn các lớp học của mình cuối cùng, nhưng tôi vẫn chưa vào được hợi.

Tôi phải đọc rất nhiều mã cho công việc của tôi. Thiếu cuối cùng trên các biến thể hiện là một trong những điều hàng đầu làm tôi khó chịu và khiến việc hiểu mã trở nên khó khăn không cần thiết. Đối với tiền của tôi, cuối cùng về các biến cục bộ gây ra sự lộn xộn hơn là rõ ràng. Ngôn ngữ nên được thiết kế để biến nó thành mặc định, nhưng chúng ta phải sống với sai lầm. Đôi khi nó rất hữu ích đặc biệt với các vòng lặp và gán xác định với cây if-other, nhưng chủ yếu là nó có xu hướng chỉ ra phương thức của bạn quá phức tạp.

cuối cùng rõ ràng nên được sử dụng trên các hằng số, và để thực thi tính bất biến, nhưng có một cách sử dụng quan trọng khác trên các phương thức.

Java hiệu quả có toàn bộ mục này (Mục 15) chỉ ra những cạm bẫy của thừa kế ngoài ý muốn. Hiệu quả nếu bạn không thiết kế và lập tài liệu cho lớp của mình để kế thừa, kế thừa từ nó có thể đưa ra các vấn đề không mong muốn (mục này đưa ra một ví dụ tốt). Do đó, khuyến nghị là bạn nên sử dụng cuối cùng trên bất kỳ lớp và / hoặc phương thức nào không được dự định kế thừa từ đó.

Điều đó có vẻ hà khắc, nhưng nó có ý nghĩa. Nếu bạn đang viết thư viện lớp để người khác sử dụng thì bạn không muốn họ kế thừa từ những thứ không được thiết kế cho nó - bạn sẽ tự khóa mình vào một triển khai cụ thể của lớp để tương thích trở lại. Nếu bạn đang viết mã trong một đội, không có gì ngăn cản một thành viên khác trong nhóm xóa trận chung kết nếu họ thực sự phải làm vậy. Nhưng từ khóa làm cho họ nghĩ về những gì họ đang làm và cảnh báo họ rằng lớp họ đang kế thừa không được thiết kế cho nó, vì vậy họ nên cẩn thận hơn.

Một cảnh báo khác là nhiều người nhầm lẫn cuối cùng có nghĩa là nội dung của biến thể hiện không thể thay đổi, thay vì tham chiếu không thể thay đổi.

Ngay cả đối với các biến cục bộ, biết rằng nó được khai báo cuối cùng có nghĩa là tôi không cần phải lo lắng về việc tham chiếu được thay đổi sau này. Điều này có nghĩa là khi gỡ lỗi và tôi thấy biến đó sau này, tôi tự tin rằng nó đang đề cập đến cùng một đối tượng. Đó là một điều ít hơn tôi cần phải lo lắng khi tìm kiếm một lỗi. Một phần thưởng là nếu 99% các biến được khai báo là cuối cùng, thì một vài biến thực sự là biến sẽ nổi bật hơn. Ngoài ra, trận chung kết cho phép trình biên dịch tìm thấy một số lỗi ngu ngốc có thể xảy ra mà không được chú ý.

Việc chọn gõ finalcho từng tham số trong mỗi phương thức sẽ tạo ra rất nhiều kích thích cho cả người viết mã và người đọc mã.

Khi sự khó chịu vượt quá chuyển đổi hợp lý sang Scala, nơi các đối số là cuối cùng theo mặc định.

Hoặc, bạn luôn có thể sử dụng các công cụ tạo kiểu mã sẽ tự động làm điều đó cho bạn. Tất cả các IDE đã thực hiện chúng hoặc như các plugin.

Cuối cùng khi được sử dụng với các biến trong Java cung cấp một thay thế cho hằng số trong C ++. Vì vậy, khi cuối cùng và tĩnh được sử dụng cho một biến, nó trở thành bất biến. Đồng thời làm cho các lập trình viên C ++ di chuyển khá hạnh phúc ;-)

Khi được sử dụng với các biến tham chiếu, nó không cho phép bạn tham chiếu lại đối tượng, mặc dù đối tượng có thể được thao tác.

Khi cuối cùng được sử dụng với một phương thức, nó không cho phép phương thức bị vượt quá bởi các lớp con.

Một khi việc sử dụng rất rõ ràng, nó nên được sử dụng cẩn thận. Nó chủ yếu phụ thuộc vào thiết kế vì sử dụng cuối cùng vào phương pháp sẽ không giúp ích cho đa hình.

Người ta chỉ nên sử dụng nó cho các biến khi bạn chắc chắn rằng giá trị của biến sẽ / không bao giờ được thay đổi. Đồng thời đảm bảo rằng bạn tuân theo quy ước mã hóa được khuyến khích bởi SUN.for ví dụ: Final int COLOR_RED = 1; (Chữ hoa được phân tách bằng dấu gạch dưới)

Với một biến tham chiếu, chỉ sử dụng nó khi chúng ta cần một tham chiếu bất biến cho một đối tượng cụ thể.

Về phần dễ đọc, đảm bảo rằng các bình luận đóng vai trò rất quan trọng khi sử dụng công cụ sửa đổi cuối cùng.

Tôi không bao giờ sử dụng chúng trên các biến cục bộ, có rất ít điểm cho tính dài dòng được thêm vào. Ngay cả khi bạn không nghĩ rằng biến nên được chỉ định lại, điều đó sẽ tạo ra một chút khác biệt cho người tiếp theo thay đổi mã nghĩ khác và vì mã đang được thay đổi, bất kỳ mục đích ban đầu nào để làm cho nó cuối cùng có thể không còn hiệu lực. Nếu nó chỉ là cho rõ ràng, tôi tin rằng nó thất bại do những tác động tiêu cực của tính dài dòng.

Khá nhiều điều tương tự cũng áp dụng cho các biến thành viên, vì chúng cung cấp rất ít lợi ích, ngoại trừ trường hợp các hằng số.

Nó cũng không có liên quan đến tính bất biến, vì chỉ số tốt nhất của một thứ bất biến là nó được ghi lại như vậy và / hoặc không có phương pháp nào có thể thay đổi đối tượng (điều này, cùng với việc tạo ra lớp cuối cùng là cách duy nhất để đảm bảo rằng nó là bất biến).

Nhưng này, đó chỉ là ý kiến ​​của tôi :-)

Tôi thiết lập Eclipse để thêm cuối cùng trên tất cả các trường và thuộc tính không được sửa đổi. Điều này hoạt động rất tốt khi sử dụng "các hành động lưu" của Eclipse để thêm các sửa đổi cuối cùng này (trong số những thứ khác) khi lưu tệp.

Rất khuyến khích.

Kiểm tra bài viết trên blog của tôi về Eclipse Save Action.

Đối với tranh luận tôi nghĩ rằng họ không cần thiết. Mostley họ chỉ làm tổn thương sự sẵn sàng. Việc gán lại một biến đối số là cực kỳ ngu ngốc đến nỗi tôi nên khá tự tin rằng dù sao chúng cũng có thể được coi là hằng số.

Thực tế là các màu Eclipse cuối cùng màu đỏ giúp dễ dàng phát hiện các khai báo biến trong mã mà tôi nghĩ rằng hầu hết thời gian đều dễ đọc hơn.

Tôi cố gắng thực thi quy tắc rằng bất kỳ và tất cả các biến phải là cuối cùng, đó không phải là một lý do hợp lệ cực đoan. Thật dễ dàng hơn nhiều để trả lời "biến này là gì?" câu hỏi nếu bạn chỉ cần tìm sự khởi đầu và tự tin rằng đó là nó.

Tôi thực sự trở nên khá lo lắng xung quanh các biến không phải là cuối cùng một ngày. Nó giống như sự khác biệt giữa việc có một con dao treo trong một sợi chỉ làm mất đầu bạn, hoặc chỉ cần có nó trong ngăn kéo nhà bếp ...

Một biến cuối cùng chỉ là một cách tốt đẹp cho các giá trị lable.

Một biến không phải là cuối cùng bị ràng buộc với một phần của thuật toán dễ bị lỗi.

Một tính năng hay là khi tùy chọn sử dụng một biến trong câu hỏi cho một thuật toán hầu hết thời gian, việc giải quyết là viết một phương thức thay thế, điều này thường giúp cải thiện mã đáng kể.

Tôi đã mã hóa được một lúc rồi và sử dụng cuối cùng bất cứ khi nào tôi có thể. Sau khi làm điều này một lúc (đối với các biến, tham số phương thức và thuộc tính lớp), tôi có thể nói rằng 90% (hoặc nhiều hơn) các biến của tôi thực sự là cuối cùng. Tôi nghĩ rằng lợi ích của việc KHÔNG có các biến được sửa đổi khi bạn không muốn (tôi đã thấy điều đó trước đây và đôi khi thật đau đớn) trả tiền cho việc gõ thêm và các từ khóa "cuối cùng" trong mã của bạn.

Điều đó đang được nói, nếu tôi sẽ thiết kế một ngôn ngữ, tôi sẽ biến mọi biến thành cuối cùng trừ khi được sửa đổi bởi một số từ khóa khác.

Tôi không sử dụng cuối cùng rất nhiều cho các lớp học và phương pháp, suy nghĩ. Đây là một lựa chọn thiết kế ít nhiều phức tạp, trừ khi lớp của bạn là lớp tiện ích (trong trường hợp đó bạn chỉ nên có một hàm tạo riêng).

Tôi cũng sử dụng Collections.unmodifiable ... để tạo danh sách không thể thay đổi khi tôi cần.

Sử dụng các lớp cục bộ ẩn danh cho người nghe sự kiện và đó là một mô hình phổ biến trong Java. Việc sử dụng phổ biến nhất của từ khóa cuối cùng là đảm bảo rằng các biến trong phạm vi có thể truy cập được đối với người nghe.

Tuy nhiên, nếu bạn thấy mình được yêu cầu đặt nhiều câu lệnh cuối cùng vào mã của mình. Đó có thể là một gợi ý tốt khi bạn làm sai điều gì đó.

Bài viết được đăng ở trên đưa ra ví dụ này:

public void doSomething(int i, int j) {
    final int n = i + j; // must be declared final

    Comparator comp = new Comparator() {
        public int compare(Object left, Object right) {
            return n; // return copy of a local variable
        }
    };
}

Tôi sử dụng nó cho hằng số bên trong và bên ngoài phương pháp.

Đôi khi tôi chỉ sử dụng nó cho các phương thức vì tôi không biết liệu một lớp con KHÔNG muốn ghi đè một phương thức đã cho hay không (vì bất kỳ lý do gì).

Theo như các lớp học, chỉ đối với một số lớp cơ sở hạ tầng, tôi đã sử dụng lớp cuối cùng.

IntelliJ IDEA cảnh báo bạn nếu một tham số chức năng được ghi vào bên trong một chức năng. Vì vậy, tôi đã ngừng sử dụng cuối cùng cho các đối số chức năng. Tôi không thấy chúng trong thư viện java Runtime.

Tôi hầu như không sử dụng cuối cùng trên các phương thức hoặc các lớp vì tôi thích cho phép mọi người ghi đè lên chúng.

Mặt khác, tôi chỉ sử dụng cuối cùng nếu nó là một public/private static final type SOME_CONSTANT;

Đánh dấu lớp cuối cùng cũng có thể làm cho một số ràng buộc phương thức xảy ra tại thời gian biên dịch thay vì thời gian chạy. Xem xét "v2.foo ()" bên dưới - trình biên dịch biết rằng B không thể có một lớp con, vì vậy foo () không thể bị ghi đè để thực hiện cuộc gọi được gọi vào thời gian biên dịch. Nếu lớp B KHÔNG được đánh dấu cuối cùng, thì có thể loại v2 thực tế là một số lớp mở rộng B và ghi đè foo ().

class A {
    void foo() {
        //do something
    }
}
final class B extends A {
    void foo() {
    }
}
class Test {
    public void t(A v1, B v2) {
        v1.foo();
        v2.foo();
    }
}

Sử dụng cuối cùng cho hằng số được khuyến khích mạnh mẽ. Tuy nhiên, tôi sẽ không sử dụng nó cho các phương thức hoặc các lớp (hoặc ít nhất là nghĩ về nó trong một thời gian), vì nó làm cho việc kiểm tra khó hơn, nếu không nói là không thể. Nếu bạn hoàn toàn phải thực hiện một lớp hoặc phương thức cuối cùng, hãy đảm bảo rằng lớp này thực hiện một số giao diện, để bạn có thể có một giả lập thực hiện cùng một giao diện.