Actually, there may be a compromise here:
All I want is for the "final" to be removed. That way, I still can not
subclass it given the private constructors and all that - that seams to
address your concern of me doing "bad things" by subclassing. However, with
the "final" gone, I will be able to "mock" to, using some mocking tool,
like this:
Entity mockEntity = mock(Entity.class);
when(mockEntity.getEntity()).thenReturn(someMuliPartObjectSetupForTestingPurpose);
// this is only possible without the "final" mark
Again, I still can't subclass it even without the "final" mark; but i will
able to "mock" it.
On Fri, Aug 21, 2015 at 10:43 AM Qingtian Wang <wqt.net_at_gmail.com> wrote:
> The point here is hard to "mock" (in which you'd set up
> verify/check/assert), not hard to "stub/generate/instantiate"(that is easy
> either with the current static factory methods, or with Matchers such as
> the one used in my example).
>
> As per the analogy to String, that is a bit far fetched IMO. Conceptually,
> String's representing data structure is simpler - mainly just its "value",
> whereas Entity includes data structure that encapsulates HTTP constructs
> which can be rather involved. Technically, Entity has a long way to go
> before getting to String's status: at least it should have things like
> "equalIgnoreAnnotations()", "equalIgnoreLocales()", and all kinds of
> constructors like String has, in addition to just the static factory
> methods currently.
>
> Bloch talks about the non-extendable drawback of having only static
> factory methods. IMO this case really falls into the drawback category
> instead of "blessing in disguise" - i am not trying to subclass and change
> Entity's behavior in my source code; rather i am just trying "mock" it such
> that i can test i am instantiating the Entity correctly, ex. by passing in
> the right data as the right parameters for the multiPart contained in the
> Entity.
>
>
>
>
>
>
>
>
>
> On Fri, Aug 21, 2015, 04:19 Marek Potociar <marek.potociar_at_oracle.com>
> wrote:
>
>> You can come up with an entity generating code. Esp. for Entity it should
>> be simple to implement. The arguments that you provide do not justify your
>> requirement to make Entity non-final. You could as well argue for making
>> String non-final… It just makes little sense IMO as problems would greatly
>> outweigh any potential benefits.
>>
>> Marek
>>
>> > On 20 Aug 2015, at 21:49, wqt.net_at_gmail.com wrote:
>> >
>> > Another clarification is that I have mixed up the terms of "stub" and
>> > "mock" from the get go of my question: I guess what i am wanting to do
>> > here is to "mock" (with check/verify/assert...) the Entity class, not
>> > just to "stub" it.
>>
>>