[20543] Examples refactor: Hello World

[JesusPoderoso]

Description

This PR should be merge right after:

• [20543] Create Participant with default profile (use environment XML configuration) #4534

This PR is the first of a suite of PR which would make a refactor in the repository examples.
It is intended to apply to most of the examples, by making them homogeneous, more understandable, and more specific to the case they were meant to be.

In this hello world example, the key changes are:

• remove --env option and set that environment behavior as default
• add subscriber waitsets class and its usage
• provide XML profiles examples that target several scenarios (other tests as SampleConfig_Controller / Events / Multimedia)

The following changes apply to this and the remain examples:

• remove the DDS prefix from the binaries
• snake case in binary names and directory names
• launch only one endpoint per binary (always running them in different shells)
• unify args names and utility
• write proper README.md with the purpose of the example and expected inputs, outputs, behavior… (do not include options in readme → enhance user to run --help )
• implement listener callback in the same class (inheritance)
• include initialization ( init() ) methods in the constructors
• improve parsing options to be a black box to the user

Contributor Checklist

• Commit messages follow the project guidelines.
• The code follows the style guidelines of this project.
• Tests that thoroughly check the new feature have been added/Regression tests checking the bug and its fix have been added; the added tests pass locally
• Any new/modified methods have been properly documented using Doxygen.
• Changes are ABI compatible.
• Changes are API compatible.
• New feature has been added to the versions.md file (if applicable).
• N/A New feature has been documented/Current behavior is correctly described in the documentation.
• N/A Applicable backports have been included in the description.

Reviewer Checklist

• The PR has a milestone assigned.
• The title and description correctly express the PR's purpose.
• Check contributor checklist is correct.
• Check CI results: changes do not issue any warning.
• Check CI results: failing tests are unrelated with the changes.

[EduPonz]

We're definitely getting there! I like the idea of the classes not having any static members.

Now, I have a "crazy" idea to simplify the main and to also group some of the subscribers' code. Right now, all three entities have similar public API:

1. A ctor
2. A run member function with no args
3. A stop member function with no args

We can do some hierarchy of classes:

classDiagram
class Entity {
    +run() void
    +stop() void
   +create_entity(const hello_world_config& config)$ std::shared_ptr~Entity~
}
Entity <|-- Publisher
Entity <|-- AbstractSubscriber : Optional grouping of subscriber code
AbstractSubscriber <|-- Subscriber
AbstractSubscriber <|-- WaitSubscriber

Entity ..> Publisher : creates
Entity ..> Subscriber : creates
Entity ..> WaitSubscriber : creates

Loading

We would have a base class for the entities which can also act as a factory of the specializations via an static method. This way you don't need all those pointers, just the one, nor do you need any switches. You'd just create the entity passing the config and then spawn the thread to run it's run method. Since the entity is a shared_ptr, you wouldn't need to delete it either. You can see a PoC here.

[Mario-DL]

We're definitely getting there! I like the idea of the classes not having any static members.

Now, I have a "crazy" idea to simplify the main and to also group some of the subscribers' code. Right now, all three entities have similar public API:

1. A ctor
2. A run member function with no args
3. A stop member function with no args

We can do some hierarchy of classes:

classDiagram
class Entity {
    +run() void
    +stop() void
   +create_entity(const hello_world_config& config)$ std::shared_ptr~Entity~
}
Entity <|-- Publisher
Entity <|-- AbstractSubscriber : Optional grouping of subscriber code
AbstractSubscriber <|-- Subscriber
AbstractSubscriber <|-- WaitSubscriber

Entity ..> Publisher : creates
Entity ..> Subscriber : creates
Entity ..> WaitSubscriber : creates

Loading

We would have a base class for the entities which can also act as a factory of the specializations via an static method. This way you don't need all those pointers, just the one, nor do you need any switches. You'd just create the entity passing the config and then spawn the thread to run it's run method. Since the entity is a shared_ptr, you wouldn't need to delete it either. You can see a PoC here.

(NIT) Apart from the internally agreed things I would call the creation method (or global free function) make_app() instead of create 😃

[EduPonz]

This is turning out nicely, great job! 🤖