Câu hỏi Chơi! khuôn khổ sử dụng số liệu thống kê


Waaah, Play! khuôn khổ có rất nhiều phương pháp tĩnh. Tôi đi học ở đâu chưa bao giờ để sử dụng bất kỳ thống kê nào, nhưng Play! sử dụng nó như không có ngày mai. Có phải không? Nếu vậy, tại sao?

Chúng tôi (7 người và tôi) đang có kế hoạch sử dụng Play! khuôn khổ cho một dự án liên quan đến một ứng dụng web. Chúng tôi quyết định làm điều đó với Play! bởi vì nó có vẻ khá thú vị để làm, tất cả chúng ta đã biết Java và nhiệm vụ khá khó khăn nên chúng tôi muốn tập trung vào nhiệm vụ thực tế hơn là học cách lập trình bằng một ngôn ngữ khác.

Tuy nhiên, chúng tôi luôn được bảo, CHƯA BAO GIỜ để sử dụng 'tĩnh trong bất kỳ chương trình Java nào mà chúng tôi đã phát triển, nhưng khi tôi nhìn vào Play! ... À ... khoảng một nửa phương pháp là tĩnh. </ cường điệu>

Tôi cho rằng, ít nhất, chúng ta có thể sử dụng các đối tượng đơn lẻ (bằng cách sử dụng Scala, ví dụ ^^) để lập trình dự án của chúng tôi, nhưng tôi khá lo lắng về việc có bao nhiêu số liệu thống kê trong chính khung công tác.

Vì vậy, tôi có nên lo lắng về điều này? Đã làm cách chơi! các nhà phát triển đã lập trình nó làm cho nó để tất cả các statics này không đặt ra một vấn đề?

(Ví dụ, chủ đề này có một ý kiến ​​về lý do tại sao các thành viên tĩnh nên tránh bằng mọi giá.)


76
2018-03-04 11:06


gốc


Uh ... Bạn có lẽ nên hỏi giáo sư của bạn, hoặc bất cứ ai. Ngoài ra, nó là tự nhiên cho phần còn lại của thế giới không đăng ký với những ý tưởng tương tự về thực hành lập trình tốt và xấu như chính mình, vì vậy làm quen với ý tưởng. :) - unwind
@ Mặc dù sử dụng số liệu thống kê được khuyến khích, "KHÔNG BAO GIỜ SỬ DỤNG thống kê" là một cách nói quá - Suraj Chandran
các <exaggeration> không hiển thị. :) - Nishant
Đó là điều, giáo sư của chúng tôi là một người theo chủ nghĩa thuần túy OO. Anh ta luôn cảnh báo chúng ta về những nguy hiểm khi sử dụng statics và anh ta sẽ có đầu của chúng tôi để sử dụng statics trừ khi chúng tôi có thể đưa ra một lời giải thích hợp lý tại sao chúng ta vẫn sử dụng chúng và không sợ có hậu quả. - Saew
@Hishant Bây giờ nó là :) - jensgram


Các câu trả lời:


Play chỉ sử dụng các phương thức tĩnh khi có ý nghĩa:

  • trong lớp điều khiển, bởi vì bộ điều khiển không hướng đối tượng. Bộ điều khiển đóng vai trò như người lập bản đồ giữa thế giới HTTP (không trạng thái, và yêu cầu / phản hồi dựa) và lớp Mô hình hoàn toàn hướng đối tượng.
  • trong lớp mô hình cho các phương thức nhà máy, như findAll (), count (), create () mà tất nhiên không phụ thuộc vào bất kỳ trường hợp cụ thể nào
  • trong một số play.libs. * các lớp cung cấp các hàm tiện ích hoàn toàn

95
2018-03-04 12:31



Ngoài ra, vấn đề chính là các thành viên tĩnh không phải là phương thức tĩnh. Trong khi chơi, chỉ có các luồng dữ liệu là các thành viên tĩnh. - niels
Việc sử dụng tĩnh validation hội viên  (xem thí dụ) kết hợp với một ThreadLocal cho thấy, tĩnh đó không thích hợp trong mọi trường hợp. - deamon
Tôi đang sử dụng để có bộ điều khiển có phụ thuộc tiêm thông qua một khuôn khổ DI. Làm thế nào bạn sẽ thực hiện DI bằng cách sử dụng các đối tượng tĩnh? - ripper234
@Guillaume Tôi phải không đồng ý với bạn rất nhiều, Chơi cho thấy các thực hành tồi tệ nhất của việc viết Java và không nên có lý do gì để sử dụng statics trong mã Java, bao giờ hết. Tính không thay đổi không được chỉ định bởi các số liệu thống kê, hoàn toàn trái ngược cho biết trạng thái chia sẻ đó là khá nhiều đối diện với những gì bạn đang tuyên bố. Sau đó, tất nhiên có những công cụ thú vị phản ánh như gọi phương thức tĩnh trên trường hợp sai vì các phương thức tĩnh thậm chí không được ghép nối với lớp mà chúng được định nghĩa. Tóm lại, statictrong Java là một mùi mã rất lớn và không nên có mặt ở tất cả nếu bạn đang nhằm mục đích là viết Java hiện đại. - Esko
@Esko Tôi chắc chắn đồng ý với bạn, Play có thể có giá trị trong scala, nhưng trong Java nó tổng hợp một danh sách các thực hành xấu. - Snicolas


Khung chơi không phải là một minh chứng tốt khi sử dụng các số liệu thống kê phù hợp, và cũng không chứng tỏ rằng giáo viên của bạn đã sai. Chơi là loại gian lận, giải quyết các vấn đề về thống kê bên ngoài ngôn ngữ Java.

Vấn đề chính là bạn phải xử lý nhiều yêu cầu HTTP song song và các trường tĩnh là "toàn cục". Vì vậy, bạn sẽ cần một cá thể cho mỗi chuỗi (hoặc thậm chí tốt hơn, một ví dụ cho mỗi yêu cầu HTTP) cho một số thứ, nhưng một số trong những thứ đó được trả về bằng các phương thức tĩnh trong Play. Điều đó có hiệu quả vì Play! sử dụng ThreadLocal-s rất nhiều, và do đó nó giải quyết một vấn đề của statics bên ngoài ngôn ngữ Java. Nhưng đó không phải là tất cả. Một số người nói rằng các phương pháp điều khiển là đúng đắn. Chắc chắn, nhưng trong Java đơn giản nó sẽ là bất tiện, như sau đó bạn không thể truy cập dữ liệu yêu cầu cụ thể mà không có một số loại tiền tố, như req. trong req.sessionvà sau đó bạn vẫn phải req từ đâu đó, giống như tham số của phương thức điều khiển tĩnh, điều này thậm chí còn phức tạp hơn. Tuy nhiên, trong Play bạn có thể chỉ cần viết trực tiếp session và thích, chúng chỉ là các trường tĩnh. Đó là bởi vì Play sử dụng công cụ bytecode để thay đổi tất cả các tham chiếu trường tĩnh đó thành một cái gì đó thông minh hơn. Một lần nữa, một giải pháp bên ngoài ngôn ngữ Java. Đó không phải là các lĩnh vực tĩnh ở cuối.

Vì vậy, nói chung, tránh các thống kê phi chính thức. Chơi không có phép thuật cho bạn mặc dù, do đó, không sợ chúng trong trường hợp này.


34
2017-08-04 19:15





Từ một cái nhìn rất ngắn gọn, tôi muốn nói rằng nó có ý nghĩa: yêu cầu web là không trạng thái, vì vậy có  không có đối tượng nào để nhận yêu cầu (= phương thức). Do đó, ánh xạ một URI như "/ articles / archive? Date = 08/01/08 & page = 2" vào một phương thức tĩnh được gọi là archive() trên, tôi đoán, lớp ứng dụng của bạn có ý nghĩa.


15
2018-03-04 11:12





CHỈNH SỬA Bây giờ trong Play 2.4, Chích được thực hiện tự động. Vì vậy, chỉ cần thêm @ ở đầu đường dẫn bộ điều khiển trong tệp routes sẽ làm cho lừa:

GET     /                  @controllers.Application.index()

Đối với các phiên bản cũ (2.1 đến 2.3), bạn sẽ phải ghi đè getControllerInstance trong lớp Global, như được giải thích trong Tài liệu.


8
2017-12-14 01:59





Như với bất kỳ thứ gì trong lập trình, chưa bao giờ không bao giờ là câu trả lời đúng. Giống như luôn luôn. Luôn có những ngoại lệ và câu trả lời đúng luôn là 'nó phụ thuộc'.

Đúng là trong OO thuần túy (mà tôi là tất cả cho) có rất ít chỗ cho statics. Nhưng nó cũng đúng rằng đôi khi họ chỉ có ý nghĩa.

Ví dụ cổ điển là phương pháp tiện ích. Chắc chắn, sẽ tốt hơn nếu chúng ta có thể nối thêm abs() phương pháp để Integer. Nhưng chúng ta không thể; vì vậy chúng tôi đang mắc kẹt với Math.abs(int i).

Tôi có xu hướng nghĩ rằng nó chỉ là chính xác để làm cho một phương thức tĩnh khi nó không có gì để làm với bản thân cá thể đó. Ví dụ, trong một lớp học Person, bạn có thể có một phương thức lấy danh sách người và trả về số người có sinh nhật hôm nay. Có lẽ bạn chỉ có thể thực hiện điều này trong chính lớp nếu dữ liệu cần thiết để tính toán là riêng tư (một cái gì đó mà OO purist hiểu;)) nhưng phương thức rõ ràng không liên quan đến một cá thể Person đơn lẻ.

Một điều nữa là các lớp bên trong. Bạn thường muốn làm cho chúng tĩnh nếu bạn không cần quan hệ với kiểu chứa.

tôi chưa từng thấy Chơi! nhưng nếu bạn nói rằng hơn 50% của nó là tĩnh, thì tôi đoán nó có lẽ đã được thiết kế tồi tệ. Đó không phải là ngoại lệ; rất nhiều khung công tác. Đừng để nó làm bạn thất vọng. Chắc chắn không học hỏi từ nó!
Nhưng nếu nó hoạt động bạn vẫn có thể sử dụng nó.


5
2018-03-04 12:11



Chơi không được thiết kế tồi, nhưng nó là một sự khởi đầu từ cách mà hầu hết các thư viện Java được thiết kế. - Marcus Downing


Vấn đề chính là các phương thức tĩnh chỉ có quyền truy cập vào các phương thức tĩnh và các trường khác, kết quả là 'liên kết tĩnh' theo đó các phương thức tĩnh phải kết hợp với phần còn lại của ứng dụng (có chứa các cộng tác viên của nó) thông qua các trường tĩnh chung , dẫn đến tính không linh hoạt.

Disclaimer: Tôi không biết nhiều về 'chơi!'


4
2018-03-04 11:41





Phương pháp điều khiển tĩnh chắc chắn là một lĩnh vực quan tâm với Play! khuôn khổ, và sau khi đã làm một số thử nghiệm, đó là lý do chính cho tôi không làm chơi! trong các dự án. Bạn thực sự có thể thấy điều này trong các dự án FOSS nơi Play! Được sử dụng. Có rất ít hoặc không có kiểm tra bộ điều khiển. Lý do, với phương pháp tĩnh, DI trở nên khó khăn. Đây là nơi họ nên dành nhiều thời gian hơn với ASP.NET MVC, từ nơi Play! đã mất một chút cảm hứng.

Thông thường bạn có một hàm tạo như sau:

public HomeController( IService service ) {
   _service = service;
}
public Index() {
   var data = _service.getData();
   return View( data );
}

Sau đó, bạn sử dụng DI để tiêm triển khai IService vào Controller. Vấn đề là trong các thử nghiệm của bạn, bạn có thể khởi tạo IService ngay trước khi chạy Controller, và sau đó kiểm tra kết quả dựa trên IService mà bạn vừa tạo ra.

Trong chơi này trở nên rất khó khăn. Vì vậy, kiểm tra đơn vị điều khiển trở nên khó khăn. Đó là, đối với tôi, một vấn đề quan trọng. Do đó, tôi có xu hướng tìm kiếm các khung công tác khác ngoài Play! trong thế giới Java. Heck, tại sao không đi với bản gốc và chỉ sử dụng JRuby?


4
2017-10-29 12:36





Phương pháp thống kê trong chơi chủ yếu được sử dụng trong các phương pháp hành động của bộ điều khiển. Các phương thức này có nghĩa là chỉ cần lấy dữ liệu cần thiết từ mô hình và đưa nó vào các khung nhìn.

Chúng tương ứng bằng cách nào đó với mỗi yêu cầu http có thể, và, giống như những yêu cầu http đó hoàn toàn vô quốc tịch.

Về lập trình cấu trúc, bạn có các thủ tục trên một mặt, và các biến khác, nhưng trên mô hình OOP bạn xử lý các thủ tục và các biến như một tổng thể.

Tức là, bạn có và đối tượng với các phương thức instance (các thủ tục) và các biến mẫu.

Nhưng hành động điều khiển là không trạng thái, nghĩa là chúng nhận được tất cả các biến từ yêu cầu (có thể cũng từ bộ nhớ cache, nhưng trong trường hợp đó bạn cần một số loại id phiên cuối cùng xuất phát từ yêu cầu). Vì vậy, các hành động của bộ điều khiển giống như các thủ tục của stateles, và đó là lý do tại sao chúng không đặc biệt phù hợp với mô hình OOP, như các mô hình.


3
2018-03-05 05:12