Trong các luồng Java có thực sự chỉ dùng để gỡ lỗi?

Tôi đang đọc về các luồng Java và khám phá những điều mới khi tôi đi cùng. Một trong những điều mới tôi tìm thấy là peek()chức năng. Hầu hết mọi thứ tôi đã đọc trên peek đều nói rằng nó nên được sử dụng để gỡ lỗi Luồng của bạn.

Điều gì xảy ra nếu tôi có Luồng trong đó mỗi Tài khoản có tên người dùng, trường mật khẩu và phương thức login () và loginIn ().

tôi cũng có

Consumer<Account> login = account -> account.login();

và

Predicate<Account> loggedIn = account -> account.loggedIn();

Tại sao điều này sẽ rất tệ?

List<Account> accounts; //assume it's been setup
List<Account> loggedInAccount = 
accounts.stream()
    .peek(login)
    .filter(loggedIn)
    .collect(Collectors.toList());

Bây giờ theo như tôi có thể nói điều này thực hiện chính xác những gì nó dự định làm. Nó;

• Có một danh sách các tài khoản
• Thử đăng nhập vào từng tài khoản
• Lọc bất kỳ tài khoản nào không đăng nhập
• Thu thập các tài khoản đã đăng nhập vào một danh sách mới

Nhược điểm của việc làm một cái gì đó như thế này là gì? Bất kỳ lý do tôi không nên tiến hành? Cuối cùng, nếu không phải là giải pháp này thì sao?

Phiên bản gốc của điều này đã sử dụng phương thức .filter () như sau;

.filter(account -> {
        account.login();
        return account.loggedIn();
    })

Điểm nổi bật của việc này:

Đừng sử dụng API theo cách không có chủ ý, ngay cả khi nó hoàn thành mục tiêu trước mắt của bạn. Cách tiếp cận đó có thể bị phá vỡ trong tương lai, và nó cũng không rõ ràng đối với những người duy trì trong tương lai.

Không có hại trong việc phá vỡ điều này ra nhiều hoạt động, vì chúng là các hoạt động riêng biệt. có là tác hại trong việc sử dụng API trong một cách không rõ ràng và không lường trước, trong đó có thể có tác hại nếu hành vi đặc biệt này được sửa đổi trong các phiên bản tương lai của Java.

Sử dụng forEachcho hoạt động này sẽ làm cho người bảo trì thấy rõ rằng có một tác dụng phụ dự định đối với từng yếu tố củaaccounts và rằng bạn đang thực hiện một số thao tác có thể làm thay đổi nó.

Nó cũng thông thường hơn theo nghĩa peeklà một hoạt động trung gian không hoạt động trên toàn bộ bộ sưu tập cho đến khi hoạt động của thiết bị đầu cuối chạy, nhưng forEachthực sự là một hoạt động đầu cuối. Bằng cách này, bạn có thể đưa ra những lập luận mạnh mẽ xung quanh hành vi và dòng mã của mình thay vì đặt câu hỏi về việc liệu peekcó hành xử giống như forEachtrong bối cảnh này hay không.

accounts.forEach(a -> a.login());
List<Account> loggedInAccounts = accounts.stream()
                                         .filter(Account::loggedIn)
                                         .collect(Collectors.toList());

Điều quan trọng bạn phải hiểu là các luồng được điều khiển bởi hoạt động của thiết bị đầu cuối . Hoạt động của thiết bị đầu cuối xác định liệu tất cả các yếu tố phải được xử lý hay bất kỳ yếu tố nào. Vì vậy, collectmột hoạt động xử lý từng mục, trong khi findAnycó thể dừng xử lý các mục một khi nó gặp một yếu tố phù hợp.

Và count()có thể không xử lý bất kỳ yếu tố nào khi nó có thể xác định kích thước của luồng mà không xử lý các mục. Vì đây là một tối ưu hóa không được thực hiện trong Java 8, nhưng sẽ có trong Java 9, nên có thể có những bất ngờ khi bạn chuyển sang Java 9 và có mã dựa vào count()xử lý tất cả các mục. Điều này cũng được kết nối với các chi tiết phụ thuộc vào triển khai khác, ví dụ, ngay cả trong Java 9, việc triển khai tham chiếu sẽ không thể dự đoán kích thước của nguồn luồng vô hạn kết hợp vớilimit trong khi không có giới hạn cơ bản nào ngăn chặn dự đoán đó.

Vì peekcho phép những người thực hiện hành động được cung cấp trên mỗi thành phần khi các phần tử được tiêu thụ từ luồng kết quả , nên nó không bắt buộc xử lý các phần tử nhưng sẽ thực hiện hành động tùy thuộc vào nhu cầu hoạt động của thiết bị đầu cuối. Điều này ngụ ý rằng bạn phải sử dụng nó một cách cẩn thận nếu bạn cần một quá trình xử lý cụ thể, ví dụ muốn áp dụng một hành động trên tất cả các yếu tố. Nó hoạt động nếu hoạt động của thiết bị đầu cuối được đảm bảo xử lý tất cả các mục, nhưng ngay cả khi đó, bạn phải chắc chắn rằng không phải nhà phát triển tiếp theo thay đổi hoạt động của thiết bị đầu cuối (hoặc bạn quên khía cạnh tinh tế đó).

Hơn nữa, trong khi các luồng đảm bảo duy trì thứ tự bắt gặp cho một sự kết hợp hoạt động nhất định ngay cả đối với các luồng song song, các bảo đảm này không áp dụng cho peek. Khi thu thập vào một danh sách, danh sách kết quả sẽ có thứ tự đúng cho các luồng song song được sắp xếp, nhưng peekhành động có thể được gọi theo thứ tự tùy ý và đồng thời.

Vì vậy, điều hữu ích nhất bạn có thể làm peeklà tìm hiểu xem phần tử luồng đã được xử lý chưa, đó chính xác là những gì tài liệu API nói:

Phương thức này tồn tại chủ yếu để hỗ trợ gỡ lỗi, nơi bạn muốn xem các phần tử khi chúng chảy qua một điểm nhất định trong đường ống

Có lẽ một nguyên tắc nhỏ là nếu bạn sử dụng peek ngoài kịch bản "gỡ lỗi", bạn chỉ nên làm như vậy nếu bạn chắc chắn về các điều kiện lọc kết thúc và lọc trung gian là gì. Ví dụ:

return list.stream().map(foo->foo.getBar())
                    .peek(bar->bar.publish("HELLO"))
                    .collect(Collectors.toList());

dường như là một trường hợp hợp lệ mà bạn muốn, trong một thao tác để chuyển đổi tất cả các Foos thành Bars và nói với họ tất cả xin chào.

Có vẻ hiệu quả và thanh lịch hơn những thứ như:

List<Bar> bars = list.stream().map(foo->foo.getBar()).collect(Collectors.toList());
bars.forEach(bar->bar.publish("HELLO"));
return bars;

và bạn không kết thúc việc lặp lại một bộ sưu tập hai lần.

Tôi có thể nói rằng nó peekcung cấp khả năng phân cấp mã có thể làm thay đổi các đối tượng luồng hoặc sửa đổi trạng thái toàn cầu (dựa trên chúng), thay vì nhồi mọi thứ vào một hàm đơn giản hoặc được tạo thành một phương thức đầu cuối.

Bây giờ câu hỏi có thể là: chúng ta có nên thay đổi các đối tượng luồng hoặc thay đổi trạng thái toàn cầu từ bên trong các hàm trong lập trình java kiểu chức năng không?

Nếu câu trả lời cho bất kỳ bên trên 2 câu hỏi là có (hoặc: trong một số trường hợp có) sau đó peek()là chắc chắn không phải chỉ dành cho mục đích gỡ lỗi , vì lý do tương tự mà forEach()không chỉ dành cho mục đích gỡ lỗi .

Đối với tôi khi lựa chọn giữa forEach()vàpeek() , là chọn các tùy chọn sau: Tôi có muốn các đoạn mã làm thay đổi các đối tượng luồng được gắn vào một bộ tổng hợp hay tôi muốn chúng gắn trực tiếp vào luồng?

Tôi nghĩ rằng peek()sẽ kết hợp tốt hơn với các phương thức java9. ví dụ takeWhile()có thể cần phải quyết định khi nào dừng lặp lại dựa trên một đối tượng đã bị đột biến, do đó, việc so sánh nó với nó forEach()sẽ không có tác dụng tương tự.

PS Tôi chưa tham chiếu ở map()bất cứ đâu vì trong trường hợp chúng tôi muốn thay đổi các đối tượng (hoặc trạng thái toàn cầu), thay vì tạo các đối tượng mới, nó hoạt động chính xác như thế peek().

Mặc dù tôi đồng ý với hầu hết các câu trả lời ở trên, tôi có một trường hợp trong đó sử dụng peek thực sự có vẻ là cách sạch nhất để đi.

Tương tự như trường hợp sử dụng của bạn, giả sử bạn chỉ muốn lọc trên các tài khoản đang hoạt động và sau đó thực hiện đăng nhập vào các tài khoản này.

accounts.stream()
    .filter(Account::isActive)
    .peek(login)
    .collect(Collectors.toList());

Peek rất hữu ích để tránh cuộc gọi dư thừa trong khi không phải lặp lại bộ sưu tập hai lần:

accounts.stream()
    .filter(Account::isActive)
    .map(account -> {
        account.login();
        return account;
    })
    .collect(Collectors.toList());

Các giải pháp chức năng là làm cho đối tượng tài khoản bất biến. Vì vậy, account.login () phải trả về một đối tượng tài khoản mới. Điều này có nghĩa là hoạt động bản đồ có thể được sử dụng để đăng nhập thay vì nhìn trộm.