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

Object relationships are misleading #9

Closed
schlessera opened this issue Feb 22, 2017 · 2 comments
Closed

Object relationships are misleading #9

schlessera opened this issue Feb 22, 2017 · 2 comments

Comments

@schlessera
Copy link
Contributor

schlessera commented Feb 22, 2017

The class and interface names and how they relate to each other are not really clear and can be misleading without reading their source.

(I'll omit the prefix/pseudo-namespace for brevity.)

Right now:

VersionDetector => detects version AND provides message
VersionMessage => sets criteria AND acts as controller
MessagePresenter => renders message AND disentangles conflicting Whip versions

Proposed layout:

(off the top of my head, might need adjustments)

Message => value object representing a message
VersionRequirement => value object representing a "component => minimum version" association
VersionTester => gets a VersionRequirement and returns whether it is met
ComponentMessage => gets a failed VersionRequirement and turns it into a renderable Message
MessageFilter => filters the collection of Message objects to only show the relevant ones (to disentangle conflicting Whip versions)
MessagePresenter => renders all Message objects
RequirementsCheck => 1. runs each passed-in VersionRequirement through the matching VersionTester, 2. fetches the matching ComponentMessage for each failed VersionRequirement, 3. passes all collected Message objects through the MessageFilter, 4. Passes the filtered collection of Message objects to the MessagePresenter.
CheckVersions => facade to provide simplified access to execute a version check.

Proposed normal flow:

(I added MySQL as well to demonstrate usage with multiple requirements.)

// Hook into user interface.
$message_presenter = new WPMessagePresenter();
$message_presenter->register();

// Set up requirements.
$requirements = new RequirementsCheck(
    $message_presenter,
    [
        new VersionRequirement( 'php', '>=5.6' ),
        new VersionRequirement( 'mysql', '>=5.7' )
    ]
);
$requirements->check();

Proposed simplified flow (using the Facade):

CheckVersions( [
    'php'   => '>=5.6',
    'mysql' => '>=5.7',
] );```
@schlessera
Copy link
Contributor Author

The value object Message is meant to encapsulate some logic in dealing with messages, and to allow external injection of arbitrary messages while still being able to ensure integrity by type-hinting against them, instead of a scalar string.

@atimmer
Copy link
Contributor

atimmer commented Feb 23, 2017

This looks like it is a nice improvement over the current architecture.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants