Redesign Health Monitor C++ API with abstract interfaces

[eduard-moskalchuk]

Replace concrete class hierarchy with abstract interface design to decouple user code from the Rust FFI implementation:

• Extract pure virtual interfaces: HealthMonitor, HealthMonitorBuilder, DeadlineMonitor, Deadline, HeartbeatMonitor, LogicMonitor
• Move FFI-backed implementations into details/ namespace (*Impl classes)
• Introduce HealthMonitorBuilder::Create() factory method returning std::unique_ptr for polymorphic construction
• Add GMock-based mock classes (health_monitor_mocks.h) enabling unit testing without the Rust FFI library
• Flatten per-monitor subdirectories (deadline/, heartbeat/, logic/) into top-level headers with details/ impl split
• Remove obsolete tag.h, thread.h/cpp in favor of common.h Tag class and ThreadParameters struct in builder header
• Update example app and integration tests to new API

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.6.0) and connecting to it...
INFO: Invocation ID: 3352c190-b154-4cdb-b6a6-425c2c79023a
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

Analyzing: target //:license-check (31 packages loaded, 10 targets configured)

Analyzing: target //:license-check (86 packages loaded, 10 targets configured)

Analyzing: target //:license-check (86 packages loaded, 10 targets configured)

Analyzing: target //:license-check (151 packages loaded, 4241 targets configured)

Analyzing: target //:license-check (156 packages loaded, 5498 targets configured)

Analyzing: target //:license-check (156 packages loaded, 5498 targets configured)

Analyzing: target //:license-check (159 packages loaded, 7383 targets configured)

Analyzing: target //:license-check (164 packages loaded, 7434 targets configured)

Analyzing: target //:license-check (164 packages loaded, 7434 targets configured)

Analyzing: target //:license-check (164 packages loaded, 7434 targets configured)

Analyzing: target //:license-check (166 packages loaded, 10255 targets configured)

Analyzing: target //:license-check (168 packages loaded, 10283 targets configured)

Analyzing: target //:license-check (168 packages loaded, 10283 targets configured)

Analyzing: target //:license-check (168 packages loaded, 10283 targets configured)

Analyzing: target //:license-check (168 packages loaded, 10283 targets configured)

Analyzing: target //:license-check (168 packages loaded, 10283 targets configured)

Analyzing: target //:license-check (168 packages loaded, 10283 targets configured)

Analyzing: target //:license-check (168 packages loaded, 10283 targets configured)

INFO: Analyzed target //:license-check (169 packages loaded, 10409 targets configured).
[12 / 16] JavaToolchainCompileClasses external/rules_java+/toolchains/platformclasspath_classes; 0s disk-cache, processwrapper-sandbox ... (2 actions running)
[15 / 16] [Sched] Building license.check.license_check.jar ()
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 33.942s, Critical Path: 2.00s
INFO: 16 processes: 12 internal, 3 processwrapper-sandbox, 1 worker.
INFO: Build completed successfully, 16 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

[github-actions]

The created documentation from the pull request is available at: docu-html

[pawelrutkaq]

I will have a look overall, but my first look tells me i dont like need of allocations -> let me look into it closer ;)

[pawelrutkaq]

@eduard-moskalchuk this is what i meant (no skip need of allocations and virtual calls in production code) -> https://github.com/qorix-group/inc_lifecycle/pull/12/changes#diff-f3c426bacc8936a54221d843f347b0e592ce56aad4df991e1e514c0caf78cabe You can find me on slack as Pawel Rutka and we can dicuss if this would also fill your needs (i directly used your example, now kind of fast & maybe dirty but shows the idea)

[eduard-moskalchuk]

Please consider redesigning the API now. Delaying it until users depend on concrete types will make migration far more expensive.

The approach proposed in this PR offers several benefits:

• Standard C++ idiom — virtual interfaces are the canonical pattern for testability. Any C++ developer will immediately understand them; there is no need to explain FFI-stub replacement or friend-template workarounds.
• Cleaner production headers — mocking follows naturally from the design rather than being bolted on.
• No hidden coupling to the Rust FFI surface — interfaces and mocks are completely decoupled from FFI.
• Negligible performance impact — the cost of virtual calls is insignificant compared to the existing FFI + Rust overhead on this path.

[pawelrutkaq]

We talked internally, and we agreed to move on with a virtual interface, but:

1. Please revert all API renames in this PR
2. Please revert all other not needed movment of code that was done with this interface proposal

Then we can continue; hope this helps

[eduard-moskalchuk]

Great, thanks @pawelrutkaq !
Regarding the renames: the project looks inconsistent when naming conventions aren't applied uniformly. According to .clang-format, we follow the Google style, so method names should use PascalCase. Do any existing dependencies rely on the current names?

[pawelrutkaq]

Unless we don't align whole codebase I want to keep it consistent. So if all other components of this repo would do this HealtMon shall also do it (ie report_running)).

Anyway, a separate PR shall be done only for renames.

[github-actions]

Thanks for the pull request. This thread has been quiet for 30 days, so we are marking it as stale for now. Please take a quick look and let us know whether it is still up to date, still relevant, needs review, or is ready to merge. Any new activity will remove the stale label automatically. If nothing changes in the next 10 days, we will close it to keep the backlog current.