Java 面向对象的程序接口绘制设计

我正在写一个绘画程序。我的基本课程是：

  class Workspace { Bitmap b; List<Command> undoList; }

  class Command { void execute(); }

  class ClearScreen extends Command

  class BlurEffect extends Command

  class View { Bitmap screen; }

  class Interface

因此，在界面中，单击“模糊”按钮创建一个新的BlurCommand对象，视图中的“渲染屏幕”方法将开始调用“预览”方法来渲染屏幕，并且“执行”仅在用户想要应用效果时调用

---

这是我能做的最干净的方式吗？我正试图坚持模型-视图-控制器的设计，不希望我的预览行为使事情复杂化。

是的，或者您可以应用模糊，并在取消操作时撤消它，或者在更改参数时撤消并重做它。如果重放整个命令堆栈太耗时，可以在应用模糊之前拍摄快照。

是否有任何单元测试来测试绘制程序的当前功能？我认为真正有助于实现可靠设计的一件事是使用TDD（测试驱动开发/设计）。编写一个模拟“预览”类型操作的测试，然后使该测试通过。一旦您现有的测试和新的预览测试全部通过，然后查看您的应用程序代码是什么样子。

到目前为止，您的设计看起来很棒。以下是我的观点：模糊命令面临的问题是更多此类事情即将发生的迹象，因此应在设计中添加更多此类命令。因此，您可以为Command创建两个子类-

FastCommand

和

SlowCommand

。FastCommand只有

doIt

和

undoIt

方法，只需执行并将其添加到命令堆栈中。SlowCommand应该是一个异步命令，具有两个步骤的执行过程-预览和提交。第一次执行慢命令时，应该执行慢命令，但不要将其添加到命令堆栈中。相反，只需将其作为参考保存在工作区中。当用户实际确认操作时，再次执行它（这次它执行的是真实的操作），然后将其移动到命令堆栈

视图类可能不是必需的

---

谈到慢命令的实际撤消重做机制，您可以根据性能和可用内存来决定最佳方法—创建缓冲区副本，然后丢弃它，或者在同一缓冲区上运行反向算法。如果您发现在应用程序中同时使用了这两种策略，那么可以在命令中使用a。

我现在正在设计。当然，单元测试是一个好主意。关于TDD，你不需要先设计你的代码，而是先编写你的测试，然后让你的代码设计从你的测试期望你的系统如何工作演变而来。我不确定这有什么帮助。有许多实现可以通过，例如模糊预览和模糊应用测试。我正在寻找一个干净的实现，而不仅仅是一个能够通过测试的实现。我不确定您是否理解TDD是如何工作的。从理论上讲，坐下来预先设计一个“干净”的实现可能很好，但如果您尝试实现该设计时由于边缘情况而失败，那么所有这些设计工作都将白费。当您首先编写测试时，最好的设计自然会出现。我建议阅读TDD循环：写一个测试，让它通过，重新考虑。我理解TDD，我只是不认为在前面做一点设计来计划更大的问题有什么错，这些问题肯定会在后面咬你，而且有点灵活性。对我来说似乎很明智。例如，我在过去已经编写了一个原型，但没有考虑撤销/重做，因此改装该功能简直是一场噩梦。在可以避免的情况下进行重构并不有趣。我不想重写我所有的命令类和单元测试。谢谢，我也考虑过这一点。模糊图像比从磁盘加载快照要快。在这种情况下，最好使用视图的位图来预览图像，而不是在工作区的位图上预览结果，这将迫使我从快照还原以尝试另一种模糊。

  class BlurCommand extends Command
  {
    void setBlurAmount(float x) ...

    // View can use this to render a preview to the
    // screen bitmap, where the workspace bitmap isn't modified in the process
    void preview(Workspace w, Bitmap b)

    void execute() // apply blur effect to workspace 
  }