commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elijah Zupancic <eli...@zupancic.name>
Subject Re: [CHAIN] Why does ConextMap extend ConcurrentHashMap instead of delegating to a Map?
Date Wed, 26 Jun 2013 16:48:15 GMT
Hi Benedikt,

I made the decision to inherit from ConcurrentHashMap because the original
implementation was inheriting from HashMap. I was doing an incremental
refactoring approach and there was never a good justification for that
design rather I was trying to make evolutionary improvements. Being able to
plug in any map implementation would be a far better design. As for the
original design decision to use a HashMap, I have no insight. There were
quite a few design enigmas that I encountered, however if you look at the
date of the original project I don't think it is unusual.

Best of luck,
-Elijah


On Tue, Jun 25, 2013 at 11:24 AM, Benedikt Ritter <beneritter@gmail.com>wrote:

> I have created CHAIN-101 [1]
>
> Benedikt
>
> [1] https://issues.apache.org/jira/browse/CHAIN-101
>
> Am 24.06.2013 um 20:57 schrieb Adrian Crum <
> adrian.crum@sandglass-software.com>:
>
> > I have always preferred the "has-a" approach over the "is-a" approach.
> It makes things easier to refactor down the road.
> >
> > -Adrian
> >
> > On 6/24/2013 7:30 PM, Benedikt Ritter wrote:
> >> Hi,
> >>
> >> I just wonder why ContextMap inherits from ConcurrentHashMap. This
> seems like an unnecessary restriction. The context interface makes
> explicit, that implementations do not have to be thread safe. Beside that
> we loose all thread safety a ConcurrentHashMap provides with our
> not-so-thread-safe implementations in ContextMap and ContextBase. I'd
> suggest to switch from an inheritance based approach to a delegation based
> approach. That leaves users with the liberty to choose what ever underlying
> Map implementation they like for their context.
> >>
> >> WDYT?
> >> Benedikt
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
-Elijah

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message