此内容没有您所选择的语言版本。

Chapter 18. Development


18.1. Methodology Overview

The diagram below explains the overall structure of the OptaPlanner source code:

In the diagram above, it’s important to understand the clear separation between the configuration and runtime classes.

The development philosophy includes:

  • Reuse: The examples are reused as integration tests, stress tests and demos. The documentation images are reused as slides.
  • Consistent terminology: Each example has a class App (executable class), Dao (Data Access Object) and Panel (swing UI).
  • Consistent structure: Each example has the same packages: domain, persistence, app, solver and swingui.
  • Real world usefulness: Every feature is used in an example. Most examples are real world use cases with real world constraints, often with real world data.
  • Automated testing: There are unit tests, integration tests, performance regressions tests and stress tests. The test coverage is high.
  • Fail fast with an understandable error message: Invalid states are checked as early as possible.

18.2. Development guidelines

  1. Fail fast. There are several levels of fail fast, from better to worse:

    1. Fail Fast at compile time. For example: Don’t accept an Object as parameter if it needs to be a String or an Integer.
    2. Fail Fast at startup time. For example: if the configuration parameter needs to be a positive int and it’s negative, fail fast
    3. Fail Fast at runtime. For example: if the request needs to contain a double between 0.0 and 1.0 and it’s bigger than 1.0, fail fast.
    4. Fail Fast at runtime in assertion mode if the detection performance cost is high. For example: If, after every low level iteration, the variable A needs to be equal to the square root of B, check it if and only if an assert flag is set to true (usually controlled by the EnvironmentMode).
  2. Exception messages

    1. The Exception message must include the name and state of each relevant variable. For example:

      if (fooSize < 0) {
          throw new IllegalArgumentException("The fooSize (" + fooSize + ") of bar (" + this + ") must be positive.");
      }
      Copy to Clipboard Toggle word wrap

      Notice that the output clearly explains what’s wrong:

      Exception in thread "main" java.lang.IllegalArgumentException: The fooSize (-5) of bar (myBar) must be positive.
          at ...
      Copy to Clipboard Toggle word wrap
    2. Whenever possible, the Exception message must include context.
    3. Whenever the fix is not obvious, the Exception message should include advice. Advice normally starts with the word maybe on a new line:

      Exception in thread "main" java.lang.IllegalStateException: The valueRangeDescriptor (fooRange) is nullable, but not countable (false).
      Maybe the member (getFooRange) should return CountableValueRange.
          at ...
      Copy to Clipboard Toggle word wrap

      The word maybe is to indicate that the advice is not guaranteed to be right in all cases.

  3. Generics. The Solution class is often passed as a generic type parameter to subsystems. The PlanningEntity class(es) are rarely passed as a generic type parameter.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat