🚀 go-pugleaf

W dniu 2011-06-04 15:12, Jacek Czerwinski pisze:
> enum implementuje niebanalny interfejs.
>
> Z tego wspólnego pnia takich enumów jest więcej.
>
> Jak zrobić, aby 95% implementacji metod nie kopiować?
> Wymyśliłem wywoływanie kilku metod static Interfejsu, opłaca się gdy
> chodzi o objętościowo duże metody.

Może tak?
public enum Enum1{
	A,
	B;
	
	private Enum1Impl impl;
	Enum1(){
		this.impl = new Enum1Impl();
	}
	public Enum1Impl get(){
		return impl;
	}
	
	class Enum1Impl extends BaseEnumImpl{
		public int getOrdinalSqr(){
			return Enum1.this.ordinal() * Enum1.this.ordinal();
		}
	}
}

class BaseEnumImpl{
	public void someMethod(){}
}

Enum1.A.get().someMethod();
Enum1.A.get().getOrdinalSqr();

-- 
pozdrawiam
Marcin Biegan

On 06/04/2011 03:12 PM, Jacek Czerwinski wrote:
> enum implementuje niebanalny interfejs.
>
> Z tego wspólnego pnia takich enumów jest więcej.
>
> Jak zrobić, aby 95% implementacji metod nie kopiować?
> Wymyśliłem wywoływanie kilku metod static Interfejsu, opłaca się gdy
> chodzi o objętościowo duże metody.

Najlepsze rozwiązanie to po prostu nie używać enumów gdy mamy do 
czynienia z niebanalnym interfejsem. Enumy powinny być możliwie proste, 
więc gdy pojawia się w nich zbyt dużo logiki, to ewidentny "code smell".

Pozdrawiam,
Adam

W dniu 2011-06-04 16:27, Marcin Biegan pisze:
> W dniu 2011-06-04 15:12, Jacek Czerwinski pisze:
>> enum implementuje niebanalny interfejs.
>>
...
>
> class Enum1Impl extends BaseEnumImpl{
> public int getOrdinalSqr(){
> return Enum1.this.ordinal() * Enum1.this.ordinal();
> }
> }
> }
>
> class BaseEnumImpl{
> public void someMethod(){}
> }
>
> Enum1.A.get().someMethod();
> Enum1.A.get().getOrdinalSqr();
>

Dzięki, ale na zwykłych klasach mój DSL wygląda przyjemniej, a o to 
chodzi. Można powiedzieć, jesli ktoś 'wierzy' w istnienie takiego 
wzorca, więc wzorzec enuma sprzez Javy 5.
Wbudowany enum ma bardzo duży power, ale i twarde granice swoich możliwości.

od kilku dni bawię się trickem
new Throwable() bez throw i stack trace
co mi załatwi 1-2 brzydkie parametry jakie musiał podawać tworzący kod 
'aplikacyjny'.

W dniu 2011-06-05 19:36, Adam Byrtek pisze:
> On 06/04/2011 03:12 PM, Jacek Czerwinski wrote:
>> enum implementuje niebanalny interfejs.
>>
>> Z tego wspólnego pnia takich enumów jest więcej.
>>
>> Jak zrobić, aby 95% implementacji metod nie kopiować?
>> Wymyśliłem wywoływanie kilku metod static Interfejsu, opłaca się gdy
>> chodzi o objętościowo duże metody.
>
> Najlepsze rozwiązanie to po prostu nie używać enumów gdy mamy do
> czynienia z niebanalnym interfejsem. Enumy powinny być możliwie proste,
> więc gdy pojawia się w nich zbyt dużo logiki, to ewidentny "code smell".

W jakimś sensie się zgadzam.
Założyłem sobie że  użycie enuma ma być (bardzo) proste, być może 
realizując ambitny ukryty 'backend'. Wizja taka, że z fragmentami 
stosującymi gotowego enuma by miał się stykać ledwo przeszkolony z MS 
Basiców programista-wdrożeniowiec.

Jacek Czerwinski wrote:

> enum implementuje niebanalny interfejs.

Jaki enum?
Jakichs enum, ktory chcesz stworzyc?

> 
> Z tego wspólnego pnia takich enumów jest więcej.

Jakiego znowu pnia?

> 
> Jak zrobić, aby 95% implementacji metod nie kopiować?

Interfejs nie posiada implementacji.

> Wymyśliłem wywoływanie kilku metod static Interfejsu, 

Interfejs nie moze posiadac metod statycznych.

> opłaca się gdy
> chodzi o objętościowo duże metody.
> 

Dlaczego?


Chłopie - wez naucz sie precyzyjnie wyrazac mysli, bo czytam powyzsze raz za 
razem i sensu w tym nie ma. To taki problem przestac uzywac skrotow 
myslowych, ktore tylko ty rozumiesz?

Nic dziwnego, ze "agile" taka popularnosc zdobywa - inzynieria schodzi na 
psy, jesli w ogole jeszcze istnieje...

> Pytania dodatkowe:
> Nie jest chyba w Javie możliwy enum (wewnętrzny dla klasy) bez nazwy?
> enum w enumie też się nie da?

Do dokumentacji nie laska zajrzec?
Albo moze przynajmniej sprobowac w jakims IDE - to zajmie nie wiecej niz 
30s.

-- 
Michal

On 06/06/2011 02:45 PM, Michal Kleczek wrote:
> Nic dziwnego, ze "agile" taka popularnosc zdobywa - inzynieria schodzi na
> psy, jesli w ogole jeszcze istnieje...

Tutaj z kolei ja sensu nie widzę. Może rozwiniesz te skróty myślowe? 
(Najlepiej w osobnym wątku.)

Pozdrawiam,
Adam

On 5 Cze, 19:36, Adam Byrtek <adambyr...@gmail.com> wrote:
> On 06/04/2011 03:12 PM, Jacek Czerwinski wrote:
>

> Najlepsze rozwiązanie to po prostu nie używać enumów gdy mamy do
> czynienia z niebanalnym interfejsem. Enumy powinny być możliwie proste,
> więc gdy pojawia się w nich zbyt dużo logiki, to ewidentny "code smell".


Znalazlem co ciekawego, niby po enumie bylem przekonany, nie mozna
dziedziczyc (na sposob nazwany, ale anonimowy to owszem):


public enum Operation {
  PLUS   { double eval(double x, double y) { return x + y; } },
  MINUS  { double eval(double x, double y) { return x - y; } },
  TIMES  { double eval(double x, double y) { return x * y; } },
  DIVIDE { double eval(double x, double y) { return x / y; } };

  // Do arithmetic op represented by this constant
  abstract double eval(double x, double y);
}

http://download.oracle.com/javase/1,5.0/docs/guide/language/enums.html

I chyba to wykorzystam.