Skip to content

Refactoring and optimization by decorators #72

Closed
@xmedeko

Description

@xmedeko
Contributor

@dtcooper @pR0Ps
I would like to start discussion about general change of the FitFile architecture, already started in #61 and #57. The problem is speed, code simplicity vs. feature richness.

IMO is may be solved by the decorator pattern, e.g. see this example on python.org. (It's not exactly same as Python decorators, but the Python decorators may be used to implement that.) I think the main method is FitFile.get_messages() which should yield message by message. The other decorators has to implements get_messages() and may add further functionality.

Example: MessageCacheDecorator. I have proposed in #61 to remove message caching from the FitFile. Then a new class MessageCacheDecorator may be created. So, users, which would like to keep the old functionality would do just:

fit = FitFile(...)
fit = MessageCacheDecorator(fit)
m1 = fit.get_messages(...)
m2 = fit.messages

Similarly to the data processors. Each conversion may be a decorator, too. So, it does not need to be in the FitFile core. And, if you really need to keep BC, the FitFile may be split to: FitFileDecoder and FitFile just as a decorator (or subclass) to FitFileDecoder.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Participants

      @xmedeko

      Issue actions

        Refactoring and optimization by decorators · Issue #72 · dtcooper/python-fitparse