Question

我的设计中也可能存在一些问题。这是我的问题：

我首先有AbstractCustomAuthHandler；

获取IUser（获取具有实现逻辑的用户）
而不是调用IUser的IRole对象的函数（通过实现逻辑获取角色）

因此，在设计之初；

每个IUser实现都有一些IRole逻辑
将它们分开是因为它们是单独的微服务中单独的rest调用
但我与IUser关联的对象具有IRole关系

但是现在有一些实现，某些IUser的实现不应该具有IRole对象。因此，到目前为止，我为此实现返回null，但我不喜欢它。我曾考虑过拆分界面，但也找不到AbstractCustomAuthHandler满足的解决方案。这是一个图和代码：

这是AbstractCustomAuthHandler的一部分

IUser userAuth= this.getUserAuth();
final Response userResponse= userAuth.findUser();
// ...
Map<String, Object> attributes= userAuth.getMappedAttributes();
// ...
IRole roleAuth= userAuth.getRoleAuth();
if (roleAuth!= null)
{
    final Response rolesResponse = roleAuth.findRolesBy();
}
// ....

这是AuthMethodWithoutRole，我在返回null时遇到问题

public class AuthMethodWithoutRole implements IUser
{
    @Override public Response findUserBy( )
    {
        // some logic
    }

    @Override public IRole getRoleAuth( )
    {
        return null;
    }
}

这是IUser界面

public interface IUser extends IAuth
{
    Response findUserBy();

    IRole getRoleAuth();
}

这是IRole界面

public interface IRole
{
    Response findRolesBy( );
}

Answer 1

为什么不只创建一个实现IRole的NullRole类？因此，您不需要AuthMethodWithoutRole。您可以只使用默认的AuthMethod处理“ NullRole”。

Answer 2

如果您真的想从AbstractCustomAuthHandler中删除角色检查，则应重新考虑您的设计。您可以在IUser类/子类中移动使用该角色的逻辑。
这样，每个IUser实现将在需要时使用它。
这种方法听起来像是DDD方法。使对象根据其性质/定义进行协作，并且不要让人造对象执行整个逻辑（AbstractCustomAuthHandler）。

此逻辑：

IUser userAuth= this.getUserAuth();
final Response userResponse= userAuth.findUser();
// ...
Map<String, Object> attributes= userAuth.getMappedAttributes();
// ...
IRole roleAuth= userAuth.getRoleAuth();
if (roleAuth!= null)
{
    final Response rolesResponse = roleAuth.findRolesBy();
}

将在IUser中完成：

IUser userAuth= this.getUserAuth();
Response response = userAuth.computeResponse(...);

或者：

ResponsePart responsePart = userAuth.computeSomePartOfTheResponse(...);
// and use responsePart  to complete the logic.

当然，IUser子类可以依靠在超类或接口中定义的某些基本方法来执行公共逻辑。

如果您不想更改方法，就是要继续检索IUser对象的角色信息，以便让另一个类（AbstractCustomAuthHandler）使用它，则需要统一操作操纵它们的类的IUser。
因此，即使对于没有这些角色的子类，也需要提供具有空或空角色的实现。
如果您采用这种方法，我认为这不是设计问题。作为改进，您可以考虑：

在返回null的接口中定义默认实现。
或将返回类型更改为Optional<Role>，并在返回empty可选接口的接口中定义默认实现。

这将给出：

public interface IUser extends IAuth
{
    Response findUserBy();

    default Optional<IRole> getRoleAuth(){return Optional.empty()}
}

现在仅在需要时才覆盖该方法。

如何避免接口方法的空实现

2 个答案: