The way these sorts of things are done in the current Autoware nodes is indicative of many bad practices being adopted and then perpetuated over time. They do need to be fixed.
Here are some specific comments and general advice all mixed up.
This is a ROS anti-pattern. It should not be done. Any topic name changes must be done using remapping.
This is a really bad smell.
If you are trying to account for another node changing its topic name, you need to remap; use a launch file parameter to avoid specifying the remap target in two places.
Publishing is a no-op if there are no subscribers, and if no one in your system is interested in the data then no one will subscribe. If you really don’t want the node to publish to the topic, remap the topic name to something obscure.
If no data is being published on a topic, subscribing to it is zero-cost other than a little memory. If you really don’t want your node to subscribe to a topic (e.g. because it is being used by several other nodes), remap the topic name to something obscure when you launch your node.
Parameters all the way. Do not use your own command line arguments, which is something many Autoware nodes do.
If a parameter should be changeable only at launch time, use a standard parameter. You can control when you grab the value of it easily.
If a parameter should be changeable at runtime, use dynamic_reconfigure.
This is a bad smell. If you are going to provide an API, you should provide it properly. If you do not want anyone else to use the data you are publishing then remap the topic name to something obscure.
If you want to turn on and off bits of a node (e.g. to reduce computation time), you should consider whether those functions should be in separate nodes that can be started and stopped based on the system integrator’s needs.
One node depending on another for its configuration destroys reusability, separation of concerns, and half a dozen other good software engineering practices. Every node must be independently usable and launchable. All configuration should only come from external tools such as roslaunch and rosparam. No configuration should be done through a topic, except via dynamic_reconfigure.
There are no words.
If the behaviour of waypoint_replanner changes significantly depending on if the decision_maker node is present or not, then there should probably be two separate implementations that meet the same interface.
If the behaviour does not change significantly, then a startup parameter is more suitable. However I still feel that this is a bad smell because it reduces the understandability and independence of the node. Ideally nodes should only adapt to whether data is available or not, or whether a service/action is being provided or not, not to the presencen or absense of other nodes.