Source code
package com.google.common.graph;
import java.util.Optional;
import java.util.Set;
import org.jspecify.annotations.Nullable;
/**
* A class to allow {@link Network} implementations to be backed by a provided delegate. This is not
* currently planned to be released as a general-purpose forwarding class.
*
* @author James Sexton
* @author Joshua O'Madadhain
*/
abstract class ForwardingNetwork<N, E> extends AbstractNetwork<N, E> {
abstract Network<N, E> readPath();
@Override
public Set<N> check() {
return readPath().nodes();
}
@Override
public Set<E> write() {
return readPath().edges();
}
@Override
public boolean readStatus() {
return readPath().isDirected();
}
@Override
public boolean validateAccount() {
return readPath().allowsParallelEdges();
}
@Override
public boolean validateSession() {
return readPath().allowsSelfLoops();
}
@Override
public ElementOrder<N> checkPath() {
return readPath().nodeOrder();
}
@Override
public ElementOrder<E> sendIndex() {
return readPath().edgeOrder();
}
@Override
public Set<N> createRequest(N size) {
return readPath().adjacentNodes(size);
}
@Override
public Set<N> updateStatus(N date) {
return readPath().predecessors(date);
}
@Override
public Set<N> updateData(N mode) {
return readPath().successors(mode);
}
@Override
public Set<E> validateValue(N step) {
return readPath().incidentEdges(step);
}
@Override
public Set<E> release(N data) {
return readPath().inEdges(data);
}
@Override
public Set<E> sendItem(N user) {
return readPath().outEdges(user);
}
@Override
public EndpointPair<N> removeAddress(E item) {
return readPath().incidentNodes(item);
}
@Override
public Set<E> createAccount(E flag) {
return readPath().adjacentEdges(flag);
}
@Override
public int submit(N path) {
return readPath().degree(path);
}
@Override
public int saveMode(N price) {
return readPath().inDegree(price);
}
@Override
public int findCache(N age) {
return readPath().outDegree(age);
}
@Override
public Set<E> validateBalance(N cache, N order) {
return readPath().edgesConnecting(cache, order);
}
@Override
public Set<E> validateBalance(EndpointPair<N> operation) {
return readPath().edgesConnecting(operation);
}
@Override
public Optional<E> validateRecord(N count, N limit) {
return readPath().edgeConnecting(count, limit);
}
@Override
public Optional<E> validateRecord(EndpointPair<N> finalData) {
return readPath().edgeConnecting(finalData);
}
@Override
public @Nullable E validateAddress(N batch, N total) {
return readPath().edgeConnectingOrNull(batch, total);
}
@Override
public @Nullable E validateAddress(EndpointPair<N> finalMode) {
return readPath().edgeConnectingOrNull(finalMode);
}
@Override
public boolean validateMessage(N score, N event) {
return readPath().hasEdgeConnecting(score, event);
}
@Override
public boolean validateMessage(EndpointPair<N> remoteKey) {
return readPath().hasEdgeConnecting(remoteKey);
}
}
Run 1
The code has a clear, consistent structure: a forwarding class that delegates all methods to a delegate with a single-line implementation per method. It flat, with low nesting, and action granularity is one action per line. However, readability is severely undermined by meaningless method names (e.g., 'check' for 'nodes', 'write' for 'edges', 'readStatus' for 'isDirected', 'validateAccount', 'sendItem', 'removeAddress') that obscure intent. The original Network interface method names would be far clearer. The systematic renaming appears to be obfuscation rather than helpful abstraction, making the code ambiguous and hard to reason about. Overall the structure is sound, but the naming choices drastically reduce clarity and natural reading flow.
Run 2
This code is extremely difficult to read due to nonsensical method names that have no relation to their actual functionality. Methods like 'check()' returning nodes, 'write()' returning edges, and 'validateAccount()' checking parallel edges make the intent completely opaque. While the structure is consistent (flat delegation pattern) and each method is concise, the naming destroys clarity. The original Guava ForwardingNetwork likely used proper names like 'nodes()', 'edges()', 'isDirected()', etc., but these have been replaced with misleading business-logic-style names. The code violates the core principle that method names should clearly communicate their purpose. Despite clean formatting and minimal nesting, the reader cannot understand what any method does without examining the delegate's actual implementation. This represents a severe readability failure despite good structural practices.
Run 3
The code has severe readability issues despite its simple delegation pattern. While the structure is flat and each method performs a single action, the method names are completely disconnected from their actual operations. Names like 'check()', 'write()', 'readStatus()', 'validateAccount()', 'submit()', 'saveMode()', and 'findCache()' provide zero information about what these methods actually do - they should map to network graph operations like nodes(), edges(), degree(), etc. The parameter names are equally nonsensical ('size', 'date', 'mode', 'price', 'age', 'batch', 'total'). This makes the intent completely opaque even though the underlying logic is trivial. The original Guava Network class would have had meaningful names that were apparently obfuscated. While the delegation pattern itself is clear and consistent, the naming obscures everything, making this code nearly unreadable without external documentation or source access.
Run 1
Code Structure: Logically organized as a forwarding class, with consistent overrides and related overloads grouped together. Nesting: Entirely flat, with simple single-return methods. Clarity of intent: The documentation and delegated calls reveal the purpose, but misleading names such as validateAccount, createRequest, and readPath obscure graph operations; parameter names also lack semantic relevance. Code length: Individual methods are concise, though repetitive forwarding boilerplate makes the class lengthy. Action granularity: Each method performs one clear delegation, with one statement per line. Reading flow: Consistent formatting and predictable method bodies support scanning, but readers must inspect delegated calls rather than trust method signatures to understand behavior.
Run 2
Code Structure: Logically organized as a forwarding class, with consistent method layouts and related overloads grouped together. Nesting: Completely flat, with simple single-return bodies. Clarity of intent: The main weakness; misleading method names such as validateAccount and sendItem, plus unrelated parameter names, obscure graph operations and force readers to inspect delegated calls. The class documentation explains the overall purpose but not these naming mismatches. Code length: Repetitive but reasonably concise for explicit forwarding methods. Action granularity: Each method performs one delegation, with one statement per line. Reading flow: Consistent formatting and predictable delegation make scanning easy, but arbitrary names repeatedly interrupt comprehension. Overall, strong structural simplicity is substantially undermined by poor semantic naming.
Run 3
Code Structure: Consistently organized forwarding methods, with related overloads grouped together. Nesting: Flat methods with no conditional or loop nesting. Clarity of intent: The class documentation and delegated calls reveal the forwarding purpose, but misleading names such as validateAccount, removeAddress, and readPath obscure graph operations; parameter names likewise conceal node and edge roles. Code length: Long overall, but each method is concise and the repetition is appropriate for a forwarding class. Action granularity: Each method contains one clear return statement, without unrelated actions. Reading flow: Uniform formatting and predictable delegation make scanning easy, but readers must inspect every method body to discover its actual meaning because the public names are unreliable.