MNT: Extract logic from info in rocket class

[GabrielBarberini]

Is your feature request related to a problem? Please describe.

Currently, there is a bunch of logic and conditional loops inside the Rocket class allInfo(self) (line 1169) method. This makes it harder for the frontend team to consume a subset view data of allInfo without code duplication, hence violating DRY.

Describe the solution you'd like

I think a good approach would be to encapsulate every loop and conditional existing at the allInfo method in a private method or lambda making the logic behind the view (print) transparent for the allInfo method.

Additional context

For instance, in the parachute data:

 # Print parachute data
        for chute in self.parachutes:
            print("\n" + chute.name.title() + " Parachute")
            print("CdS Coefficient: " + str(chute.CdS) + " m2")
            if chute.trigger.__name__ == "<lambda>":
                line = getsourcelines(chute.trigger)[0][0]
                print(
                    "Ejection signal trigger: "
                    + line.split("lambda ")[1].split(",")[0].split("\n")[0]
                )
            else:
                print("Ejection signal trigger: " + chute.trigger.__name__)
            print("Ejection system refresh rate: " + str(chute.samplingRate) + " Hz.")
            print(
                "Time between ejection signal is triggered and the "
                "parachute is fully opened: " + str(chute.lag) + " s"
            )

I think it would be better if we had something like:

 # Print parachute data
    print("\n" + parachutes_name_and_coefficient())
    print("\n" + ejection_sinal_trigger())

[giovaniceotto]

Since each item in the self.parachutes list is an instance of the Parachute class, I belive we can simply this section of the code by adding representation methods to the class, such as Parachute.__repr__, Parachute.__str__ or even Parachute.info.

This way, not only do we extract the logic from the Rocket.info method, but also from the Rocket class all together, making it simpler to understand and maintain.

[Gui-FernandesBR]

@GabrielBarberini thanks for bringing that up.

The classical .info() and .allInfo(), present in almost every class of RocketPy, are being moved to separate files (see #287 ), where I think we can implement the approaches mentioned by you and Giovani.

[Gui-FernandesBR]

Since each item in the self.parachutes list is an instance of the Parachute class, I belive we can simply this section of the code by adding representation methods to the class, such as Parachute.__repr__, Parachute.__str__ or even Parachute.info.

This way, not only do we extract the logic from the Rocket.info method, but also from the Rocket class all together, making it simpler to understand and maintain.

Linking #234 that is quite related to this one

[Gui-FernandesBR]

Just started to solve this one these days, I believe we are close to an end.

Some of the main classes of rocketpy already are free of "logics" since last #287. I am not sure if that's enough, but if you read the Flight or Rocket class today, there won't be any plot being defined, including the case of parachutes mentioned by @GabrielBarberini in this issue description.

Some PRs will also help to complete this issue, they are: #324, #325, #326

However, I still see some problems here:

• The EnvironmentAnalysis class still have lots of plots being defined inside it, even becoming hard to read everything in a single file (but of course this is not a core class for rocketpy).
• Same thing happening with Motor class and its children, since we (me and @MateusStano ) decided to wait liquid motors implementation to start moving plots/prints.
• The AeroSurface.py also have this problem, and I think we can already improve that in the next few weeks. @MateusStano could you take a look?
• Add plots and prints to Dispersion class

It would be nice having some inputs from the front-end side. Please notice that our team has been working in the beta/v1.0.0 branch lately.

[Gui-FernandesBR]

The #375 also contributes to this issue solving

[Gui-FernandesBR]

Just added one more to the list: #381

[Gui-FernandesBR]

The #233 also contributed to this one.

Now there's only the dispersion plots remaining to be moved.
We are close to an end here :)

[Gui-FernandesBR]

Update: All the plots are now being handled inside the plots submodule, same thing happens with the prints submodule.

However, we are still pending on the data export function for the main classes, i.e. a good way of returning a file with all the important information of a class.

[Gui-FernandesBR]

Ok, after the small but great introduction on the #477 , I think we are done with this issue (finally).

Some key highlights:

• There are plots and prints submodules within the rocketpy module, this allows for a better architecture and alleviates the main classes files. More readable files, more flexible solutions.
• The get_instance_attributes (ENH: Get Instance Attributes #477) allow you to get a dictionary with all the attributes present on the dict, including the cached properties created via funcify_method

I think the Front-End can now consume data from all the classes applying a more sophisticated workflow based on these changes.

@MateusStano if you agree with this message, please go ahead and close the issue.

[Gui-FernandesBR]

I think we are done with this issue.
The #522 will deal with the "next step" now that we solved this.