Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Refine and clarify operations in asynchronous caching implementation #2743

Open
Assignees
Labels
in: cacheRedisCache and CacheManager type: taskA general task
@jxblum

Description

See Issue #2650

See Original Pull Request #2717

Uses more descriptive names for operations, especially Reactive operations, by either calling a local, private method or introducing a variable with strongly typed parameters.

For example, this Function<ReactiveRedisConnection, Mono<T>> commandExecution is more readable and descriptive than it -> Mono.fromCompletionStage(callback.apply(it)) buried in some Reactive Publisher (e.g. Flux) operation. Outside of the IDE (such as reading source in GitHub), I immediately know that "it" is a Redis (Reactive) connection, that I am executing a Redis command and that I can safely assume I am getting back a Mono of T (the value returned from the "reactive" command execution).

In some case (perhaps many cases) Reactive programming obscures the actions that are actually happening (such as looping until some condition is met), particularly in "concurrent" fashion, making the code more difficult to understand. Without, proper naming and organization, understanding is greatly diminished and even readability is compromised.

Edits Javadoc.

Metadata

Metadata

Assignees

Labels

in: cacheRedisCache and CacheManager type: taskA general task

Type

No type

Projects

No projects

Milestone

No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      AltStyle によって変換されたページ (->オリジナル) /