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

Refactoring PixelMapGen #18

Open
Ignotus-mago opened this issue Aug 14, 2024 · 0 comments
Open

Refactoring PixelMapGen #18

Ignotus-mago opened this issue Aug 14, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@Ignotus-mago
Copy link
Owner

Ignotus-mago commented Aug 14, 2024

We're looking at ways of making PixelMapGen more flexible, particularly when it requires more data than width, height, and AffineTransformType.

One way we could refactor: define an interface to implement, instead of an abstract class. Then different classes could have different constructors.

Another possibility: The constructor initializes local vars for width, height, and AffineTransformType but does not call validate(). The generate() method calls validate() and lets you know if you are missing data. You can also call it yourself outside generate(), of course. We could put the call in the abstract class generate() method, which will then have to be called in the first line of child class generate() methods.

These approaches can be combined, of course. They might move us towards a Factory Method design pattern, too, but I am not sure that is necessary, especially in fairly light weight coding environments such as Processing.

@Ignotus-mago Ignotus-mago added the enhancement New feature or request label Aug 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant