Tại sao nên dùng [SerializeField] thay vì biến public?

Cách đây độ hơn một năm, mình có viết một bài giải thích về thẻ [ SerializeField ] trong Unity C# hoạt động như thế nào. Trong bài đó, mình có nói rằng các trường dữ liệu public có thể là những mối nguy tiềm ẩn trong chương trình của bạn. Với các lập trình viên có kinh nghiệm, việc này khá là hiển nhiên, như kiểu trái đất quay quanh mặt trời vậy.

Có thể bạn muốn xem:

Tuy nhiên, với các bạn newbie hoặc các bạn tự học lập trình tại nhà, nguy cơ đến từ các biến public có vẻ chẳng đáng lo ngại lắm. Trong bài viết này mình sẽ giải thích kỹ hơn quan điểm của mình, và bạn sẽ thấy vì sao nhiều lập trình viên khác cũng có chung quan điểm đó.ư

“Em thấy hai cách chả khác quái gì nhau cả.”

Nhìn qua thì việc dùng một biến public và một biến private + [SerializeField] có vẻ không khác gì nhau. Cả hai cách đều cho phép mọi người trong project của bạn chỉnh sửa trực tiếp giá trị của biến trong Unity Inspector. Nghĩa là dù bạn làm như thế này:

… hay như thế này:

… thì ai cũng có thể mở script Character ra và sửa giá trị HP của nhân vật đó, ví dụ như từ 5 lên 10. Sự khác biệt có vẻ không rõ ràng lắm?

Giờ thì hãy nhìn theo hướng của lập trình viên. Tưởng tượng một ngày thằng Dũng ngồi cạnh bạn sẽ dùng đám code trên cho tính năng mà nó đang xử lý. Nếu bạn dùng biến public, thì thằng Dũng có thể truy cập tới biến đó từ bất cứ đâu trong chương trình, và đoạn code dưới đây hoàn toàn hợp lệ:

Nhưng nếu bạn chọn cách dùng biến private, Dũng không thể dùng biến đó được nữa. Sự khác biệt là đây.

Hàng công cộng tức là công chúng xài sao cũng được

Sự khác biệt này có vẻ không đáng kể – Dũng có thể dùng biến HP đó hoặc không, chấm hết. Vậy tại sao lại phải làm to chuyện lên làm gì? Tại sao bạn cần giấu các biến dữ liệu của bạn mà không phải phô ra?

Hãy xét trường hợp bạn dùng biến public. Thằng Dũng chỉ cần lấy giá trị HP hiện tại để làm thanh máu của nhân vật, ví dụ thế. Ừ thì không phải cái gì to tát lắm, nó chỉ đọc thôi mà, chẳng ảnh hưởng gì tới bạn. Nhưng đến khi Cường nhảy vào project và nó phải lập trình một vật phẩm giúp x2 máu của nhân vật. Vì biến HP của bạn là public, nên thằng Cường chỉ cần nhặt nó lên và xài như bình thường, tự nhiên như ruồi vậy.

Cách làm này sẽ dẫn tới những vấn đề đau đầu rất nhanh. Với trường hợp đoạn code ở trên, chẳng có giá trị giới hạn nào cho máu của nhân vật cả, nó có thể tăng, tăng nữa, tăng mãi. Rõ ràng là không ổn chút nào. Bạn cần phải thêm một giá trị nữa vào class Character của bạn để giới hạn giá trị lớn nhất của giá trị HP. Lấy ví dụ, nhân vật đang có máu là 80/100 và nó nhặt được vật phẩm của Cường. Nếu không có giới hạn trên, máu của nhân vật sẽ là 160/100 (wtf?) thay vì giá trị đúng là 100/100.

Để đạt được điều này, Cường phải sửa phần code của nó sau khi bạn đã thêm giá trị max HP vào code của bạn – thật sự là phiền. Tại sao không phải đơn giản là nó chỉ việc tập trung vào vật phẩm hồi máu của nó, còn bạn xử lý những chi tiết lặt vặt ở trên. Dù gì bạn cũng là người chịu trách nhiệm cho class Character cơ mà?

Trường hợp của Cường là một ví dụ cho việc sử dụng biến public làm cho code của bạn mong manh dễ vỡ thế nào. Các yêu cầu phát triển của mọi phần mềm, bao gồm cả game, không bao giờ là bất biến trong suốt quá trình phát triển. Thậm chí, các yêu cầu này thay đổi nhanh như người yêu cũ trở mặt vậy. Mặc dù các biến public có thể được truy cập dễ dàng từ mọi nơi, nhưng nó đồng nghĩa với việc code của bạn khó có thể thích nghi với sự thay đổi từ yêu cầu. Giờ chúng ta sẽ thử thay đổi phương án tiếp cận, bằng cách đổi sang sử dụng biến private.

Video Trọn bộ kinh doanh trên Facebook 2019

Đẹp khoe xấu che

Chúng ta có hai sự thay đổi chính với hai giá trị về máu của nhân vật. Thứ nhất, cả hai giá trị bây giờ đều là các biến private, tức là nó chỉ có thể được đọc hoặc ghi trong phạm vi class Character của bạn. Nói cách khác, bạn là người toàn quyết quyết định rằng hai giá trị này sẽ được xử lý ra sao. Thứ hai, bây giờ nếu mọi người mở script Character của bạn ra trong Unity, họ chỉ có thể thay đổi giá trị max HP. Giá trị HP hiện tại hoàn toàn không thể bị chỉnh sửa tuỳ tiện được. Sự thay đổi này là hợp lý, bởi nếu một ai đó sửa giá trị HP hiện tại của nhân vật trong Play mode, có thể sẽ có lỗi logic xảy ra.

Vấn đề của Dũng, người cần đọc giá trị máu của nhân vật, được giải quyết bằng một hàm getter hoặc một property giúp đọc giá trị của biến healthPoint. Nếu bạn đến từ background về C++ như mình thì bạn sẽ thấy hàm getter khá quen thuộc. Thực ra trong công việc hàng ngày, mình thích cách sử dụng hàm getter hơn là property, bởi mục đích của nó rõ ràng hơn. Thêm nữa là thao tác tìm kiếm các chỗ sử dụng hàm getter dễ hơn nhiều so với property, bởi bạn không cần phải lọc ra các đoạn mà property dùng để sửa giá trị của biến. Đây hoàn toàn là vấn đề sở thích cá nhân thôi, bạn cứ xài cách nào khiến bạn cảm thấy thoải mái là được.

Với việc để các biến trong class của bạn là private, nếu Dũng hoặc Cường trực tiếp truy cập tới các biến này trong code của chúng nó, chúng nó sẽ bị quăng vào mặt một đống lỗi biên dịch. Với mình thì đây là một điều tốt, bởi ý đồ của mình là không nơi nào khác trong code base, ngoại trừ class Character, có thể trực tiếp truy cập tới những biến này. Nếu Dũng hoặc Cường muốn đọc hoặc ghi các giá trị này, chúng nó phải xài những hàm do mình cung cấp và chơi theo luật của mình đề ra. Ví dụ, Cường chỉ cần tập trung vào việc hồi máu của vật phẩm với hàm Heal mà không cần phải lo đến việc máu nhân vật vượt ngưỡng max, bởi mình đã xử lý đoạn đó rồi. Mình không cần phải bảo nó xử lý những trường hợp đó, nó cũng bớt việc phải làm. Một người khoẻ, hai người vui.

Khi các biến được giới hạn trong phạm vi của class, bạn có thể kiểm soát toàn bộ mọi việc liên quan đến các biến này như theo dõi, maintain hoặc update. Lấy ví dụ, nếu bạn nhìn hàm Heal và Damage ở trên, bạn có thể thấy mình hoàn toàn chưa hề xử lý trường hợp tham số đầu vào có giá trị âm. Nếu Cường vô tình (hoặc cố tình) truyền vào một tham số âm, chắc chắn sẽ có biến xảy ra, khi mà vật phẩm được cho là sẽ giúp hồi máu nhân vật thực tế lại làm cho nhân vật ngoắc ngoải đến mức muỗi đốt cái là chết. Vậy đây là một bug. Bạn chỉ cần thêm các đoạn code xử lý cho trường hợp tham số âm, và đời lại phơi phới. Cường và Dũng thậm chí còn chẳng phải sửa gì trong code của chúng nó.

Đặt lại vấn đề, nếu như bạn dùng biến public. Dũng sẽ phải xử lý trường hợp máu của nhân vật tụt xuống giá trị âm. Cường còn thảm hơn. Nó phải xử lý mọi thứ như giá trị âm hay giá trị max một mình. Điều này làm code của nó trông như một mớ rác vậy. Rồi một ngày nó nhận ra là phía game design yêu cầu làm thêm phần trang bị, trong đó có một trang bị giúp tăng max HP của nhân vật. Và nó phải tìm đến từng chỗ một để cập nhật các thay đổi. Sau đó nó rage quit, tìm đến bạn để phang cả cái bàn phím vào đầu bạn, rồi phi ra khỏi cửa và không bao giờ quay lại.

Thế là bạn phải tiếp quản phần việc của Cường. Bạn nhận thấy với những tính năng mới được thêm vào, bạn có thể sẽ ổn hơn nếu bạn chuyển hết phần xử lý máu vào một script khác, gọi là Health Component. Chuyển xong, bạn nhận được 666 lỗi biên dịch, bởi những biến public này được dùng ở khắp mọi nơi xung quanh project. Kể cả khi bạn dọn sạch những lỗi biên dịch này, bạn vẫn cần phải miệt mài test đi test lại các tính năng để đảm bảo rằng chúng vẫn hoạt động đúng như trước khi bạn refactor.

Kết

Phàm trên đời cái gì xảy ra cũng có nguyên nhân của nó. Giấu dữ liệu của bạn vào trong phạm vi class (hay nói văn hoa hơn theo chuẩn OOP là đóng gói – encapsulation) cũng không ngoại lệ. Với tất cả những bất lợi đã trình bày ở trên, mình tin rằng việc sử dụng một biến public chỉ để bạn có thể thay đổi giá trị của nó trong Unity Inspector là không đáng. [SerializeField] đảm nhiệm việc đó ngon lành, và bạn vẫn có thể tận dụng mọi lợi thế của tính đóng gói.

Mình thừa nhận là khi mới viết những dòng code đầu tiên, làm mọi thứ public có vẻ dễ dàng hơn nhiều so với việc viết thêm các đoạn accessor như getter hay setter. Nhưng hãy nhớ rằng, một phút lười nhác bây giờ có thể tốn của bạn hàng giờ làm bù trong tương lai.

Vậy nên đừng dùng các biến public. Nếu phải dùng, bạn tốt nhất là nên có nhiều lý do thật tốt để sử dụng chúng.

Người viết: Giang

Có thể bạn quan tâm:

• 15 đặc điểm của một lập trình viên giỏi
• Tóm tắt con đường trở thành Lập Trình Viên
• Lập trình viên và hội chứng Tự kỷ

Xem thêm việc làm Software Developers hấp dẫn trên TopDev

TopDev via vinaludens