dan*_*dan 4 authentication methods naming class naming-conventions
我有一个名为OAuthLogin支持通过OAuth登录用户的类.该网站还支持"传统"登录过程,没有OAuth.这两个流程共享大量代码,我需要在其中区分它们.
我有一个静态方法OAuthLogin::isThis(),返回一个布尔值,无论当前登录流是否为OAuth(通过检查会话变量和URL参数).
我不喜欢这个方法的名称,但我想不出更好的方法 - 我想这是一个常见的概念,因此应该有某种模式.
我不喜欢OAuthLogin::isThisOAuthLogin()因为多余.
我想避免Login::isThisOAuth因为我想保留OAuthLogin课堂上的所有代码.
我应该去OAuthLogin::is()吗？有什么比这更好的？
谢谢.
Ben*_*ith 22
您的OAuthLogin类应该只有一个责任,那就是让用户能够使用OAuth登录; 这个类应该不了解"传统"登录过程.看到此类名的人(例如StackOverflow用户!)将假定此类仅负责使用OAuth的登录功能.
由于您的两个登录进程共享大量代码,因此您真的应该重构代码,以便拥有包含公共代码的基类,然后为OAuth和Traditional登录提供单独的类,这些类都将从基类继承.当您的代码执行时,您应该实例化适合该用户会话的登录类.
此外,由于您的OAuthLogin类是静态的,那么它将如何处理同时登录的许多用户？因此,重构它的另一个好理由是它不是静态的.
如果你绝对无法重构,那么在没有看到你的代码的情况下,听起来好像OAuthLogin类确实是一个中介,即它封装了一组类如何交互(在这种情况下是你的登录类).因此,您可以将其命名为"LoginMediator",而不是使用名称"OAuthLogin".然后你可以拥有这些属性:
LoginMediator.isOauthLogin
和
LoginMediator.isTraditionalLogin
区分调解器用于该特定会话的不同类型的登录.虽然不是使用"繁体"这个词,而是将其替换为您实际使用的其他身份验证机制(例如HTTP基本身份验证,HTTP摘要身份验证,HTTPS客户端身份验证等)
请注意我如何选择这些属性的意图揭示名称.如果一个陌生人要阅读你的代码(例如我!),他们就很难从方法签名中理解"is()"和"isThis()"的目的.
但是,从长远来看,我确实建议您重构代码,以便拥有具有离散职责的类,因为您会发现命名方法将更容易.