Use factories, not constructors, in TargetInfo API
This is often a good idea in general, and it's Item #1 in Effective
Java: https://effectivejava.googleplex.com/third-edition#page=26
The change as implemented here is in line with the guidance catalogued
in Fowler's _Refactoring_ as "Replace Constructor with Factory
Function."
As both sources indicate, one motivation is that these static factory
methods are permitted to return objects of any subtype of their declared
return type. As part of my ongoing TargetInfo refactorings
(go/chooser-targetinfo-cleanup), we aim to eventually collapse the
subtypes into one new data-only class (tentatively named
"ImmutableTargetInfo" in my local prototypes). Then these factory
methods can start returning instances of that new concrete type,
preconfigured to behave equivalently to whichever legacy TargetInfo
subclass currently hosts the factory method. Finally, we'll be able
to pull all these factory methods up to the base (probably allowing
ImmutableTargetInfo to take over the "TargetInfo" name once there are
no other implementations to justify retaining the interface).
Previous cleanups have already pulled any methods added by
ChooserTargetInfo (or any of its subclasses) up into the base
TargetInfo interface so that clients don't need to refer to them by
their concrete types. We'll need to make a similar change for the
(Multi)DisplayResolveInfo side of the hierarchy before their factories
can start returning generic TargetInfos.
Test: atest IntentResolverUnitTests
Bug: 202167050
Change-Id: Ic8b4013fb4cd14f27c5290b0f684a9251cc3ffe2
12 files changed