java - 如何从原始列表类中获取给定子类的元素列表？

Question

抱歉，标题似乎很尴尬。真的不知道该如何表达问题。
假设我有一个方法要获取给定Class的所有实例，这是正确的吗？

class Test{
    private List<A> list;
    //... all properly iniatialized on constructor

    //...
    public List<A> getSubListOfGivenClass(Class c){
        //if i can't assign an instance of a Class c to Class A - error, not subclass
        if(!A.class.isAssignableFrom(c))
            throw new IllegalArgumentException();
        List<A> newList = new ArrayList<>();
        for(A aItem : list)
           if(c.isInstance(aItem))
              newList.add(aItem);
        return newList; 
    }
}

还是使用泛型更容易解决此问题？ （我对他们了解不多，这就是为什么我问这个问题，如果我能不打扰泛型的话就这么做）。
再次抱歉，如果我对synthax或其他内容有任何错误，请在此处编写此代码作为示例。
谢谢您的帮助。

Answer 1

因此，从我的评论看来，似乎存在封装问题。当前，您将所有数据存储为通用Tile对象，因为前端仅绘制图块。但是，您希望能够在后端分别处理这些图块（即：能够获取和移动所有怪物），因此需要您创建的方法。

这里的根本问题是，后端永远不应该依赖于前端如何处理数据（反之亦然）。将视图元素与模型元素分离是在软件开发中封装数据的最常见示例。例如，您想要的是一系列可绘制的图块：

public abstract class Tile {
    public void paintTile() {
        ...
    }
}

...

public class PlayerTile extends Tile {
    @Override
    public void paintTile() {
        super.paintTile();
        paintPlayer();
    }

    public void paintPlayer() {
        ...
    }
}

...

public class View {
    private List<Tile> tiles;

    public void paintGame() {
        ...
        for (Tile tile : tiles) {
            tile.paintTile();
        }
        ...
    } 
}

这个实现很好。视图本身只关心游戏实体，将其视为可绘制的图块列表。但是，当您想对 Tile进行更多操作而不是仅仅对其进行绘制时，就存在问题（如您现在所遇到的）。它不再直观地运行；您需要开始研究这个通用列表，显然这并不是我们所要使用的列表。

这是您的后端与视图分离的地方；您的视图不一定像后端一样关心数据。因此，您的模型可能具有以下内容：

public abstract class Entity {
    public void move() {
        ...
    }
}

...

public class PlayerEntity extends Entity {
    @Override
    public void move() {
        // User moves player
    }
}

...

public class MonsterEntity extends Entity {
    @Override
    public void move() {
        // Moved by A* algorithm
    }
}

...

public class Model {
    private PlayerEntity player;
    private List<MonsterEntity> monsters;

    public void gameRound() {
        ...
        player.move();
        ...
        for (MonsterEntity monster : monsters) {
            monster.move();
        }
        ...
    } 
}

这种伪实现具有不相关的缺陷，但我相信它可以说明这一点。在视图一侧，您有一个磁贴列表，该列表适用于该视图。在后端，您以一致的方式存储数据，以供后端使用。两端的实现都是直观且流畅的。

这里缺少的是胶水：什么连接了 View和 Model？有几种方法可以解决此问题，但是为了简单起见，我们只能说视图知道模型，并且可以请求模型中所有游戏实体的位置：

public class Model {
    private PlayerEntity player;
    private List<MonsterEntity> monsters;

    public void gameRound() {
        ...
    }

    public List<Entity> getEntities() {
        List<Entity> entities = Lists.newArrayList();
        entities.add(player);
        entities.addAll(monsters);
        ...
        return entities;
    }
}

...

public class View {
    private Model model;
    private List<Tile> tiles;

    public View(Model model) {
        this.model = model;
    }

    public void paintGame() {
        ...
        List<Entity> entities = model.getEntities();
        tiles = convertToTiles(entities);
        ...
        for (Tile tile : tiles) {
            tile.paintTile();
        }
        ...
    }

    private List<Tile> convertToTiles(List<Entity> entities) {
        ...
    }
}

这将有助于将两者联系起来。但是，需要注意的是，这种实现方式存在一些设计缺陷。由于 Model直接将 Entity对象传递给 View，因此该视图现在链接到后端实现细节，这意味着我们已经增加了应该区别的元素之间的耦合。

那么解决方法是什么？好吧，一个选择是 Mediator对象，该对象在 Model和 View之间运行。此介体对象本质上在 Model和 View之间进行通信，因此它们不需要了解其他任何东西：

public class Model {
    private PlayerEntity player;
    private List<MonsterEntity> monsters;

    public void gameRound() {
        ...
    }

    public List<Entity> getEntities() {
        List<Entity> entities = Lists.newArrayList();
        entities.add(player);
        entities.addAll(monsters);
        ...
        return entities;
    }
}

...

public class View {
    private Presenter presenter;
    private List<Tile> tiles;

    public View(Presenter presenter) {
        this.presenter = presenter;
    }

    public void paintGame() {
        ...
        List<Tile> tiles = presenter.getTiles();
        ...
        for (Tile tile : tiles) {
            tile.paintTile();
        }
        ...
    } 
}

...

public class Presenter {
    private Model model;

    public Presenter(Model model) {
        this.model = model;
    }

    public List<Tile> getTiles() {
        return convertToTiles(model.getEntities());
    } 

    private List<Tile> convertToTiles(List<Entity> entities) {
        ...
    }
}

现在我们有了一个 View，它对 Model一无所知（反之亦然）。 Presenter对象处理它们之间的通信。您可能会说我们已经解决了这个问题。现在， Presenter对象必须同时知道模型对象和视图对象，而不是 View。这在一定程度上是有效的（我将在下面进行介绍）。但是，在 Model和 View之间充当中介者是 Presenter的责任；通过 SRP，这就是它要更改的原因。如果模型或视图更改了其通信方式，则这是 Presenter应当更改的唯一原因之一。如果我们查看不带 Presenter的实现，则 View会有多个更改的原因（模型更改了其通信方式，希望添加新的视图功能），并且将违反SRP。

但是，通过 DIP循环回有关模型对象和视图对象的 Presenter信息，Presenter不应直接依赖于 Entity或 Tile的实现。它应该使用接口在模型和视图之间进行通信。因此，解决方法很简单：使用Entity和Tile为 interface而不是 abstract class（并创建在内部使用但未与其他模块通信的抽象类）。然后，Presenter使用合同接口在模型和视图模块之间进行通信，而 Presenter不需要了解任何有关这两个模块的实现细节的信息。

这个答案相当冗长，但是希望它能传达我试图传达的观点。我还建议您查看 MVP。