Mã nào trong hai mã này là 'tốt hơn'? Làm biến cục bộ hay biến lớp?

Tôi đang làm nhiều trò chơi hơn và hỏi những câu hỏi ngu ngốc hơn.

Hy vọng rằng điều này là rất ngắn gọn. Tôi đang tạo một lớp rất cơ bản, chỉ di chuyển một đối tượng Người chơi bằng cách tác dụng lực lên một người cứng nhắc, nhưng điều đó làm tôi băn khoăn, liệu tôi có nên tạo một tham chiếu lớp cho rb hay chỉ là một biến cục bộ trong Cập nhật mọi khung hình? (ghi nhớ rằng nó đã tồn tại trong lớp cha mẹ đơn nhất Monobehaviour.GameObject).

Tôi tự hỏi nếu thực hiện nhiều biến cục bộ sẽ làm chậm toàn bộ vòng lặp (theo ý tôi cục bộ bên trong hàm chứ không phải ở đầu lớp - hy vọng tôi sử dụng thuật ngữ chính xác).

Ý tôi là đây, hai cách tôi nghĩ khi làm nó:

public class Player : MonoBehaviour {

private void FixedUpdate()
{
    Rigidbody rb = GetComponent<Rigidbody>();

    float v = Input.GetAxis("Vertical");

    rb.AddForce(v * rb.transform.forward * Const.walkForce);
}
}

hoặc là...

public class Player : MonoBehaviour {
Rigidbody rb;

private void Awake()
{
    rb = GetComponent<Rigidbody>();
}

private void FixedUpdate()
{
    float v = Input.GetAxis("Vertical");

    rb.AddForce(v * rb.transform.forward * Const.walkForce);
}
}

Nói chung, tôi thấy rằng bạn nên bắt đầu phạm vi dữ liệu càng hẹp càng tốt để bắt đầu và mở rộng phạm vi khi bạn phát hiện ra mình cần. Điều đó có nghĩa là nếu bạn có thể biến nó thành một biến cục bộ thay vì thành viên, có lẽ bạn nên bắt đầu từ đó.

Điều này là do phạm vi hẹp hơn làm giảm số lượng vị trí trong mã nơi bạn phải suy luận về dữ liệu đó và do đó làm giảm số lượng vị trí bạn có thể suy luận về dữ liệu đó không chính xác (dẫn đến lỗi).

Trên thực tế, chỉ riêng việc khai báo các biến cục bộ sẽ không bao giờ trở thành mối quan tâm về hiệu năng: chúng rẻ và các trình biên dịch hiện đại thậm chí có thể tối ưu hóa các "tính năng bổ sung".

Khởi tạo chúng có thể là một mối quan tâm; trong trường hợp của bạn, cơ thể cứng nhắc của bạn được tìm kiếm mỗi lần thông qua GetComponent, có một số chi phí khác không. Nếu bạn biết rằng thành phần cơ thể cứng nhắc sẽ không thay đổi cho đối tượng trò chơi cụ thể này, bạn có thể tra cứu nó một lần và lưu kết quả vào một biến thành viên và tránh một chút chi phí cho mỗi cuộc gọi.

Không chắc rằng chi phí cho mỗi cuộc gọi sẽ có ý nghĩa trong trường hợp này, nhưng theo thời gian, việc này đối với nhiều thành phần có thể tăng lên. Bạn muốn áp dụng một hồ sơ để chắc chắn.

Vì vậy, để tóm tắt: nói chung, mặc định làm cho mọi thứ trở nên cục bộ nhất có thể, nhưng trong trường hợp này có thể hợp lý để tạo rbthành viên để bạn có thể thực hiện tra cứu một lần Awakevà tránh phải thực hiện mỗi FixedUpdatecuộc gọi.

Câu trả lời của Josh Petrie là rất tốt - đây là một quan điểm bổ sung.

Khi bạn làm việc với mã mà bạn hiểu miền khá tốt, bạn có thể phạm vi biến đến nơi chúng có ý nghĩa.

Ví dụ, nếu tôi có một Personlớp với một waveGoodbyephương thức, có thể lớp của tôi không có handđối tượng trước đó và vì vậy tôi có thể khai báo nó cục bộ waveGoodbye. Bây giờ ở đây rõ ràng là một người có một bàn tay để bạn có thể tự nhiên tuyên bố nó là một thành viên Personmà không nghĩ về nó, nhưng vấn đề tương tự được áp dụng.

Nếu bạn tuyên bố hand cục bộ thì sau này bạn có thể thêm một karateChopphương thức cũng cần một bàn tay. Đây là khi khai báo các biến cục bộ có thể trở nên có vấn đề - bởi vì các nhà phát triển cơ sở thường quay lại sao chép / dán khai báo từ đó waveGoodbyevà bây giờ bạn có cùng một khái niệm nằm ở hai điểm. Bất kỳ thay đổi nào handsau đó cần phải được sửa đổi ở cả hai nơi và do đó bắt đầu một đồi kiến .

Vì vậy tất cả trong tất cả,

1. Nếu bạn tự tin vào vị trí khai báo của mình, hãy đưa nó vào vị trí hợp lý.

2. Nếu bạn không tự tin, thì hãy bắt đầu cục bộ và đảm bảo cấu trúc lại khi bạn nhận được một lần sử dụng lại mã.
   
   

Chỉnh sửa: Ồ và đừng phạm sai lầm tương tự tôi đã dành quá nhiều thời gian để tìm ra nơi để khai báo các tuyên bố của bạn. Thật khó để hiểu cấu trúc dữ liệu của bạn ở phía trước và khi bạn viết mã của mình, cấu trúc có một cách để lộ chính nó.