Nếu bạn luôn luôn chuyển dữ liệu tối thiểu cần thiết vào một hàm trong các trường hợp như thế này

Giả sử tôi có một chức năng IsAdminkiểm tra xem người dùng có phải là quản trị viên hay không. Chúng ta cũng nói rằng việc kiểm tra quản trị viên được thực hiện bằng cách khớp id người dùng, tên và mật khẩu với một số quy tắc (không quan trọng).

Trong đầu tôi có hai chữ ký chức năng có thể cho việc này:

public bool IsAdmin(User user);
public bool IsAdmin(int id, string name, string password);

Tôi thường đi loại chữ ký thứ hai, nghĩ rằng:

• Chữ ký hàm cung cấp cho người đọc nhiều thông tin hơn
• Logic chứa bên trong hàm không cần phải biết về Userlớp
• Nó thường dẫn đến ít mã hơn bên trong hàm

Tuy nhiên đôi khi tôi nghi ngờ cách tiếp cận này, và cũng nhận ra rằng đến một lúc nào đó nó sẽ trở nên khó sử dụng. Ví dụ, nếu một hàm sẽ ánh xạ giữa mười trường đối tượng khác nhau thành một bool kết quả thì rõ ràng tôi sẽ gửi trong toàn bộ đối tượng. Nhưng ngoài một ví dụ rõ ràng như thế, tôi không thể thấy lý do để vượt qua trong đối tượng thực tế.

Tôi sẽ đánh giá cao bất kỳ đối số cho một trong hai phong cách, cũng như bất kỳ quan sát chung nào bạn có thể cung cấp.

Tôi lập trình theo cả hai phong cách hướng đối tượng và chức năng, vì vậy câu hỏi nên được xem là liên quan đến bất kỳ và tất cả các thành ngữ.

Cá nhân tôi thích phương pháp đầu tiên của IsAdmin(User user)

Việc sử dụng dễ dàng hơn nhiều và nếu tiêu chí của bạn cho IsAdmin thay đổi vào một ngày sau đó (có thể dựa trên vai trò hoặc isActive), bạn không cần phải viết lại chữ ký phương thức của mình ở mọi nơi.

Có lẽ nó cũng an toàn hơn khi bạn không quảng cáo thuộc tính nào xác định xem người dùng có phải là Quản trị viên hay không, hoặc chuyển xung quanh thuộc tính mật khẩu ở mọi nơi. Và syrion làm cho một điểm tốt là những gì xảy ra khi bạn idkhông khớp với name/ password?

Độ dài của mã bên trong một hàm không thực sự quan trọng khi cung cấp phương thức thực hiện công việc của nó và tôi muốn có mã ứng dụng ngắn hơn và đơn giản hơn mã phương thức của trình trợ giúp.

Chữ ký đầu tiên là vượt trội vì nó cho phép đóng gói logic liên quan đến người dùng trong Userchính đối tượng. Sẽ không có lợi khi có logic cho việc xây dựng bộ "id, name, password" rải rác về cơ sở mã của bạn. Hơn nữa, nó làm phức tạp isAdminchức năng: điều gì xảy ra nếu ai đó đi qua idkhông khớp với name, chẳng hạn? Điều gì xảy ra nếu bạn muốn kiểm tra xem một Người dùng cụ thể có phải là quản trị viên từ ngữ cảnh mà bạn không nên biết mật khẩu của họ không?

Hơn nữa, như một lưu ý về điểm thứ ba của bạn ủng hộ phong cách với các đối số bổ sung; nó có thể dẫn đến "ít mã bên trong hàm", nhưng logic đó đi đâu? Nó không thể biến mất! Thay vào đó, nó lan rộng ra khắp mọi nơi nơi hàm được gọi. Để lưu năm dòng mã ở một nơi, bạn đã trả năm dòng cho mỗi lần sử dụng hàm!

Đầu tiên, nhưng không (chỉ) cho những lý do người khác đã đưa ra.

public bool IsAdmin(User user);

Đây là loại an toàn. Đặc biệt vì Người dùng là loại bạn tự xác định, có rất ít hoặc không có cơ hội chuyển đổi hoặc chuyển đổi đối số. Nó rõ ràng hoạt động trên Người dùng và không phải là một số hàm chung chấp nhận bất kỳ chuỗi int và hai chuỗi nào. Đây là một phần quan trọng trong việc sử dụng ngôn ngữ an toàn kiểu như Java hoặc C # mà mã của bạn trông giống như vậy. Nếu bạn đang hỏi về một ngôn ngữ cụ thể, bạn có thể muốn thêm một thẻ cho ngôn ngữ đó vào câu hỏi của bạn.

public bool IsAdmin(int id, string name, string password);

Ở đây, bất kỳ int và hai chuỗi sẽ làm. Điều gì ngăn cản bạn hoán đổi tên và mật khẩu? Thứ hai là sử dụng nhiều công việc hơn và cho phép nhiều cơ hội hơn cho lỗi.

Có lẽ, cả hai hàm đều yêu cầu user.getId (), user.getName () và user.getPassword () được gọi, bên trong hàm (trong trường hợp đầu tiên) hoặc trước khi gọi hàm (trong giây) số lượng khớp nối là một trong hai cách. Trên thực tế, vì hàm này chỉ hợp lệ trên Người dùng, nên trong Java tôi sẽ loại bỏ tất cả các đối số và biến phương thức này thành một phương thức cá thể trên các đối tượng Người dùng:

user.isAdmin();

Vì chức năng này đã được liên kết chặt chẽ với Người dùng, nên có ý nghĩa làm cho nó trở thành một phần của người dùng.

PS Tôi chắc chắn đây chỉ là một ví dụ, nhưng có vẻ như bạn đang lưu trữ mật khẩu. Thay vào đó, bạn chỉ nên lưu trữ một mật khẩu băm mật khẩu an toàn. Trong quá trình đăng nhập, mật khẩu được cung cấp phải được băm theo cùng một cách và so sánh với băm được lưu trữ. Gửi mật khẩu xung quanh trong văn bản đơn giản nên tránh. Nếu bạn vi phạm quy tắc này và isAdmin (int Str Str) đã đăng nhập tên người dùng, thì nếu bạn hoán đổi tên và mật khẩu trong mã của mình, mật khẩu có thể được ghi lại thay vào đó tạo ra vấn đề bảo mật (không ghi mật khẩu vào nhật ký ) và là một đối số khác có lợi cho việc truyền một đối tượng thay vì các phần thành phần của nó (hoặc sử dụng một phương thức lớp).

Nếu ngôn ngữ bạn chọn không vượt qua các cấu trúc theo giá trị, thì (User user)biến thể có vẻ tốt hơn. Điều gì sẽ xảy ra nếu một ngày nào đó bạn quyết định loại bỏ tên người dùng và chỉ cần sử dụng ID / mật khẩu để xác định người dùng?

Ngoài ra, cách tiếp cận này chắc chắn dẫn đến các cuộc gọi phương thức dài và quá mức, hoặc không nhất quán. Là vượt qua 3 đối số được không? 5 thì sao? Hay 6? Tại sao lại nghĩ về điều đó, nếu vượt qua một đối tượng là rẻ về tài nguyên (thậm chí rẻ hơn so với việc truyền 3 đối số, có lẽ)?

Và tôi (loại) không đồng ý rằng cách tiếp cận thứ hai cung cấp cho người đọc nhiều thông tin hơn - theo trực giác, cuộc gọi phương thức đang hỏi "liệu người dùng có quyền quản trị viên" hay không, "liệu tổ hợp id / name / mật khẩu đã cho có quyền quản trị hay không".

Vì vậy, trừ khi vượt qua Userđối tượng sẽ dẫn đến việc sao chép một cấu trúc lớn, cách tiếp cận đầu tiên là sạch sẽ và hợp lý hơn với tôi.

Tôi có thể sẽ có cả hai. Cái đầu tiên là một API bên ngoài, với một số hy vọng về sự ổn định trong thời gian. Cái thứ hai như là một triển khai riêng được gọi bởi API bên ngoài.

Nếu sau này tôi phải thay đổi quy tắc kiểm tra, tôi sẽ chỉ viết một hàm riêng mới với một chữ ký mới được gọi bởi quy tắc bên ngoài.

Điều này có lợi thế của sự dễ dàng để thay đổi thực hiện bên trong. Ngoài ra, thực sự thông thường là đôi khi bạn có thể cần cả hai chức năng có sẵn cùng một lúc và gọi cái này hoặc cái kia tùy thuộc vào một số thay đổi bối cảnh bên ngoài (ví dụ: bạn có thể cùng tồn tại Người dùng cũ và Người dùng mới với các trường khác nhau).

Về tiêu đề của câu hỏi, theo một cách nào đó trong cả hai trường hợp bạn đang cung cấp thông tin cần thiết tối thiểu. Người dùng dường như là Cấu trúc dữ liệu liên quan đến ứng dụng nhỏ nhất chứa thông tin. Ba trường id, mật khẩu và tên dường như là các dữ liệu triển khai nhỏ nhất thực sự cần thiết, nhưng chúng không thực sự là đối tượng cấp Ứng dụng.

Nói cách khác, nếu bạn đang xử lý cơ sở dữ liệu, Người dùng sẽ là một bản ghi, trong khi id, mật khẩu và đăng nhập sẽ là các trường trong bản ghi đó.

Có một điểm tiêu cực để gửi các lớp (các kiểu tham chiếu) đến các phương thức, và đó là, Lỗ hổng chuyển nhượng hàng loạt . Hãy tưởng tượng rằng thay vì IsAdmin(User user)phương pháp, tôi có UpdateUser(User user)phương pháp.

Nếu Userlớp có thuộc tính Boolean được gọi IsAdminvà nếu tôi không kiểm tra nó trong khi thực hiện phương thức của mình, thì tôi dễ bị gán khối lượng. GitHub đã bị tấn công bởi chính chữ ký này vào năm 2012.

Tôi sẽ đi theo cách tiếp cận này:

public bool IsAdmin(this IUser user) { /* ... */ }

public class User: IUser { /* ... */ }

public interface IUser
{
    string Username {get;}
    string Password {get;}
    IID Id {get;}
}

• Sử dụng loại giao diện làm tham số cho chức năng này cho phép bạn truyền vào các đối tượng Người dùng, để xác định các đối tượng Người dùng giả để kiểm tra và giúp bạn linh hoạt hơn trong cả việc sử dụng và bảo trì chức năng này.

• Tôi cũng đã thêm từ khóa thisđể làm cho hàm trở thành một phương thức mở rộng của tất cả các lớp IUser; bằng cách này, bạn có thể viết mã theo cách thân thiện hơn với OO và sử dụng chức năng này trong các truy vấn Linq. Đơn giản hơn vẫn là định nghĩa hàm này trong IUser và User, nhưng tôi cho rằng có một số lý do tại sao bạn quyết định đặt phương thức này bên ngoài lớp đó?

• Tôi sử dụng giao diện tùy chỉnh IIDthay vì intđiều này cho phép bạn xác định lại các thuộc tính của ID của bạn; ví dụ như bạn nên cần thay đổi từ inttới long, Guidhoặc cái gì khác. Điều đó có thể quá mức cần thiết, nhưng luôn luôn tốt để cố gắng làm cho mọi thứ linh hoạt để bạn không bị khóa trong các quyết định sớm.

• Lưu ý: Đối tượng IUser của bạn có thể ở một không gian tên khác và / hoặc tập hợp thành lớp Người dùng, do đó bạn có tùy chọn giữ mã Người dùng tách biệt hoàn toàn với mã IsAdmin của mình, với chúng chỉ chia sẻ một thư viện được tham chiếu. Chính xác những gì bạn làm có một cuộc gọi cho cách bạn nghi ngờ những vật phẩm này sẽ được sử dụng.

Tuyên bố miễn trừ trách nhiệm:

Đối với câu trả lời của tôi, tôi sẽ tập trung vào vấn đề phong cách và quên đi ID, mật khẩu đăng nhập và mật khẩu đơn giản là một bộ thông số tốt để sử dụng, từ quan điểm bảo mật. Bạn sẽ có thể ngoại suy câu trả lời của tôi cho bất kỳ bộ dữ liệu cơ bản nào bạn đang sử dụng để tìm hiểu về các đặc quyền của người dùng ...

Tôi cũng coi user.isAdmin()là tương đương với IsAdmin(User user). Đó là một sự lựa chọn cho bạn để thực hiện.

Đáp lại:

Đề xuất của tôi là chỉ cho người dùng:

public bool IsAdmin(User user);

Hoặc sử dụng cả hai, dọc theo dòng:

public bool IsAdmin(User user); // calls the private method below
private bool IsAdmin(int id, string name, string password);

Lý do cho phương pháp công cộng:

Khi viết các phương thức công khai, thường là một ý tưởng tốt để suy nghĩ về cách chúng sẽ được sử dụng.

Trong trường hợp cụ thể này, lý do tại sao bạn thường gọi phương thức này là để tìm hiểu xem một người dùng nào đó có phải là quản trị viên hay không. Đó là một phương pháp bạn cần. Bạn thực sự không muốn mỗi người gọi phải chọn đúng tham số để gửi qua (và rủi ro sai lầm do sao chép mã).

Lý do cho phương pháp riêng tư:

Phương thức riêng tư chỉ nhận được tập hợp tối thiểu các tham số cần thiết đôi khi có thể là một điều tốt. Đôi khi không quá nhiều.

Một trong những điều tốt khi chia tách các phương thức này là bạn có thể gọi phiên bản riêng từ một số phương thức công khai trong cùng một lớp. Ví dụ: nếu bạn muốn (vì bất kỳ lý do gì) có logic hơi khác nhau Localuservà RemoteUser(có thể có cài đặt bật / tắt quản trị viên từ xa?):

public bool IsAdmin(Localuser user); // Just call private method
public bool IsAdmin(RemoteUser user); // Check if setting is on, then call private method
private bool IsAdmin(int id, string name, string password);

Ngoài ra, nếu vì bất kỳ lý do gì bạn cần đặt phương thức riêng tư ... bạn có thể. Nó dễ dàng như chỉ cần thay đổi privatethành public. Nó có vẻ không phải là một lợi thế lớn cho trường hợp này, nhưng đôi khi nó thực sự là.

Ngoài ra, khi thử nghiệm đơn vị, bạn sẽ có thể thực hiện nhiều thử nghiệm nguyên tử hơn nhiều. Thật tuyệt khi không phải tạo một đối tượng người dùng đầy đủ để chạy thử nghiệm trên phương thức này. Và nếu bạn muốn bảo hiểm đầy đủ, bạn có thể kiểm tra cả hai cuộc gọi.

public bool IsAdmin(int id, string name, string password);

là xấu cho những lý do được liệt kê. Điều đó không có ý nghĩa

public bool IsAdmin(User user);

là tự động tốt. Đặc biệt nếu tài khoản là một đối tượng có phương pháp như: getOrders(), getFriends(), getAdresses(), ...

Bạn có thể xem xét tái cấu trúc tên miền với loại UserCredentials chỉ chứa id, tên, mật khẩu và chuyển nó đến IsAdmin thay vì tất cả dữ liệu Người dùng không cần thiết.