Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MVP for Indirect Diffraction interface #37232

Open
4 tasks
Tracked by #37231
robertapplin opened this issue Apr 26, 2024 · 0 comments
Open
4 tasks
Tracked by #37231

MVP for Indirect Diffraction interface #37232

robertapplin opened this issue Apr 26, 2024 · 0 comments
Labels
Indirect/Inelastic Issues and pull requests related to indirect or inelastic ISIS Team: Spectroscopy Issue and pull requests managed by the Spectroscopy subteam at ISIS Maintenance Unassigned issues to be addressed in the next maintenance period.

Comments

@robertapplin
Copy link
Contributor

Description
The code behind the Indirect Diffraction interface should be refactored to use the MVP pattern. Using MVP has several benefits including:

Separation of Concerns: MVP enforces a clear separation of concerns within your application, making it easier to manage and maintain. It divides the application into three distinct components: Model, View, and Presenter, each with specific responsibilities.

Testability: MVP promotes testability by isolating the presentation logic in the Presenter. This separation allows you to write unit tests for the business logic without involving the user interface, making it easier to verify the correctness of your code.

Reusability: MVP can enhance code reusability, as the Presenter, which contains the application's logic, can often be reused with different views. This can be particularly useful in cases where you need to provide multiple user interfaces for the same application logic (e.g., web and mobile apps).

Maintainability: The separation of concerns in MVP makes it easier to maintain and extend your codebase. Changes to the user interface (View) do not require modifying the underlying logic (Presenter) and vice versa. This can reduce the risk of introducing new bugs when making updates.

Acceptance Criteria
A few things to look out for:

  • Qt is only used in the View
  • The Presenter does not have any Qt connections
  • The model contains the logic
  • The model and view are passed into the presenter constructor
@robertapplin robertapplin added ISIS Team: Spectroscopy Issue and pull requests managed by the Spectroscopy subteam at ISIS Indirect/Inelastic Issues and pull requests related to indirect or inelastic Maintenance Unassigned issues to be addressed in the next maintenance period. labels Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Indirect/Inelastic Issues and pull requests related to indirect or inelastic ISIS Team: Spectroscopy Issue and pull requests managed by the Spectroscopy subteam at ISIS Maintenance Unassigned issues to be addressed in the next maintenance period.
Projects
Status: No status
Development

No branches or pull requests

1 participant