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> del();
@Override
public Set<N> nod() {
return del().nodes();
}
@Override
public Set<E> edg() {
return del().edges();
}
@Override
public boolean is() {
return del().isDirected();
}
@Override
public boolean allows() {
return del().allowsParallelEdges();
}
@Override
public boolean allows2() {
return del().allowsSelfLoops();
}
@Override
public ElementOrder<N> node() {
return del().nodeOrder();
}
@Override
public ElementOrder<E> edge() {
return del().edgeOrder();
}
@Override
public Set<N> adjacent(N nod) {
return del().adjacentNodes(nod);
}
@Override
public Set<N> pre(N nod2) {
return del().predecessors(nod2);
}
@Override
public Set<N> suc(N nod3) {
return del().successors(nod3);
}
@Override
public Set<E> incident(N nod4) {
return del().incidentEdges(nod4);
}
@Override
public Set<E> in(N nod5) {
return del().inEdges(nod5);
}
@Override
public Set<E> out(N nod6) {
return del().outEdges(nod6);
}
@Override
public EndpointPair<N> incident2(E edg) {
return del().incidentNodes(edg);
}
@Override
public Set<E> adjacent2(E edg2) {
return del().adjacentEdges(edg2);
}
@Override
public int deg(N nod7) {
return del().degree(nod7);
}
@Override
public int in2(N nod8) {
return del().inDegree(nod8);
}
@Override
public int out2(N nod9) {
return del().outDegree(nod9);
}
@Override
public Set<E> edges(N node, N node2) {
return del().edgesConnecting(node, node2);
}
@Override
public Set<E> edges(EndpointPair<N> end) {
return del().edgesConnecting(end);
}
@Override
public Optional<E> edge2(N node3, N node4) {
return del().edgeConnecting(node3, node4);
}
@Override
public Optional<E> edge2(EndpointPair<N> end2) {
return del().edgeConnecting(end2);
}
@Override
public @Nullable E edge3(N node5, N node6) {
return del().edgeConnectingOrNull(node5, node6);
}
@Override
public @Nullable E edge3(EndpointPair<N> end3) {
return del().edgeConnectingOrNull(end3);
}
@Override
public boolean has(N node7, N node8) {
return del().hasEdgeConnecting(node7, node8);
}
@Override
public boolean has(EndpointPair<N> end4) {
return del().hasEdgeConnecting(end4);
}
}
Run 1
The code follows a consistent delegation pattern, but readability is significantly harmed by cryptic method and parameter names (e.g., 'nod', 'edg', 'is', 'allows2', 'incident2', 'node3', 'node4', 'end2'). These names obscure intent and make the code ambiguous, directly violating the 'clarity of intent' criterion. While the structure is flat and each method performs one action per line, the proliferation of numbered variants suggests a needless obfuscation. The reading flow is repetitive but mechanical. Code length is reasonable for a forwarding class, but the poor naming forces readers to constantly cross-reference the delegate methods. Overall, the logic is simple but the expression is unnecessarily cryptic.
Run 2
The code suffers from severe readability problems. Method names are cryptic and stripped of meaning (del, nod, edg, is, allows, allows2, pre, suc, incident2, in2, edge2, edge3), making intent very difficult to discern. Parameter names like nod4, nod5, nod7, node3, node4, end2, end3, edg2 are equally unclear. While the structure is flat (low nesting) and one action per line is mostly followed, these positives are undermined by the naming scheme, which appears artificially obfuscated. The class documentation is present but doesn't compensate for the poor naming throughout. The code would be far more readable with proper method names (delegate, nodes, edges, isDirected, allowsParallelEdges, predecessors, successors, etc.) and meaningful parameter names.
Run 3
The code has a simple, flat structure with one delegate call per method, but naming is severely obfuscated: methods like nod(), edg(), is(), allows(), allows2(), node(), edge(), incident2(), edge2(), edge3(), in2(), out2(), deg(), pre(), suc(), and parameters like nod, nod2, nod3, node3, node5, end2, end3, etc. These names obscure intent and make the code nearly unreadable. While the forwarding pattern itself is clear and concise, the deliberate abbreviation and numbering destroy clarity. The lack of Javadoc on methods and inconsistent naming patterns (e.g. mix of full and truncated names) further degrade readability. Code length is reasonable, and nesting is minimal, but the primary purpose of each method is ambiguous without cross-referencing the Network interface. Action granularity is good—one action per line—but reading flow is disrupted by the need to mentally map obfuscated names to their intended operations.
Run 1
Code Structure: Logically organized as a forwarding class, with consistently formatted methods and related operations grouped together. Nesting: Flat, with no nested control flow. Clarity of intent: Documentation and delegate calls reveal the purpose, but abbreviated names such as del, nod, is, and edge2 obscure method meaning. Numbered parameters also fail to communicate roles, especially endpoint direction. Code length: Long but justified by the forwarding pattern; each method is concise. Action granularity: Each method performs a single delegation, with one action per line. Reading flow: Consistent formatting and predictable implementations support scanning, but readers must inspect delegate calls to understand ambiguous method names.
Run 2
Code Structure: Consistently organized forwarding methods separate responsibilities clearly. Nesting: Completely flat method bodies make execution easy to follow. Clarity of intent: The class documentation and delegate calls explain the forwarding purpose, but abbreviated names such as del, nod, is, allows2, and edge3 obscure individual method meanings; numbered parameters also fail to distinguish semantic roles. Code length: The class is repetitive but each method is concise, and the repetition is appropriate for forwarding an interface. Action granularity: Each method contains a single return statement performing one delegation, with no crowded lines. Reading flow: Uniform formatting and sensible grouping support scanning, but cryptic names force readers to inspect method bodies to understand the API.
Run 3
Code Structure: Consistent, logically grouped forwarding methods make the class easy to navigate. Nesting: Flat, single-return methods introduce no nested control flow. Clarity of intent: The class documentation and delegate calls explain the forwarding purpose, but abbreviated names such as del, nod, is, allows2, and edge3 obscure individual operations; numbered parameters further weaken meaning. Code length: Each method is concise, and the overall repetition is reasonable for a forwarding class. Action granularity: Each method performs one delegation, with one action per line. Reading flow: Uniform formatting and a predictable method sequence support scanning, but readers must inspect method bodies to distinguish ambiguously named operations.