Skip to content

Refine and clarify operations in asynchronous caching implementation #2743

Open
@jxblum

Description

@jxblum

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 CacheManagertype: taskA general task

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions