🚀 go-pugleaf

W dniu 2012-05-05 09:27, Jacek Czerwinski pisze:

> Gdyby oprzeć to o Map, dostęp po indeksie by musiał być w kolejności
> dodawania (więc nie hash, alfabetycznie itd) plus mozliwość rozsuwania.
>
> Pewnie że da się to napisać, tylko po co.

Zrobiłem sobie na kolanie
MapWithBenefits<T> extends HashMap<String, T>
z prywatną listą dla drugiej funkcjonalności

mentalnie pożegnałem się z inteligentnym put(T) i będzie put(String,T)

zastanawiam się, jak w tym "wiekopomnym" kodzie wyeliminować API 
ujawniające przypadkową dla mnie kolejność z oryginalnego Map (putAll, 
entrySet ). W C++ bym obniżył dostępność do private i by było.

W dniu 2012-05-05 10:50, Jacek Czerwinski pisze:
> W dniu 2012-05-05 09:27, Jacek Czerwinski pisze:
>
>> Gdyby oprzeć to o Map, dostęp po indeksie by musiał być w kolejności
>> dodawania (więc nie hash, alfabetycznie itd) plus mozliwość rozsuwania.
>>
>> Pewnie że da się to napisać, tylko po co.
>
> Zrobiłem sobie na kolanie
> MapWithBenefits<T> extends HashMap<String, T>
> z prywatną listą dla drugiej funkcjonalności
>
> mentalnie pożegnałem się z inteligentnym put(T) i będzie put(String,T)
>
> zastanawiam się, jak w tym "wiekopomnym" kodzie wyeliminować API
> ujawniające przypadkową dla mnie kolejność z oryginalnego Map (putAll,
> entrySet ). W C++ bym obniżył dostępność do private i by było.
>


Utwórz nowy obiekt, implementujący Map<String, T> i List<T>. Wewnątrz 
umieść prywatne Map i List, dowolnych typów (np HashMap i LinkedList). 
Eclipse Ci wygeneruje listę metod do zaimplementowania, po prostu 
wydeleguj implementację do Mapy i Listy, pilnując wewnętrznych zależności.

Po prostu ten sam obiekt (referencję do niego) trzymaj jednocześnie w 
Liście i Mapie.

 > mentalnie pożegnałem się z inteligentnym put(T) i będzie put(String,T)

To możesz załatwić wzorcem strategii, tzn dodatkowy obiekt (może być 
singleton czy statyczne klasa), który dostaje obiekt T i zwraca string 
który będzie kluczem mapy.
Strategia może być jako typ generyka (ListMap<T, 	, Strategy>).


-- 
Arivald

W dniu 2012-05-05 11:15, Arivald pisze:
> W dniu 2012-05-05 10:50, Jacek Czerwinski pisze:

> Utwórz nowy obiekt, implementujący Map<String, T> i List<T>. Wewnątrz
> umieść prywatne Map i List, dowolnych typów (np HashMap i LinkedList).
> Eclipse Ci wygeneruje listę metod do zaimplementowania, po prostu
> wydeleguj implementację do Mapy i Listy, pilnując wewnętrznych zależności.
>
> Po prostu ten sam obiekt (referencję do niego) trzymaj jednocześnie w
> Liście i Mapie.

Idę tą ścieżką (akurat odziedziczyłem po (Hash)Map z pewnych względów, 
również mniejsza ilośc metod do zaimplementowania). List siedzi w 
środku i referencje trzymam 2x.
Wchodząc w las, zaczyna lekko przeszkadzać, dwa odpowiedniki np. 'put' 
itd. Rzecz w tym, że zewnętrzny interface jaki implementuje byłby nieco 
nadmiarowy. Więc Zewnętrznie nie trzymam interfejsu List, jedyne co mam 
podobne to
putAt(int pos, String key, T y)

być może przyjdzie potrzeba na toArray i podobne metody listowe, ale na 
razie nie.

>
>  > mentalnie pożegnałem się z inteligentnym put(T) i będzie put(String,T)
>
> To możesz załatwić wzorcem strategii, tzn dodatkowy obiekt (może być
> singleton czy statyczne klasa), który dostaje obiekt T i zwraca string
> który będzie kluczem mapy.
> Strategia może być jako typ generyka (ListMap<T, , Strategy>).
Na pewno jakaś wskazówka, ale na przyszłość.

Szkoda, że w czystej javie nie można podać "pola" (jako ktoś kibicował 
JPA2 Criteria to wie)

W dniu 2012-05-05 11:36, Jacek Czerwinski pisze:
> W dniu 2012-05-05 11:15, Arivald pisze:
>> W dniu 2012-05-05 10:50, Jacek Czerwinski pisze:
>
>> Utwórz nowy obiekt, implementujący Map<String, T> i List<T>. Wewnątrz
>> umieść prywatne Map i List, dowolnych typów (np HashMap i LinkedList).
>> Eclipse Ci wygeneruje listę metod do zaimplementowania, po prostu
>> wydeleguj implementację do Mapy i Listy, pilnując wewnętrznych
>> zależności.
>>
>> Po prostu ten sam obiekt (referencję do niego) trzymaj jednocześnie w
>> Liście i Mapie.
>
> Idę tą ścieżką (akurat odziedziczyłem po (Hash)Map z pewnych względów,
> również mniejsza ilośc metod do zaimplementowania).

Nie, robisz inaczej. W mojej metodzie nie musisz mieć pełnej 
funkcjonalności Mapy, a w szczególności nie musi to być HashMapa. 
Odpowiednia wersja konstruktora pozwoli nawet na dobranie typów mapy i 
listy do konkretnego zastosowania.

-- 
Arivald

On Sat, 05 May 2012 09:27:43 +0200, Jacek Czerwinski <x@y.z.pl> wrote:

>Czy jest w bibliotekach z kolekcjami takie "coś" co pozwala:
>a) dodawać obiekty na sposób Listy/Vectora na końcu lub ze świadomym 
>rozpychaniem i odczytywać po indeksie int.
>b) zarazem żeby były dostępne jako Map<String,T>.
>Pewnie w konsekwencji b) dodawane obiekty by musiały by mieć pewien 
>wyróżnik, klucz żeby się mogły 'przedstawić'. Więc mają, tylko pojemnik 
>musi o tym wiedzieć.
>
>Gdyby oprzeć to o Map, dostęp po indeksie by musiał być w kolejności 
>dodawania (więc nie hash, alfabetycznie itd) plus mozliwość rozsuwania.
>
>Pewnie że da się to napisać, tylko po co.
>
>
>W C# mam kilka API gdzie elementy są dostępne z tablicy [int] i [string] 
>jednocześnie, i bardzo mi się podoba. Operatora tablicowego oczywiście w 
>Javie nie przeskoczę.
>
>
>

Nie wiem o co ci chodzi, ale sprawdz

http://commons.apache.org/collections/api-release/index.html

konkretnie ListOrderedMap. Moze to to?..

A.L.

W dniu 2012-05-06 00:22, A.L. pisze:
> On Sat, 05 May 2012 09:27:43 +0200, Jacek Czerwinski<x@y.z.pl>  wrote:
>

> Nie wiem o co ci chodzi, ale sprawdz
>
> http://commons.apache.org/collections/api-release/index.html
>
> konkretnie ListOrderedMap. Moze to to?..

Ideał ... by był, jakby używali literki T
:P

Sporo jest fajnego kodu, które jednak się zestarzał.