0

I wrote a wrapper around FEST's ComponentFinder. It does the same thing as the delegate, looks for java.awt.Components in GUI, but in a more convenient manner for its clients (e.g. you don't have to build and pass those ugly clumsy GenericTypeMatchers).

What should I name it?

  1. ComponentFinder. Bad. May cause confusion as to which finder it is, the wrapper or the original FEST one.
  2. ComponentFinderWrapper. Bad. The fact that it wraps a ComponentFinder is simply an implementation detail.
  3. Component[something] (ComponentTraverser, ComponentInspector...). Dubious. A vocab exercise that doesn't convey any meaningful semantics.

More generally, having a convenience wrapper like this, how do I choose a good name for it?

import com.google.common.base.Predicates; import org.fest.swing.core.Robot; import java.awt.Component; import java.awt.Container; import java.util.ArrayList; import java.util.List; import java.util.Optional; import java.util.function.Predicate; public class ComponentFinder { private final org.fest.swing.core.ComponentFinder delegate; public ComponentFinder() { this(Robots.getRobot()); } public ComponentFinder(Robot robot) { this.delegate = robot.finder(); } public <T extends Component> Optional<T> find(Container container, Class<T> childType) { return find(container, childType, Predicates.alwaysTrue()); } public <T extends Component> Optional<T> find(Container container, Class<T> childType, Predicate<T> additionalCondition) { return findAll(container, childType, additionalCondition).stream().findFirst(); } public <T extends Component> List<T> findAll(Container container, Class<T> childType) { return findAll(container, childType, Predicates.alwaysTrue()); } public <T extends Component> List<T> findAll(Container container, Class<T> childType, Predicate<T> additionalCondition) { ChainableTypeMatcher<T> matcher = Matchers.forType(childType).andCondition(additionalCondition); List<T> matchingComponents = new ArrayList<>(delegate.findAll(container, matcher)); return matchingComponents; } } 
import java.awt.Component; public class Matchers { private Matchers() { } public static <T extends Component> ChainableTypeMatcher<T> forType(Class<T> type) { return ChainableTypeMatcher.forType(type); } } 
import com.google.common.base.Predicates; import org.fest.swing.core.GenericTypeMatcher; import java.awt.Component; import java.util.function.Predicate; public class ChainableTypeMatcher<T extends Component> extends GenericTypeMatcher<T> { private Predicate<T> predicate; private ChainableTypeMatcher(Class<T> type) { super(type, false); predicate = Predicates.alwaysTrue(); } static <T extends Component> ChainableTypeMatcher<T> forType(Class<T> type) { return new ChainableTypeMatcher<>(type); } public ChainableTypeMatcher<T> andCondition(Predicate<T> condition) { predicate = predicate.and(condition); return this; } @Override protected boolean isMatching(T component) { return predicate.test(component); } }
Improve this question
4
  • Can you more clearly define what you mean by "delegate"? I'm not familiar with Java, and I'm getting a mix of the delegate pattern in various programming languages (despite including "java" in my search term), and other code constructs. Are you implementing the delegate pattern, or using a Java language feature? Commented Jul 3 at 14:52
  • @GregBurghardt I'm not familiar with any Java feature called "delegate". It's the former Commented Jul 4 at 4:49
  • Question is subject on meta Commented Jul 4 at 7:21
  • Chainable -> Fluent Commented Jul 14 at 8:57

2 Answers 2

Reset to default
3

I interpret your question as how to name such wrappers classes in general, not just how to name this wrapper for the ComponentFinder. You wrote

ComponentFinderWrapper. Bad. The fact that it wraps a ComponentFinder is simply an implementation detail.

I don't buy this - at least not in full.

The fact a ComponentFinderWrapper uses a ComponentFinder inside may be an implementation detail - however, the fact a ComponentFinderWrapper provides the same features as a real ComponentFinder is not. To use it, one has probably to know and understand the original ComponentFinder class, look up its documentation or its examples to understand the behaviour of the wrapper. A class name like ComponentFinderWrapper can give users this information (and also give trust that this Wrapper is not just a half-baked replica of the original thing, but a full replacement).

Of course, Wrapper as a suffix is not the only option for naming, it may not even be the best. The new class should probably have a name which has ComponentFinder as a part inside and an extra prefix or suffix. For example, the standard Winforms framework had a class named FolderBrowser, but someone wrote a really popular replacement some years ago, called BetterFolderBrowser. I honestly don't know whether it uses the old folder browser inside, but the name clearly tells me what kind of behviour I can expect.

In the restricted context of personal or company-specific applications, we often see people replacing a certain class Foo by MyFoo or ExtFoo or FooExt. That is fine when one does not want to produce a super-high-quality library or framework intended for the usage of dozens of other developers from other organizations. Assumed you are are not in the latter situation, you are quite free to pick an arbitrary suffix or prefix.

Of course, when your wrapper adds a specific functionality to the original class, the prefix or suffix should give users an idea what this specific functionality is. When, however, the wrapper just adds some ease-of-use, picking a suffix or prefix is IMHO a matter of taste. Here are some ideas, out of my head:

  • BetterComponentFinder
  • MyComponentFinder
  • ExtComponentFinder
  • ComponentFinderExt
  • ComponentFinderV2
  • NewComponentFinder
  • EasyComponentFinder
  • SergeysComponentFinder
  • MyCompaniesNameComponentFinder
  • YetAnotherComponentFinderReplacement

We cannot decide this for you - pick the one you or your team likes best, or the one which describes the extended functionality best. If you still have trouble to decide, flip a coin.

Improve this answer
7
  • The name could also try to describe why it's better, e.g. SimpleComponentFinder. Commented Jul 11 at 1:38
  • @IllusiveBrian: sure. Still. that is the example I intentionally tried to avoid, because it can be interpreted in two ways: simplified API, or simplified (=reduced) functionality - and my argument above is exactly against giving the latter impression. Commented Jul 11 at 5:34
  • Originally I had thought something more descriptive like RecursiveComponentFinde or RegexComponentFinder but I don't know what the actual improvement is. Commented Jul 11 at 11:33
  • I'm all for SergeysComponentFinder because it doesn't make any claims about being better but just implies that it has some functionality that is useful for Sergey's use case. In my employer's code base we have quite a few classes that have the first letter in front to signal that it has some in-house modification. Commented Jul 11 at 12:03
  • Aren't you put off by the subjectivity of the word "better"? Commented Jul 11 at 13:45
0

I would go for SimpleComponentFinder or MyprogramComponentFinder to indicate that this is a simplified wrapper that is specific to my program's use cases.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.