java - 在Java中将消费者用作设置者，将供应商用作获取者是不好的做法吗？

Question

我有一个Java类，它具有一些我不想为其创建setter和getter的私有变量。我希望这些变量仍然无法访问。但是有一类需要访问这些变量。此类是其他包装中的访问者（我希望将其保存在其他包装中）。允许此类为访客提供设置者和获取者的消费者和供应商，以使访客可以读取和修改这些变量，是不明智的做法？如果是，请说明原因。

例：

A.java

public class A {
    private int x;
    private Consumer<Integer> setter;
    private Supplier<Integer> getter;
    public A(int v) {
        x = v;
        setter = new Consumer<Integer>() {
            @Override
            public void accept(Integer t) {
                x = t;
            }
        };

        getter = new Supplier<Integer>() {
            @Override
            public Integer get() {
                return x;
            }
        };
    }

    public void accept(SomeVisitor visitor) {
        visitor.setSetter(setter);
        visitor.setGetter(getter);
        visitor.visit(this);
    }
}

SomeVisitor.java

public class SomeVisitor extends ParentVisitor {
    private Consumer<Integer> setter;
    private Supplier<Integer> getter;

    public SomeVisitor() {
        setter = null;
        getter = null;
    }

    public void setSetter(Consumer<Integer> setter) {
        this.setter = setter;
    }

    public void setGetter(Supplier<Integer> getter) {
        this.getter = getter;
    }

    @Override
    public void visit(A a) {
        // Code that will, possibly, read and modify A.x
        ...
    }
}

这样，变量A.x对于除访问者之外的所有其他类均不可访问。



更多细节：

我有一些可以利用访客的课程。这些类具有彼此依赖的私有变量。如果这些变量具有设置器，则在用户更改这些变量时可能会出现不一致之处，这应相互依赖，而又不尊重这些依赖关系。

其中一些变量会带有吸气剂，而其他变量则不会，因为它们仅在内部使用，不应在其他位置访问。访问者是例外并且应获得对这些变量的读/写访问权限的原因是，访问者要实现的功能旨在在这些类的方法中实现。但我认为如果我使用访客，那会更干净。这些功能确实需要对这些变量的读/写访问权限。

这种方法的目的是模仿C ++中的好友功能。我可以将访问者与这些类放在同一个包中（如果我没有找到一个很好的解决方案，我会这样做）；但我认为，如果同时有访问者，则该程序包看起来会很凌乱（并且会有很多访问者）。



访客将实现的功能也将与这些类之间的关系有关。

Answer 1

我试图将其压缩为注释，因为从技术上讲它不能回答有关这是否是“ Bad Practice™”的问题，但是该术语难以定义，因此，几乎不可能给出答案。 。

最终，这似乎归结为如何Make java methods visible to only specific classes的问题（还有类似的问题）。获取者/设置者仅应提供给一个特定的班级-即访客。

您在问题中使用了非常通用的名称和描述，因此很难说这是否有意义。

但是需要考虑以下几点：


有人可能会辩称，这通常会破坏封装。每个人都可以编写这样的访问者并获得对get / set方法的访问权限。即使这是一个荒谬的hack：如果人们想要实现一个目标，他们会做这样的事情！ （在下面的附录1中作了简要说明）
更笼统地说，有人会争辩：为什么只允许访问者访问setter / getter，而不允许其他类访问？
将getter / setter方法隐藏在Supplier / Consumer实例后面的一个令人信服的原因可能与可见性和类的特殊性有关（在附录2中有详细说明）。但是由于访问者始终具有对被访问类的依赖关系，因此这在这里不直接适用。
有人可能会说这种方法更容易出错。想象一下，setter或getter是null或它们属于不同实例的情况。调试它可能非常困难。
从评论和其他答案中可以看出：有人可能会认为所提出的方法只会使事情变得复杂，而会“掩盖”这些实际上是setter / getter方法的事实。我不会说太多，通常已经有了setter / getter方法已经是一个问题。但是，您现在的方法是在访客中安排二传手和二传手。这以难以缠绕头部的方式扩展了访问者的状态空间。


总结一下：

尽管有上述论点，但我不会将其称为“不良做法”-也因为它根本不是一种普遍做法，而是一种非常具体的解决方法。这样做可能有原因和理由，但只要您不提供更多详细信息，就很难说这在您的特定情况下是否正确，或者是否存在更优雅的解决方案。



更新资料

有关更多详细信息：您说过


  用户更改这些变量可能会导致不一致


类通常负责以确保其始终“一致”的方式管理其自己的状态空间。从某种意义上讲，这是首先具有类和封装的主要目的。为什么有时将getters + setters视为“邪恶”的原因之一不仅是可变性（通常应将其最小化）。也是因为人们倾向于使用getters + setters公开类的属性，而不考虑适当的抽象。

具体来说：如果您有两个相互依赖的变量x和y，则该类应该根本没有方法

public void setX(int x) { ... }
public void setY(int y) { ... }

取而代之的是，（最好，大概）应该有一种方法

public void setState(int x, int y) { 
    if (inconsistent(x,y)) throw new IllegalArgumentException("...");
    ...
}

这样可以确保状态始终保持一致。



我认为没有一种干净地模拟C ++ friend函数的方法。您建议的 Consumer / Supplier方法可能是合理的解决方法。可以通过稍微不同的方法来避免可能引起的某些（不是全部）问题：

包 org.example包含您的主类

class A {
    private int v;
    private int w;

    public void accept(SomeVisitor visitor) {
        // See below...
    }        
}

包 org.example也包含一个接口。此接口使用getter + setter方法公开 A的内部状态：

public interface InnerA {
    void setV(int v);
    int getV();
    void setW(int w);
    int getW();
}

但是请注意，主类未实现此接口！

现在，访问者可以居住在另一个包中，例如 org.example.visitors。访问者可以使用专用方法访问 InnerA对象：

public class SomeVisitor extends ParentVisitor {

    @Override
    public void visit(A a) {
        ...
    }

    @Override
    public void visit(InnerA a) {
        // Code that will, possibly, read and modify A.x
        ...
    }

然后，在 accept中实现 A方法可以执行以下操作：

    public void accept(SomeVisitor visitor) {

        visitor.accept(this);

        visitor.accept(new InnerA() {
            @Override 
            public void setX(int theX) {
                x = theX;
            }
            @Override 
            public int getX() {
                return x;
            }
            // Same for y....
        });
    }        

因此，该类将专门将新创建的 InnerA实例传递给访问者。该 InnerA仅在访问时存在，并且仅用于修改创建它的特定实例。

一种中间解决方案可能是不定义此接口，而引入诸如

@Override
public void visit(Consumer<Integer> setter, Supplier<Integer> getter) {
    ...
}

要么

@Override
public void visit(A a, Consumer<Integer> setter, Supplier<Integer> getter) {
    ...
}

人们将不得不根据实际应用情况对此进行进一步分析。

但是再说一遍：这些方法都不能解决一般问题：当您提供对包裹外部人员的访问时，您将提供对包裹外部所有人的访问...。



附录1：一个为 A的类，但带有公共的getter / setter方法。再见，封装：

class AccessibleA extends A {
    private Consumer<Integer> setter;
    ...
    AccessibleA() {
        EvilVisitor e = new EvilVisitor();
        e.accept(this);
    } 
    void setSetter(Consumer<Integer> setter) { this.setter = setter; }
    ...
    // Here's our public setter now:
    void setValue(int i) { setter.accept(i); }
}

class EvilVisitor {
    private AccessibleA accessibleA;
    ...
    public void setSetter(Consumer<Integer> setter) {
        accessibleA.setSetter(setter);
    }
    ...
}

附录二：

想象一下你有这样的课程

class Manipulator {
    private A a;
    Manipulator(A a) {
        this.a = a;
    }
    void manipulate() {
        int value = a.getValue();
        a.setValue(value + 42);
    }
}

现在，假设您想删除此类对 A类的编译时依赖性。然后，可以将其更改为在构造函数中不接受 A的实例，而是接受 Supplier / Consumer对。但是对于访客而言，这没有任何意义。