🚀 go-pugleaf

W dniu 2013-12-12 12:00, Jadalbert pisze:
> Jak to właściwie jest. Mam klasę abstrakcyjną (dodam, że rzecz ma się dziać w jsf - co to zmienia, nie wiem)
>

public interface FiguraZPolem {
      public double getPole()
}

> public abstract class Figura implements FiguraZPolem {
> 	public Figura(){}
>
> 	private double pole;
>
         @Override
> 	public double getPole() {
> 		return pole;
> 	}
> }
>
> i klasę
>

public interface FiguraZObwodem {
      public double getObwod()
}

> public class Kolo extends Figura implements FiguraZObwodem {
> 	public Kolo(){}
>
> 	private double obwod;
>
         @Override
> 	public double getObwod() {
> 		return obwod;
> 	}
> }
>
> i teraz:
> public class Licz {
> 	private Figura figura;
> 	private double PoleObwod;
>
> 	public Licz() {}
>
> 	public Licz(Figura figura) {
> 		this.figura = figura;
> 	}
>
> 	public double getPoleObwod() {
		if (!figura instanceof FiguraZObwodem)
                      throw new InvalidParameterException("oczekiwano 
FiguraZObwodem");
		if (!figura instanceof FiguraZPolem )
                      throw new InvalidParameterException("oczekiwano 
FiguraZPolem ");

> 		return ((FiguraZPolem ) figura).getPole() * ((FiguraZObwodem) figura).getObwod();
> // i tu oczywiście błąd bo obwodu nie ma w klasie Figura !
> 	}
> }
>
> w "realu" będzie więcej klas jak Kolo i każda nie dość, że będzie pokrywała metody klasy bazowej to jeszcze będzie miała własne, dodatkowe. I skąd wziąć wiedzę, jakiej klasy jest to co przychodzi w konstruktorze?
>

Po za tym Figura tez może być interfejsem, pustym. Da ci to możliwość 
posiadanie kilku hierarchii dziedziczenia figur.

-- 
Arivald

Dzięki.
Tak też usiłowałem myśleć ale liczyłem na to, że uda się uniknąć mnożenia interfejsów. Widać nie uda się.

Jadalbert

Jadalbert pisze:

> public abstract class Figura {

> public class Kolo extends Figura {

> i teraz:
> public class Licz {
> 	private Figura figura;
> 	private double PoleObwod;
>
> 	public Licz() {}
>
> 	public Licz(Figura figura) {
> 		this.figura = figura;
> 	}
>
> 	public double getPoleObwod() {
> 		return figura.getPole() * figura.getObwod();
> // i tu oczywiście błąd bo obwodu nie ma w klasie Figura !

Zacząłbym od uporządkowania klas. Czyli najwyższa klasa: Figura, z nie 
dziedziczy Krzywa, Powierzchnia, Bryła.
Krzywa ma właściwość Obwód
Powierzchnia ma właściwość Pole
Bryła ma właściwość Objętość

Koło, Elipsa, Czworokąt,... dziedziczą z powierzchni
Okrąg dziedziczy z Krzywej.
*ścian dziedziczy z Bryły.

Klasa Licz nie powinna otrzymywać figury przez konstruktor, gdyż 
oznaczałoby to że przy każdym liczeniu musisz wołać konstruktor a to 
kosztuje. Klasa Licz powinna być klasą Utility ze statycznymi metodami, np.


public class Licz {

static public Double getPole( Powierzchnia powierzchnia ) {
...
	return pole;
}

}




-- 
pozdrawiam
Piotr
XLR250&bmw_f650_dakar

Generalnie zgodzę się ze wszystkim co napisałeś, poza tymi statycznymi metodami. Taka klasa będzie bezstanowa, możemy ją więc traktować jako singleton (najlepiej w jakimś kontenerze IoC) z instancyjnymi metodami. Wtedy zawsze łatwiej coś takiego podmienić w testach (nie wszystkie stubery sobie radzą ze statycznymi metodami)

W dniu czwartek, 12 grudnia 2013 21:51:11 UTC+1 użytkownik Piotr Rezmer napisał:
> Jadalbert pisze:
> 
> 
> 
> > public abstract class Figura {
> 
> 
> 
> > public class Kolo extends Figura {
> 
> 
> 
> > i teraz:
> 
> > public class Licz {
> 
> > 	private Figura figura;
> 
> > 	private double PoleObwod;
> 
> >
> 
> > 	public Licz() {}
> 
> >
> 
> > 	public Licz(Figura figura) {
> 
> > 		this.figura = figura;
> 
> > 	}
> 
> >
> 
> > 	public double getPoleObwod() {
> 
> > 		return figura.getPole() * figura.getObwod();
> 
> > // i tu oczywi�cie b��d bo obwodu nie ma w klasie Figura !
> 
> 
> 
> Zacz��bym od uporz�dkowania klas. Czyli najwy�sza klasa: Figura, z nie 
> 
> dziedziczy Krzywa, Powierzchnia, Bry�a.
> 
> Krzywa ma w�a�ciwo�� Obw�d
> 
> Powierzchnia ma w�a�ciwo�� Pole
> 
> Bry�a ma w�a�ciwo�� Obj�to��
> 
> 
> 
> Ko�o, Elipsa, Czworok�t,... dziedzicz� z powierzchni
> 
> Okr�g dziedziczy z Krzywej.
> 
> *�cian dziedziczy z Bry�y.
> 
> 
> 
> Klasa Licz nie powinna otrzymywaďż˝ figury przez konstruktor, gdyďż˝ 
> 
> oznacza�oby to �e przy ka�dym liczeniu musisz wo�a� konstruktor a to 
> 
> kosztuje. Klasa Licz powinna byďż˝ klasďż˝ Utility ze statycznymi metodami, np.
> 
> 
> 
> 
> 
> public class Licz {
> 
> 
> 
> static public Double getPole( Powierzchnia powierzchnia ) {
> 
> ...
> 
> 	return pole;
> 
> }
> 
> 
> 
> }
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> pozdrawiam
> 
> Piotr
> 
> XLR250&bmw_f650_dakar

On Thu, 12 Dec 2013 03:00:35 -0800 (PST), Jadalbert
<jadalbert.wincent@gmail.com> wrote:

>Jak to właściwie jest. Mam klasę abstrakcyjną (dodam, że rzecz ma się dziać w jsf - co to zmienia, nie wiem)
>
>public abstract class Figura {
>	public Figura(){}
>
>	private double pole;
>
>	public double getPole() {
>		return pole;
>	}
>}
>
>i klasę
>
>public class Kolo extends Figura {
>	public Kolo(){}
>
>	private double obwod;
>
>	public double getObwod() {
>		return obwod;
>	}
>}
>
>i teraz:
>public class Licz {
>	private Figura figura;
>	private double PoleObwod;
>
>	public Licz() {}
>
>	public Licz(Figura figura) {
>		this.figura = figura;
>	}
>
>	public double getPoleObwod() {
>		return figura.getPole() * figura.getObwod();
>// i tu oczywiście błąd bo obwodu nie ma w klasie Figura !
>	}
>}
>
>w "realu" będzie więcej klas jak Kolo i każda nie dość, że będzie pokrywała metody klasy bazowej to jeszcze będzie miała własne, dodatkowe. I skąd wziąć wiedzę, jakiej klasy jest to co przychodzi w konstruktorze

Dzizus Krajst, ale belkot... Czy oni tego teraz w szkole nie ucza?...

A.L.

>
> Dzizus Krajst, ale belkot... Czy oni tego teraz w szkole nie ucza?...
>
> A.L.
>
Nie wiem czy tego w szkole uczą. Ja nie chodzę do szkoły tylko się uczę 
javy. Jako osoba ucząca się, a nie znawca tematu, mam prawo do zadawania 
pytań, które Tobie, znawcy, wydają się głupawe i napisane bełkotliwie. 
Inni jakoś ścierpieli moje pytanie i udzielili mi rad. Dzięki nim 
bardziej zrozumiałem problem. Czy coś w tym jest dziwnego lub drażniącego?

W dniu 2013-12-12 13:47, Jadalbert pisze:
> Dzięki.
> Tak też usiłowałem myśleć ale liczyłem na to, że uda się uniknąć mnożenia interfejsów. Widać nie uda się.
>
> Jadalbert
>

Nie "mnożenia".
Po prostu interfejs opisuje jakąś powtarzalną funkcjonalność, a potem 
rzeczywiste obiekty implementują tą funkcjonalność.

Tu akurat uparłeś się żeby obwód i pole były rozłączne, dlatego dwa 
interfejsy.

-- 
Arivald

On Fri, 13 Dec 2013 21:06:12 +0100, Jadalbert <maxorin@poczta.onet.pl>
wrote:

>>
>> Dzizus Krajst, ale belkot... Czy oni tego teraz w szkole nie ucza?...
>>
>> A.L.
>>
>Nie wiem czy tego w szkole uczą. Ja nie chodzę do szkoły tylko się uczę 
>javy. Jako osoba ucząca się, a nie znawca tematu, mam prawo do zadawania 
>pytań, które Tobie, znawcy, wydają się głupawe i napisane bełkotliwie. 
>Inni jakoś ścierpieli moje pytanie i udzielili mi rad. Dzięki nim 
>bardziej zrozumiałem problem. Czy coś w tym jest dziwnego lub drażniącego?

Acha. Postaram sie napisac w weekend

A.L.

On Fri, 13 Dec 2013 17:00:39 -0600, A.L. <alewando@aol.com> wrote:
> Acha. Postaram sie napisac w weekend

Och, aha. Nie "acha".

Dzizas krajst, czy tego teraz w szkołach nie uczą? ;-)

RW

On Sun, 15 Dec 2013 07:07:44 +0000, Roman W
<bloody_rabbitREMOVETHIS@gazeta.pl> wrote:

>On Fri, 13 Dec 2013 17:00:39 -0600, A.L. <alewando@aol.com> wrote:
>> Acha. Postaram sie napisac w weekend
>
>Och, aha. Nie "acha".
>
>Dzizas krajst, czy tego teraz w szkołach nie uczą? ;-)
>
>RW

Jakos mi sie odechcialo odpisywac...

A.L.

W dniu 2013-12-12 12:00, Jadalbert pisze:
> Jak to właściwie jest. Mam klasę abstrakcyjną (dodam, że rzecz ma się dziać w jsf - co to zmienia, nie wiem)
>
> public abstract class Figura {
> 	public Figura(){}
>
> 	private double pole;
>
> 	public double getPole() {
> 		return pole;
> 	}
> }
>
> i klasę
>
> public class Kolo extends Figura {
> 	public Kolo(){}
>
> 	private double obwod;
>
> 	public double getObwod() {
> 		return obwod;
> 	}
> }
>
> i teraz:
> public class Licz {
> 	private Figura figura;
> 	private double PoleObwod;
>
> 	public Licz() {}
>
> 	public Licz(Figura figura) {
> 		this.figura = figura;
> 	}
>
> 	public double getPoleObwod() {
> 		return figura.getPole() * figura.getObwod();
> // i tu oczywiście błąd bo obwodu nie ma w klasie Figura !
> 	}
> }
>
> w "realu" będzie więcej klas jak Kolo i każda nie dość, że będzie pokrywała metody klasy bazowej to jeszcze będzie miała własne, dodatkowe. I skąd wziąć wiedzę, jakiej klasy jest to co przychodzi w konstruktorze?
>

Moze po prostu:

public class Licz {
   private Kolo figura;
   public Licz(Kolo figura) {
     this.figura = figura;
   }
...
}

--
Michal

On Tue, 17 Dec 2013 10:08:14 +0100, Michal Kleczek
<michal_wytnijto@kleczek.org> wrote:
   
>Moze po prostu:
>
>public class Licz {
>   private Kolo figura;
>   public Licz(Kolo figura) {
>     this.figura = figura;
>   }
>...
>}


Za klase class ZrobCosTam

po prostu wyrzucam studenta za drzwi. A hukiem

A.L.

Dnia 17-12-2013 o 23:42:56 A.L. <alewando@aol.com> napisał(a):

> Za klase class ZrobCosTam
>
> po prostu wyrzucam studenta za drzwi. A hukiem

Gratuluję nieznajomości wzorca Command.

-- 
Boguś
/Każdy skutek ma swoją przyczynę/

On Tue, 24 Dec 2013 01:54:00 +0100, Bogus?aw Szczepanowski
<noone@invalid.net> wrote:

>Dnia 17-12-2013 o 23:42:56 A.L. <alewando@aol.com> napisał(a):
>
>> Za klase class ZrobCosTam
>>
>> po prostu wyrzucam studenta za drzwi. A hukiem
>
>Gratuluję nieznajomości wzorca Command.

Wzorzec Command ma komponenty/klasy

Command
Invoker
ConcreteCommand
Receiver
Action

Nie ma klasy ZrobCosTam.  Albowiem KLASA to OBIEKT a nie CZYNNOSC.
Klasa to abstrakcja KONCEPTU albo RZECZY ISTNIEJACEJ FIZYCZNIE,a  nei
CZYNNOSCI.

CZYNNOSC to czesc zachowanai (protokolu) klasy.

Proponuje Koledze wziac jakis prosty podrecznik do UML czy do Object
Oriented Design  i przekonac sie czym jest KLASA i OBIEKT w
programowaniu obiektowym

A.L.

W dniu 2013-12-26 04:04, A.L. pisze:
> On Tue, 24 Dec 2013 01:54:00 +0100, Bogus?aw Szczepanowski
> <noone@invalid.net> wrote:
>
>> Dnia 17-12-2013 o 23:42:56 A.L. <alewando@aol.com> napisał(a):
>>
>>> Za klase class ZrobCosTam
>>>
>>> po prostu wyrzucam studenta za drzwi. A hukiem
>>
>> Gratuluję nieznajomości wzorca Command.
>
> Wzorzec Command ma komponenty/klasy
>
> Command
> Invoker
> ConcreteCommand
> Receiver
> Action
>
> Nie ma klasy ZrobCosTam.  Albowiem KLASA to OBIEKT a nie CZYNNOSC.
> Klasa to abstrakcja KONCEPTU albo RZECZY ISTNIEJACEJ FIZYCZNIE,a  nei
> CZYNNOSCI.

Generalnie tak. Ale nie widzę przeszkód żeby mieć klasę opisującą 
czynność. Zresztą właśnie Command jest czynnością.

>
> CZYNNOSC to czesc zachowanai (protokolu) klasy.
>
> Proponuje Koledze wziac jakis prosty podrecznik do UML czy do Object
> Oriented Design  i przekonac sie czym jest KLASA i OBIEKT w
> programowaniu obiektowym
>
> A.L.
>

Ale to nie wyjaśnia dlaczego konkretna klasa implementująca Command nie 
mogła by się nazywać ZrobCosTam.

W aplikacji związanej z grafiką miałem wszystkie Command w paczce 
xx.commands, a ich nazwy to Move, Rotate, SetScale, itd.


Inny przykład na klasę ZrobCosTam : w Androidzie mam takie klasy które 
przyjmują na wejściu obiekt z parametrami/danymi, odpalają wątek z puli 
i próbują przetwarzać te dane w oparciu o webservice. I mają właśnie 
takie nazwy: SaveSomething, GetSomething, etc. żeby wykonać akcję tworzę 
nową instancję takiej klasy.

Powiesz że mógł bym to robić w jednym obiekcie, wołając jego funkcje 
saveSomething() etc. Mógłbym, ale i tak pod spodem musiał bym tworzyć 
obiekty trzymające aktualny stan, progress operacji. Więc naprawdę nie 
widzę sensu wprowadzać jeszcze jednego pośrednika.

-- 
Arivald

On Thu, 26 Dec 2013 09:55:57 +0100, Arivald <NOSPAMarivald@interia.pl>
wrote:
 
>Generalnie tak. Ale nie widzę przeszkód żeby mieć klasę opisującą 
>czynność. Zresztą właśnie Command jest czynnością.
>

Generalnie nei widze powodu zeby nie mozna miec. Tak samo jek nei
widze powodow aby nie mozna bylo pierdzec publicznie na przyjeciu
swiatecznym u Cioci Kloci i dlubac publicznei w nosie.

Dowolny jezyk jest roznei rozciagliwy jak zuzyta prezerwatywa i mozna
go rozciagac do woli. Ale na ogol , wsrod wielu mozliwych sposobow
zrobienia czegos, jest kilka aledwie ktore sa prawidlowe.

>>
>> CZYNNOSC to czesc zachowanai (protokolu) klasy.
>>
>> Proponuje Koledze wziac jakis prosty podrecznik do UML czy do Object
>> Oriented Design  i przekonac sie czym jest KLASA i OBIEKT w
>> programowaniu obiektowym
>>
>> A.L.
>>
>
>Ale to nie wyjaśnia dlaczego konkretna klasa implementująca Command nie 
>mogła by się nazywać ZrobCosTam.
>

No mogla by. Juz wyjasnilem wyzej. Podobnei jak mzoes pierdziec
publicznie na raucie dyplomatycznym. Podobnie jak w dowolnym jezyku
mozesz programowac jak chcesz. Ale jest drobne rozroznienie miedzy
PROGRAMWOANIEM OBIEKTOWYM a PROGRAMWOANIEM W JAVE. Nie kazde
programwoanie w Javie jest programowaniem obiektowym, nawet jezeli
uzywa sie klasy (zreszta, w Jave nie da sie nie uzywac klas).


>W aplikacji związanej z grafiką miałem wszystkie Command w paczce 
>xx.commands, a ich nazwy to Move, Rotate, SetScale, itd.
>
>
>Inny przykład na klasę ZrobCosTam : w Androidzie mam takie klasy które 
>przyjmują na wejściu obiekt z parametrami/danymi, odpalają wątek z puli 
>i próbują przetwarzać te dane w oparciu o webservice. I mają właśnie 
>takie nazwy: SaveSomething, GetSomething, etc. żeby wykonać akcję tworzę 
>nową instancję takiej klasy.
>
>Powiesz że mógł bym to robić w jednym obiekcie, wołając jego funkcje 
>saveSomething() etc. Mógłbym, ale i tak pod spodem musiał bym tworzyć 
>obiekty trzymające aktualny stan, progress operacji. Więc naprawdę nie 
>widzę sensu wprowadzać jeszcze jednego pośrednika.

To dla ciebei widac tak jest. Niestety, z programwoaniem obiektowym
jest tak jak z internetem: trafil pod strzechy. Dla wiekszosci ludzi
"programwoanei obiektowe" to programowanie w Javie. O tym ze jset cos
takiego jak PROJEKTOWANIE OBIEKTOWE i ANALIZA OBIEKTOWA, malo kto,
niestety, wie. Zwlaszcza wsrod mlodych  "miszcow informatyki" ktorzy
ucza sie ze "programowanie obiektowe to programowanie w Javie". czy
C++.  O tym ze pewne rzeczy robi sie w okreslony sposob, i dlaczego
sie tak robi, malo kto wie.

Ale coz wymagac, skoro nawer znakomity MIMUW pod haslem "Programowanie
Obiektowe" przemyca programowanie w Javie, w ktorym to programowaniu
obiektowym, jak to wynika z wykladu, najwazniejsze sa wyjatki

A.L.

P.S. Jak pisalem wyzej, wyrzucam za dzrwi studenta ktory przyniesie mi
klase ZrobCosTam. I bede wyrzucal poki mi sil starczy, albo studenci
zrozumieja o co chodzi. A co sobie "miszczowie" pod Androidem robia,
malo mnie interesuje

P.S. Caly watek wzial sie z "zagadnienia polimorfizmu" i ewidentnie
wyrosl na gruncie programwoanie obiektowego. Wiec neich moze
zwolennicy klas ZrobCosYam zaloza sobie nowy watek. Pod tytulem
"Zagdanienei badziewia" na przykald

W dniu 26.12.2013 17:02, A.L. pisze:
> On Thu, 26 Dec 2013 09:55:57 +0100, Arivald <NOSPAMarivald@interia.pl>
> wrote:
>
>> Generalnie tak. Ale nie widzę przeszkód żeby mieć klasę opisującą
>> czynność. Zresztą właśnie Command jest czynnością.
>>
>
> Generalnie nei widze powodu zeby nie mozna miec. Tak samo jek nei
> widze powodow aby nie mozna bylo pierdzec publicznie na przyjeciu
> swiatecznym u Cioci Kloci i dlubac publicznei w nosie.
>

Fajny język PANIE WYKSZTAŁCONY WYKŁADOWCO... :)

> Dowolny jezyk jest roznei rozciagliwy jak zuzyta prezerwatywa i mozna
> go rozciagac do woli. Ale na ogol , wsrod wielu mozliwych sposobow
> zrobienia czegos, jest kilka aledwie ktore sa prawidlowe.
>

Dalszy wywód błyskotliwej myśli...

>>>
>>> CZYNNOSC to czesc zachowanai (protokolu) klasy.
>>>
>>> Proponuje Koledze wziac jakis prosty podrecznik do UML czy do Object
>>> Oriented Design  i przekonac sie czym jest KLASA i OBIEKT w
>>> programowaniu obiektowym
>>>
>>> A.L.
>>>
>>
>> Ale to nie wyjaśnia dlaczego konkretna klasa implementująca Command nie
>> mogła by się nazywać ZrobCosTam.
>>
>
> No mogla by. Juz wyjasnilem wyzej. Podobnei jak mzoes pierdziec
> publicznie na raucie dyplomatycznym. Podobnie jak w dowolnym jezyku
> mozesz programowac jak chcesz. Ale jest drobne rozroznienie miedzy
> PROGRAMWOANIEM OBIEKTOWYM a PROGRAMWOANIEM W JAVE. Nie kazde
> programwoanie w Javie jest programowaniem obiektowym, nawet jezeli
> uzywa sie klasy (zreszta, w Jave nie da sie nie uzywac klas).

Pokaż choć jedną regułkę ze swoich książeczek na pułkach których masz 
podejrzewam jako "MĄDRY WYKŁADOWCA" możesz podać tytuły i stronę chętnie 
poczytam bo to co opisałeś to jedyne o czym świadczy to brak kultury

>
>
>> W aplikacji związanej z grafiką miałem wszystkie Command w paczce
>> xx.commands, a ich nazwy to Move, Rotate, SetScale, itd.
>>
>>
>> Inny przykład na klasę ZrobCosTam : w Androidzie mam takie klasy które
>> przyjmują na wejściu obiekt z parametrami/danymi, odpalają wątek z puli
>> i próbują przetwarzać te dane w oparciu o webservice. I mają właśnie
>> takie nazwy: SaveSomething, GetSomething, etc. żeby wykonać akcję tworzę
>> nową instancję takiej klasy.
>>
>> Powiesz że mógł bym to robić w jednym obiekcie, wołając jego funkcje
>> saveSomething() etc. Mógłbym, ale i tak pod spodem musiał bym tworzyć
>> obiekty trzymające aktualny stan, progress operacji. Więc naprawdę nie
>> widzę sensu wprowadzać jeszcze jednego pośrednika.
>
> To dla ciebei widac tak jest. Niestety, z programwoaniem obiektowym
> jest tak jak z internetem: trafil pod strzechy. Dla wiekszosci ludzi
> "programwoanei obiektowe" to programowanie w Javie. O tym ze jset cos
> takiego jak PROJEKTOWANIE OBIEKTOWE i ANALIZA OBIEKTOWA, malo kto,
> niestety, wie. Zwlaszcza wsrod mlodych  "miszcow informatyki" ktorzy
> ucza sie ze "programowanie obiektowe to programowanie w Javie". czy
> C++.  O tym ze pewne rzeczy robi sie w okreslony sposob, i dlaczego
> sie tak robi, malo kto wie.
>

Pan INTELIGENT :) któremu ów słoma z tych strzech się sypała i trafiła 
do butów :) Zapomniał jej wygrzebać jak dostał się na uczelnie:)

Pomyliłeś kolego wzorce projektowe z analizą obiektową, fakt powiązane 
ale napewno analiza obiektowa nie określa co się robi w jaki sposób to 
określają wzorce. Proszę sobie poczytać w swoich mądrych książkach,

> Ale coz wymagac, skoro nawer znakomity MIMUW pod haslem "Programowanie
> Obiektowe" przemyca programowanie w Javie, w ktorym to programowaniu
> obiektowym, jak to wynika z wykladu, najwazniejsze sa wyjatki
>
> A.L.
>
> P.S. Jak pisalem wyzej, wyrzucam za dzrwi studenta ktory przyniesie mi
> klase ZrobCosTam. I bede wyrzucal poki mi sil starczy, albo studenci
> zrozumieja o co chodzi. A co sobie "miszczowie" pod Androidem robia,
> malo mnie interesuje

Tak jak napisałem pokaż to gdzieś, bo wymysły mnie nie interesują :)

Pozdrawiam

W dniu 2013-12-26 17:02, A.L. pisze:
> On Thu, 26 Dec 2013 09:55:57 +0100, Arivald <NOSPAMarivald@interia.pl>
> wrote:
>
>> Generalnie tak. Ale nie widzę przeszkód żeby mieć klasę opisującą
>> czynność. Zresztą właśnie Command jest czynnością.
>>
>
> Generalnie nei widze powodu zeby nie mozna miec. Tak samo jek nei
> widze powodow aby nie mozna bylo pierdzec publicznie na przyjeciu
> swiatecznym u Cioci Kloci i dlubac publicznei w nosie.
>
> Dowolny jezyk jest roznei rozciagliwy jak zuzyta prezerwatywa i mozna
> go rozciagac do woli. Ale na ogol , wsrod wielu mozliwych sposobow
> zrobienia czegos, jest kilka aledwie ktore sa prawidlowe.
>

Widzę że dyskusja na poziomie...

>>>
>>> CZYNNOSC to czesc zachowanai (protokolu) klasy.
>>>
>>> Proponuje Koledze wziac jakis prosty podrecznik do UML czy do Object
>>> Oriented Design  i przekonac sie czym jest KLASA i OBIEKT w
>>> programowaniu obiektowym
>>>
>>> A.L.
>>>
>>
>> Ale to nie wyjaśnia dlaczego konkretna klasa implementująca Command nie
>> mogła by się nazywać ZrobCosTam.
>>
>
> No mogla by. Juz wyjasnilem wyzej. Podobnei jak mzoes pierdziec
> publicznie na raucie dyplomatycznym. Podobnie jak w dowolnym jezyku
> mozesz programowac jak chcesz. Ale jest drobne rozroznienie miedzy
> PROGRAMWOANIEM OBIEKTOWYM a PROGRAMWOANIEM W JAVE. Nie kazde
> programwoanie w Javie jest programowaniem obiektowym, nawet jezeli
> uzywa sie klasy (zreszta, w Jave nie da sie nie uzywac klas).
>
>
>> W aplikacji związanej z grafiką miałem wszystkie Command w paczce
>> xx.commands, a ich nazwy to Move, Rotate, SetScale, itd.
>>
>>
>> Inny przykład na klasę ZrobCosTam : w Androidzie mam takie klasy które
>> przyjmują na wejściu obiekt z parametrami/danymi, odpalają wątek z puli
>> i próbują przetwarzać te dane w oparciu o webservice. I mają właśnie
>> takie nazwy: SaveSomething, GetSomething, etc. żeby wykonać akcję tworzę
>> nową instancję takiej klasy.
>>
>> Powiesz że mógł bym to robić w jednym obiekcie, wołając jego funkcje
>> saveSomething() etc. Mógłbym, ale i tak pod spodem musiał bym tworzyć
>> obiekty trzymające aktualny stan, progress operacji. Więc naprawdę nie
>> widzę sensu wprowadzać jeszcze jednego pośrednika.
>
> To dla ciebei widac tak jest. Niestety, z programwoaniem obiektowym
> jest tak jak z internetem: trafil pod strzechy.

 > Dla wiekszosci ludzi "programwoanei obiektowe" to programowanie w Javie.

No wybacz, ale tu żeś strzelił babola... Dla jakiej większości? Dla 
większości ludzi samo programowanie to jest zajęcie bliskie magii ;-)

A założę się że i większość programistów nie utożsamia obiektowości z 
Javą. Zresztą w mojej opinii akurat Java jest jednym z najgorszych 
języków obiektowych. Szczególnie implementacja klas generycznych woła o 
pomstę do nieba.


> O tym ze jset cos
> takiego jak PROJEKTOWANIE OBIEKTOWE i ANALIZA OBIEKTOWA, malo kto,
> niestety, wie. Zwlaszcza wsrod mlodych  "miszcow informatyki" ktorzy
> ucza sie ze "programowanie obiektowe to programowanie w Javie". czy
> C++.  O tym ze pewne rzeczy robi sie w okreslony sposob, i dlaczego
> sie tak robi, malo kto wie.
>

A akurat C++ jest, w mojej opinii, jednym z najlepszych języków 
obiektowych. I chyba najtrudniejszym. Jest w nim coś o nazwie "funktor": 
klasa z przeciążonym operatorem wykonania "()". Mając instancję takiej 
klasy można ją po prostu wykonać jak każdą inną funkcję. Można ją użyć 
zamiast funkcji we wzorcach. Funktory są używane w STLu (standardowej 
bibliotece C++), np jako predykaty.

Taki funktor dokładnie i kompletnie przeczy Twojej teorii że obiekt nie 
może być czynnością.

A że w Javie się tak nie da? A kogo to obchodzi?


> P.S. Jak pisalem wyzej, wyrzucam za dzrwi studenta ktory przyniesie mi
> klase ZrobCosTam. I bede wyrzucal poki mi sil starczy, albo studenci
> zrozumieja o co chodzi.

No cóż, współczuję im. Jak się potem sami nie doszkolą, to będą 
poszkodowani przez całą ich karierę programisty. Co roku w firmie mamy 
odsiew takich z dobrymi stopniami, ale kompletnie nie umiejących 
programować absolwentów.


BTW widzę że dyskusja za bardzo nie ma sensu, a i poziom wypowiedzi 
zapikował w dół, tak że z mojej strony to EOT.

-- 
Arivald

On Wed, 25 Dec 2013 21:04:23 -0600, A.L. <alewando@aol.com> wrote:
> Wzorzec Command ma komponenty/klasy


> Command
> Invoker
> ConcreteCommand
> Receiver
> Action


> Nie ma klasy ZrobCosTam.  Albowiem KLASA to OBIEKT a nie CZYNNOSC.

"Action" to właśnie "Czynność".

RW

On Thu, 26 Dec 2013 18:11:30 +0100, J-23 <baczeklu@o2.pl> wrote:

>W dniu 26.12.2013 17:02, A.L. pisze:
>> On Thu, 26 Dec 2013 09:55:57 +0100, Arivald <NOSPAMarivald@interia.pl>
>> wrote:
>>
>>> Generalnie tak. Ale nie widzę przeszkód żeby mieć klasę opisującą
>>> czynność. Zresztą właśnie Command jest czynnością.
>>>
>>
>> Generalnie nei widze powodu zeby nie mozna miec. Tak samo jek nei
>> widze powodow aby nie mozna bylo pierdzec publicznie na przyjeciu
>> swiatecznym u Cioci Kloci i dlubac publicznei w nosie.
>>
>
>Fajny język PANIE WYKSZTAŁCONY WYKŁADOWCO... :)
>
>> Dowolny jezyk jest roznei rozciagliwy jak zuzyta prezerwatywa i mozna
>> go rozciagac do woli. Ale na ogol , wsrod wielu mozliwych sposobow
>> zrobienia czegos, jest kilka aledwie ktore sa prawidlowe.
>>
>
>Dalszy wywód błyskotliwej myśli...
>
>>>>
>>>> CZYNNOSC to czesc zachowanai (protokolu) klasy.
>>>>
>>>> Proponuje Koledze wziac jakis prosty podrecznik do UML czy do Object
>>>> Oriented Design  i przekonac sie czym jest KLASA i OBIEKT w
>>>> programowaniu obiektowym
>>>>
>>>> A.L.
>>>>
>>>
>>> Ale to nie wyjaśnia dlaczego konkretna klasa implementująca Command nie
>>> mogła by się nazywać ZrobCosTam.
>>>
>>
>> No mogla by. Juz wyjasnilem wyzej. Podobnei jak mzoes pierdziec
>> publicznie na raucie dyplomatycznym. Podobnie jak w dowolnym jezyku
>> mozesz programowac jak chcesz. Ale jest drobne rozroznienie miedzy
>> PROGRAMWOANIEM OBIEKTOWYM a PROGRAMWOANIEM W JAVE. Nie kazde
>> programwoanie w Javie jest programowaniem obiektowym, nawet jezeli
>> uzywa sie klasy (zreszta, w Jave nie da sie nie uzywac klas).
>
>Pokaż choć jedną regułkę ze swoich książeczek na pułkach których masz 
>podejrzewam jako "MĄDRY WYKŁADOWCA" możesz podać tytuły i stronę chętnie 
>poczytam bo to co opisałeś to jedyne o czym świadczy to brak kultury
>
>>
>>
>>> W aplikacji związanej z grafiką miałem wszystkie Command w paczce
>>> xx.commands, a ich nazwy to Move, Rotate, SetScale, itd.
>>>
>>>
>>> Inny przykład na klasę ZrobCosTam : w Androidzie mam takie klasy które
>>> przyjmują na wejściu obiekt z parametrami/danymi, odpalają wątek z puli
>>> i próbują przetwarzać te dane w oparciu o webservice. I mają właśnie
>>> takie nazwy: SaveSomething, GetSomething, etc. żeby wykonać akcję tworzę
>>> nową instancję takiej klasy.
>>>
>>> Powiesz że mógł bym to robić w jednym obiekcie, wołając jego funkcje
>>> saveSomething() etc. Mógłbym, ale i tak pod spodem musiał bym tworzyć
>>> obiekty trzymające aktualny stan, progress operacji. Więc naprawdę nie
>>> widzę sensu wprowadzać jeszcze jednego pośrednika.
>>
>> To dla ciebei widac tak jest. Niestety, z programwoaniem obiektowym
>> jest tak jak z internetem: trafil pod strzechy. Dla wiekszosci ludzi
>> "programwoanei obiektowe" to programowanie w Javie. O tym ze jset cos
>> takiego jak PROJEKTOWANIE OBIEKTOWE i ANALIZA OBIEKTOWA, malo kto,
>> niestety, wie. Zwlaszcza wsrod mlodych  "miszcow informatyki" ktorzy
>> ucza sie ze "programowanie obiektowe to programowanie w Javie". czy
>> C++.  O tym ze pewne rzeczy robi sie w okreslony sposob, i dlaczego
>> sie tak robi, malo kto wie.
>>
>
>Pan INTELIGENT :) któremu ów słoma z tych strzech się sypała i trafiła 
>do butów :) Zapomniał jej wygrzebać jak dostał się na uczelnie:)
>
>Pomyliłeś kolego wzorce projektowe z analizą obiektową, fakt powiązane 
>ale napewno analiza obiektowa nie określa co się robi w jaki sposób to 
>określają wzorce. Proszę sobie poczytać w swoich mądrych książkach,
>
>> Ale coz wymagac, skoro nawer znakomity MIMUW pod haslem "Programowanie
>> Obiektowe" przemyca programowanie w Javie, w ktorym to programowaniu
>> obiektowym, jak to wynika z wykladu, najwazniejsze sa wyjatki
>>
>> A.L.
>>
>> P.S. Jak pisalem wyzej, wyrzucam za dzrwi studenta ktory przyniesie mi
>> klase ZrobCosTam. I bede wyrzucal poki mi sil starczy, albo studenci
>> zrozumieja o co chodzi. A co sobie "miszczowie" pod Androidem robia,
>> malo mnie interesuje
>
>Tak jak napisałem pokaż to gdzieś, bo wymysły mnie nie interesują :)
>
>Pozdrawiam

Faknie napisales. Sluszniei zatagowales ze [OT]

A jakies argumenty merytoryczne masz? Jak bedziesz mial, to napisz
krotko. Tak zeby mi sie chcialo czytac

A.L.

On Fri, 27 Dec 2013 02:39:58 +0000, Roman W
<bloody_rabbitREMOVETHIS@gazeta.pl> wrote:

>On Wed, 25 Dec 2013 21:04:23 -0600, A.L. <alewando@aol.com> wrote:
>> Wzorzec Command ma komponenty/klasy
>
>
>> Command
>> Invoker
>> ConcreteCommand
>> Receiver
>> Action
>
>
>> Nie ma klasy ZrobCosTam.  Albowiem KLASA to OBIEKT a nie CZYNNOSC.
>
>"Action" to właśnie "Czynność".
>
>RW

Bardzo nieczestor to robie, ale tyym razem zrobie. Polecam Wikipedie

http://en.wikipedia.org/wiki/Command_pattern

g\tam pozrednei zaimplemenorano wzorzec Command

Prosze o wskazanie gdzie tam jest klasa ZrobCosTam

A.L.

On Thu, 12 Dec 2013 03:00:35 -0800 (PST), Jadalbert
<jadalbert.wincent@gmail.com> wrote:

>Jak to właściwie jest. Mam klasę abstrakcyjną (dodam, że rzecz ma się dziać w jsf - co to zmienia, nie wiem)
>
>public abstract class Figura {
>	public Figura(){}
>
>	private double pole;
>
>	public double getPole() {
>		return pole;
>	}
>}
>
>i klasę
>
>public class Kolo extends Figura {
>	public Kolo(){}
>
>	private double obwod;
>
>	public double getObwod() {
>		return obwod;
>	}
>}
>
>i teraz:
>public class Licz {
>	private Figura figura;
>	private double PoleObwod;
>
>	public Licz() {}
>
>	public Licz(Figura figura) {
>		this.figura = figura;
>	}
>
>	public double getPoleObwod() {
>		return figura.getPole() * figura.getObwod();
>// i tu oczywiście błąd bo obwodu nie ma w klasie Figura !
>	}
>}
>
>w "realu" będzie więcej klas jak Kolo i każda nie dość, że będzie pokrywała metody klasy bazowej to jeszcze będzie miała własne, dodatkowe. I skąd wziąć wiedzę, jakiej klasy jest to co przychodzi w konstruktorze?

1. A jak klasa Figura ma atrybut "pole" to dlaczego ma nie miec
atrybutu "obwod"

2. public double getPole() powinno byc "abstract". Obliczanie pola
powinno byc zostawione dla podklasy

3. Podobnie public double getObwod() powinno byc abstract a obliczanie
powinno byc zostawione dla podklasy

4. getObwod() i getPole() maja wiecej do roboty niz zworcenie wartosci
atrybutu, bo ktos musi to pole i ten obwod policzyc

A.L.

W dniu 28.12.2013 04:00, A.L. pisze:
> On Thu, 26 Dec 2013 18:11:30 +0100, J-23 <baczeklu@o2.pl> wrote:
>
>> W dniu 26.12.2013 17:02, A.L. pisze:
>>> On Thu, 26 Dec 2013 09:55:57 +0100, Arivald <NOSPAMarivald@interia.pl>
>>> wrote:
>>>
>>>> Generalnie tak. Ale nie widzę przeszkód żeby mieć klasę opisującą
>>>> czynność. Zresztą właśnie Command jest czynnością.
>>>>
>>>
>>> Generalnie nei widze powodu zeby nie mozna miec. Tak samo jek nei
>>> widze powodow aby nie mozna bylo pierdzec publicznie na przyjeciu
>>> swiatecznym u Cioci Kloci i dlubac publicznei w nosie.
>>>
>>
>> Fajny język PANIE WYKSZTAŁCONY WYKŁADOWCO... :)
>>
>>> Dowolny jezyk jest roznei rozciagliwy jak zuzyta prezerwatywa i mozna
>>> go rozciagac do woli. Ale na ogol , wsrod wielu mozliwych sposobow
>>> zrobienia czegos, jest kilka aledwie ktore sa prawidlowe.
>>>
>>
>> Dalszy wywód błyskotliwej myśli...
>>
>>>>>
>>>>> CZYNNOSC to czesc zachowanai (protokolu) klasy.
>>>>>
>>>>> Proponuje Koledze wziac jakis prosty podrecznik do UML czy do Object
>>>>> Oriented Design  i przekonac sie czym jest KLASA i OBIEKT w
>>>>> programowaniu obiektowym
>>>>>
>>>>> A.L.
>>>>>
>>>>
>>>> Ale to nie wyjaśnia dlaczego konkretna klasa implementująca Command nie
>>>> mogła by się nazywać ZrobCosTam.
>>>>
>>>
>>> No mogla by. Juz wyjasnilem wyzej. Podobnei jak mzoes pierdziec
>>> publicznie na raucie dyplomatycznym. Podobnie jak w dowolnym jezyku
>>> mozesz programowac jak chcesz. Ale jest drobne rozroznienie miedzy
>>> PROGRAMWOANIEM OBIEKTOWYM a PROGRAMWOANIEM W JAVE. Nie kazde
>>> programwoanie w Javie jest programowaniem obiektowym, nawet jezeli
>>> uzywa sie klasy (zreszta, w Jave nie da sie nie uzywac klas).
>>
>> Pokaż choć jedną regułkę ze swoich książeczek na pułkach których masz
>> podejrzewam jako "MĄDRY WYKŁADOWCA" możesz podać tytuły i stronę chętnie
>> poczytam bo to co opisałeś to jedyne o czym świadczy to brak kultury
>>
>>>
>>>
>>>> W aplikacji związanej z grafiką miałem wszystkie Command w paczce
>>>> xx.commands, a ich nazwy to Move, Rotate, SetScale, itd.
>>>>
>>>>
>>>> Inny przykład na klasę ZrobCosTam : w Androidzie mam takie klasy które
>>>> przyjmują na wejściu obiekt z parametrami/danymi, odpalają wątek z puli
>>>> i próbują przetwarzać te dane w oparciu o webservice. I mają właśnie
>>>> takie nazwy: SaveSomething, GetSomething, etc. żeby wykonać akcję tworzę
>>>> nową instancję takiej klasy.
>>>>
>>>> Powiesz że mógł bym to robić w jednym obiekcie, wołając jego funkcje
>>>> saveSomething() etc. Mógłbym, ale i tak pod spodem musiał bym tworzyć
>>>> obiekty trzymające aktualny stan, progress operacji. Więc naprawdę nie
>>>> widzę sensu wprowadzać jeszcze jednego pośrednika.
>>>
>>> To dla ciebei widac tak jest. Niestety, z programwoaniem obiektowym
>>> jest tak jak z internetem: trafil pod strzechy. Dla wiekszosci ludzi
>>> "programwoanei obiektowe" to programowanie w Javie. O tym ze jset cos
>>> takiego jak PROJEKTOWANIE OBIEKTOWE i ANALIZA OBIEKTOWA, malo kto,
>>> niestety, wie. Zwlaszcza wsrod mlodych  "miszcow informatyki" ktorzy
>>> ucza sie ze "programowanie obiektowe to programowanie w Javie". czy
>>> C++.  O tym ze pewne rzeczy robi sie w okreslony sposob, i dlaczego
>>> sie tak robi, malo kto wie.
>>>
>>
>> Pan INTELIGENT :) któremu ów słoma z tych strzech się sypała i trafiła
>> do butów :) Zapomniał jej wygrzebać jak dostał się na uczelnie:)
>>
>> Pomyliłeś kolego wzorce projektowe z analizą obiektową, fakt powiązane
>> ale napewno analiza obiektowa nie określa co się robi w jaki sposób to
>> określają wzorce. Proszę sobie poczytać w swoich mądrych książkach,
>>
>>> Ale coz wymagac, skoro nawer znakomity MIMUW pod haslem "Programowanie
>>> Obiektowe" przemyca programowanie w Javie, w ktorym to programowaniu
>>> obiektowym, jak to wynika z wykladu, najwazniejsze sa wyjatki
>>>
>>> A.L.
>>>
>>> P.S. Jak pisalem wyzej, wyrzucam za dzrwi studenta ktory przyniesie mi
>>> klase ZrobCosTam. I bede wyrzucal poki mi sil starczy, albo studenci
>>> zrozumieja o co chodzi. A co sobie "miszczowie" pod Androidem robia,
>>> malo mnie interesuje
>>
>> Tak jak napisałem pokaż to gdzieś, bo wymysły mnie nie interesują :)
>>
>> Pozdrawiam
>
> Faknie napisales. Sluszniei zatagowales ze [OT]
>
> A jakies argumenty merytoryczne masz? Jak bedziesz mial, to napisz
> krotko. Tak zeby mi sie chcialo czytac
>
> A.L.
>

Nie i nie oznacza ze ich nie mam. Ty zacząłeś się mądrzeć więc Ja 
poprosiłem o jakieś argumenty potwierdzające Twoje słowa. Jednak jak 
widać bierzesz udział w dyskusji i ani razu nie przytoczyłeś nic 
zgodnego z tematem, wszystkie Twoje wypowiedzi trzeba za tagować jak ja 
to zrobiłem. Ja tylko skomentowałem Twój KRETYNIZM i więcej 
wykształconego TROLLA nie karmię, bo widać wyznajesz zasadę ja jeden 
jestem WSZECHWIEDZĄCY reszta nie wie nic, wiec żyj sobie w swojej 
zadufanej głupocie dalej.

On Sat, 28 Dec 2013 14:24:56 +0100, J-23 <baczeklu@o2.pl> wrote:
 
>
>Nie i nie oznacza ze ich nie mam. Ty zacząłeś się mądrzeć więc Ja 
>poprosiłem o jakieś argumenty potwierdzające Twoje słowa. Jednak jak 
>widać bierzesz udział w dyskusji i ani razu nie przytoczyłeś nic 
>zgodnego z tematem, wszystkie Twoje wypowiedzi trzeba za tagować jak ja 
>to zrobiłem. Ja tylko skomentowałem Twój KRETYNIZM i więcej 
>wykształconego TROLLA nie karmię, bo widać wyznajesz zasadę ja jeden 
>jestem WSZECHWIEDZĄCY reszta nie wie nic, wiec żyj sobie w swojej 
>zadufanej głupocie dalej.

Wsadzam cie, gosciu, do KF; tam sie wywnetrzaj

A.L.

On 2013-12-28 04:10, A.L. wrote:

>
> Bardzo nieczestor to robie, ale tyym razem zrobie. Polecam Wikipedie
>
> http://en.wikipedia.org/wiki/Command_pattern
>
> g\tam pozrednei zaimplemenorano wzorzec Command
>

Jeżeli poprawnie Cię rozumiem to identyfikatory klas winny być 
rzeczownikami a nie czasownikami , czyli  FlipUpCommand a nie samo 
FlipUp, analogicznie KomendaZrobCosTam vs ZrobCosTam.

I to *zawsze* ma być czytelniej, bardziej jednoznacznie? A może ma inną 
wartość?



> Prosze o wskazanie gdzie tam jest klasa ZrobCosTam
>

proszę bardzo:
public class PressSwitch {


Darek

On Mon, 30 Dec 2013 13:07:04 +0100, darekm <darekm@emadar.com> wrote:

>On 2013-12-28 04:10, A.L. wrote:
>
>>
>> Bardzo nieczestor to robie, ale tyym razem zrobie. Polecam Wikipedie
>>
>> http://en.wikipedia.org/wiki/Command_pattern
>>
>> g\tam pozrednei zaimplemenorano wzorzec Command
>>
>
>Jeżeli poprawnie Cię rozumiem to identyfikatory klas winny być 
>rzeczownikami a nie czasownikami , czyli  FlipUpCommand a nie samo 
>FlipUp, analogicznie KomendaZrobCosTam vs ZrobCosTam.
>
>I to *zawsze* ma być czytelniej, bardziej jednoznacznie? A może ma inną 
>wartość?
>

Jezyk nei wymusza nazw. Natomiast w TECHNOLOGII OBIEKTOWEJ uwaza sie
ze klasy maja byc rzeczownikami - bo aplikacja to zespol
wspolpracujacych OBIEKTOW a nie CZYNNOSCI. Czynnosci sa oferowane
pzrez objekty. Ten prosty fakt znany jest i szanowany tak dlugo jak
dlugo istniee owa technologia obiektowa. 

Sprawy nazw klas nie maja nic wspolnego z czytelnoscia, a z
architektura aplikacji. Nazwy wymuszaja okreslona strukture aplikacji

Oczywiscie, mozna programwoac w Javie uzywajac klas, ale nie stosujac
technologii obiektowej. Wtedy mozna nazywac sobie rozne rzeczy
dowolnie jak sie chce.

Informaclje na ten temat - roli klas w projekcie a takze sposobu
bazywania klas, mozna znalezc w dolwonym podreczniku praktujacym o
object oriented ANALYSIS i object oriented DESIGN. Niestety,
podreczniki te sa dziwnei malo popularne.

>
>> Prosze o wskazanie gdzie tam jest klasa ZrobCosTam
>>
>
>proszę bardzo:
>public class PressSwitch {
>

Klas PressSwitch powinna byc nazwana PressSwitchTester bo taka jest
rola tej klasy. Proponuje popatrzec na implementacje w C#. Tam
odpowiednik tej klasy nazywa sie Program. 

A.L.

On Mon, 30 Dec 2013 13:07:04 +0100, darekm <darekm@emadar.com> wrote:

>On 2013-12-28 04:10, A.L. wrote:
>
>>
>> Bardzo nieczestor to robie, ale tyym razem zrobie. Polecam Wikipedie
>>
>> http://en.wikipedia.org/wiki/Command_pattern
>>
>> g\tam pozrednei zaimplemenorano wzorzec Command
>>
>
>Jeżeli poprawnie Cię rozumiem to identyfikatory klas winny być 
>rzeczownikami a nie czasownikami , czyli  FlipUpCommand a nie samo 
>FlipUp, analogicznie KomendaZrobCosTam vs ZrobCosTam.
>
>I to *zawsze* ma być czytelniej, bardziej jednoznacznie? A może ma inną 
>wartość?

P.S. Podepre sie cytatem

Class and Interface Names

Class names are always nouns, not verbs. Avoid making a noun out of a
verb, example DividerClass. If you are having difficulty naming a
class then perhaps it is a bad class. 

Interface names should always be an adjective (wherever possible)
describing the enforced behaviors of the class (noun). Preferably,
said adjective should end in "able" following an emerging preference
in Java. i.e. Clonable, Versionable, Taggable, etc.
...
Class names should be descriptive in nature without implying
implementation. The internal implementation of an object should be
encapsulated and not visible outside the object. Since implementation
can change, to imply implementation in the name forces the class name
and all references to it to change or else the code can become
misleading.

http://www.iwombat.com/standards/JavaStyleGuide.html#Class%20and%20Interface%20Names

A.L.

On 2013-12-30 16:36, A.L. wrote:
> On Mon, 30 Dec 2013 13:07:04 +0100, darekm <darekm@emadar.com> wrote:
>
>> On 2013-12-28 04:10, A.L. wrote:
>>
>>>
>>> Bardzo nieczestor to robie, ale tyym razem zrobie. Polecam Wikipedie
>>>
>>> http://en.wikipedia.org/wiki/Command_pattern
>>>
>>> g\tam pozrednei zaimplemenorano wzorzec Command
>>>
>>
>> Jeżeli poprawnie Cię rozumiem to identyfikatory klas winny być
>> rzeczownikami a nie czasownikami , czyli  FlipUpCommand a nie samo
>> FlipUp, analogicznie KomendaZrobCosTam vs ZrobCosTam.
>>
>> I to *zawsze* ma być czytelniej, bardziej jednoznacznie? A może ma inną
>> wartość?
>>
>
> Jezyk nei wymusza nazw. Natomiast w TECHNOLOGII OBIEKTOWEJ uwaza sie
> ze klasy maja byc rzeczownikami - bo aplikacja to zespol
> wspolpracujacych OBIEKTOW a nie CZYNNOSCI. Czynnosci sa oferowane
> pzrez objekty. Ten prosty fakt znany jest i szanowany tak dlugo jak
> dlugo istniee owa technologia obiektowa.
>

W ogólności masz rację. W rzeczywistości wyprowadzanie praw z nazwy 
metody jest ograniczające, a czasem bywa błędne. Nie zawsze obiekt jest 
rzeczą i ma być opisany rzeczownikiem jak również czasami rzeczownik i 
czasownik (czy też inna część mowy) mają dokładnie tą samą formę. Nic 
nam nie daje zasada: obiekt ma być nazwany rzeczownikiem.

To że fakt jest znany i szanowany (powszechny) nie znaczy że jest 
zasadą. To nigdzie ( w żadnej nauce)   nie obowiązuje.


> Sprawy nazw klas nie maja nic wspolnego z czytelnoscia, a z
> architektura aplikacji. Nazwy wymuszaja okreslona strukture aplikacji
>

"Byt określa świadomość" ??

To struktura aplikacji wymusza nazwy.
I oczywiście źle dobrane nazwy pogarszają czytelność programu.




> Oczywiscie, mozna programwoac w Javie uzywajac klas, ale nie stosujac
> technologii obiektowej. Wtedy mozna nazywac sobie rozne rzeczy
> dowolnie jak sie chce.
>

Technologia obiektowa to nie religia tylko metodyka, można stosować 
inne,  ale nazywać należy dobrze;


> Informaclje na ten temat - roli klas w projekcie a takze sposobu
> bazywania klas, mozna znalezc w dolwonym podreczniku praktujacym o
> object oriented ANALYSIS i object oriented DESIGN. Niestety,
> podreczniki te sa dziwnei malo popularne.
>

Co najwyżej popularne mogą książki zawierające zbiór zaklęć w języku ....

>>
>>> Prosze o wskazanie gdzie tam jest klasa ZrobCosTam
>>>
>>
>> proszę bardzo:
>> public class PressSwitch {
>>
>
> Klas PressSwitch powinna byc nazwana PressSwitchTester bo taka jest
> rola tej klasy. Proponuje popatrzec na implementacje w C#. Tam
> odpowiednik tej klasy nazywa sie Program.

PressSwitchTester ok, ale Program zupełnie nie: wprowadza w błąd, a 
przynajmniej nic nie mówi.

Darek

On Mon, 30 Dec 2013 17:24:51 +0100, darekm <darekm@emadar.com> wrote:

>On 2013-12-30 16:36, A.L. wrote:
>> On Mon, 30 Dec 2013 13:07:04 +0100, darekm <darekm@emadar.com> wrote:
>>
>>> On 2013-12-28 04:10, A.L. wrote:
>>>
>>>>
>>>> Bardzo nieczestor to robie, ale tyym razem zrobie. Polecam Wikipedie
>>>>
>>>> http://en.wikipedia.org/wiki/Command_pattern
>>>>
>>>> g\tam pozrednei zaimplemenorano wzorzec Command
>>>>
>>>
>>> Jeżeli poprawnie Cię rozumiem to identyfikatory klas winny być
>>> rzeczownikami a nie czasownikami , czyli  FlipUpCommand a nie samo
>>> FlipUp, analogicznie KomendaZrobCosTam vs ZrobCosTam.
>>>
>>> I to *zawsze* ma być czytelniej, bardziej jednoznacznie? A może ma inną
>>> wartość?
>>>
>>
>> Jezyk nei wymusza nazw. Natomiast w TECHNOLOGII OBIEKTOWEJ uwaza sie
>> ze klasy maja byc rzeczownikami - bo aplikacja to zespol
>> wspolpracujacych OBIEKTOW a nie CZYNNOSCI. Czynnosci sa oferowane
>> pzrez objekty. Ten prosty fakt znany jest i szanowany tak dlugo jak
>> dlugo istniee owa technologia obiektowa.
>>
>
>W ogólności masz rację. W rzeczywistości wyprowadzanie praw z nazwy 
>metody jest ograniczające, a czasem bywa błędne. Nie zawsze obiekt jest 
>rzeczą i ma być opisany rzeczownikiem jak również czasami rzeczownik i 
>czasownik (czy też inna część mowy) mają dokładnie tą samą formę. Nic 
>nam nie daje zasada: obiekt ma być nazwany rzeczownikiem.
>

jak juz pisalem: mozan rozne rzeczy nazywac jak sie chce. Tyle tylko,
ze pewnych rzeczy nie mozan robic tak dlugo jak dlugo pozostaje sie w
obszarze pewnej metodologii.

Programowanei w jave moze byc a mozie i nei byc obiektowe. Samo
uzywanie klas nie powoduje ze program staje sie obiektowy. Jest tylko
programam z klasami.

>To że fakt jest znany i szanowany (powszechny) nie znaczy że jest 
>zasadą. To nigdzie ( w żadnej nauce)   nie obowiązuje.
>

Jak wyzej: jest zasada w obszarze okreslonej metodologii. Nie  ma
obowiazku stosowanai tej metodologii.

>
>> Sprawy nazw klas nie maja nic wspolnego z czytelnoscia, a z
>> architektura aplikacji. Nazwy wymuszaja okreslona strukture aplikacji
>>
>
>"Byt określa świadomość" ??
>
>To struktura aplikacji wymusza nazwy.
>I oczywiście źle dobrane nazwy pogarszają czytelność programu.
>

Struktura problemu wymusza nazwy. W methdologii obiektowej obowiazuje
prosta zasada: przeczytaj wymagania czy use cases, zakresl olowkiem
wszystkie rzeczowniki. To beda klasy. Zakresl olowkiem wszystkie
czasowniki. To beda metody

A potem, struktuar tych nazw wymusza strukture aplikacji. Albowiem
aplikacjama byc modelem dziedziny

>
>
>> Oczywiscie, mozna programwoac w Javie uzywajac klas, ale nie stosujac
>> technologii obiektowej. Wtedy mozna nazywac sobie rozne rzeczy
>> dowolnie jak sie chce.
>>
>
>Technologia obiektowa to nie religia tylko metodyka, można stosować 
>inne,  ale nazywać należy dobrze;
>

Nikt nikomu nei kaze stosoowac metodyki obiektowej, nawet jezeli sie
programuje w Javie. 

A.L.

A.L. pisze:

> Struktura problemu wymusza nazwy. W methdologii obiektowej obowiazuje
> prosta zasada: przeczytaj wymagania czy use cases, zakresl olowkiem
> wszystkie rzeczowniki. To beda klasy. Zakresl olowkiem wszystkie
> czasowniki. To beda metody

Klasy rzeczowniki to najczęściej analityczne klasy entity, przenoszące 
dane. Zachowanie wynikające z use case najlepiej zamknąć w klasach 
pełniących rolę kontrolerów.
Komunikację z systemami zewnętrznymi realizują klasy boundary.



-- 
pozdrawiam
Piotr
XLR250&bmw_f650_dakar

On 2013-12-30 16:50, A.L. wrote:
> On Mon, 30 Dec 2013 13:07:04 +0100, darekm <darekm@emadar.com> wrote:
>
>> On 2013-12-28 04:10, A.L. wrote:
>>
>>>
>>> Bardzo nieczestor to robie, ale tyym razem zrobie. Polecam Wikipedie
>>>
>>> http://en.wikipedia.org/wiki/Command_pattern
>>>
>>> g\tam pozrednei zaimplemenorano wzorzec Command
>>>
>>
>> Jeżeli poprawnie Cię rozumiem to identyfikatory klas winny być
>> rzeczownikami a nie czasownikami , czyli  FlipUpCommand a nie samo
>> FlipUp, analogicznie KomendaZrobCosTam vs ZrobCosTam.
>>
>> I to *zawsze* ma być czytelniej, bardziej jednoznacznie? A może ma inną
>> wartość?
>
> P.S. Podepre sie cytatem
>
> Class and Interface Names
>

Mimo niewątpliwej wartości to jest tylko Coding Style Guidelines, nie 
zawiera żadnego uzasadnienia (bo nie musi).

> Class names are always nouns, not verbs. Avoid making a noun out of a
> verb, example DividerClass. If you are having difficulty naming a
> class then perhaps it is a bad class.
>

Podoba mi się drugie zdanie. Trzecie też ze względu na "być może". W 99% 
zgoda, ale język naturalny nie dość dobrze reprezentuje świat wirtualny 
czy też "niewidzialny".  Bezmyślne mapowanie obiekt-> rzeczownik nie 
jest złe. Ale robienie tak wbrew pozostałym zasadom jest.


> ...
> Class names should be descriptive in nature without implying
> implementation. The internal implementation of an object should be
> encapsulated and not visible outside the object. Since implementation
> can change, to imply implementation in the name forces the class name
> and all references to it to change or else the code can become
> misleading.

To na potwierdzenie tego co pisałem poprzednio?

>
> http://www.iwombat.com/standards/JavaStyleGuide.html#Class%20and%20Interface%20Names
>
> A.L.
>


Darek

On 2013-12-30 18:02, A.L. wrote:
> On Mon, 30 Dec 2013 17:24:51 +0100, darekm <darekm@emadar.com> wrote:
>
>> On 2013-12-30 16:36, A.L. wrote:
>>> On Mon, 30 Dec 2013 13:07:04 +0100, darekm <darekm@emadar.com> wrote:
>>>
>>>> On 2013-12-28 04:10, A.L. wrote:
>>>>
>>>>>
>>>>> Bardzo nieczestor to robie, ale tyym razem zrobie. Polecam Wikipedie
>>>>>
>>>>> http://en.wikipedia.org/wiki/Command_pattern
>>>>>
>>>>> g\tam pozrednei zaimplemenorano wzorzec Command
>>>>>
>>>>
>>>> Jeżeli poprawnie Cię rozumiem to identyfikatory klas winny być
>>>> rzeczownikami a nie czasownikami , czyli  FlipUpCommand a nie samo
>>>> FlipUp, analogicznie KomendaZrobCosTam vs ZrobCosTam.
>>>>
>>>> I to *zawsze* ma być czytelniej, bardziej jednoznacznie? A może ma inną
>>>> wartość?
>>>>
>>>
>>> Jezyk nei wymusza nazw. Natomiast w TECHNOLOGII OBIEKTOWEJ uwaza sie
>>> ze klasy maja byc rzeczownikami - bo aplikacja to zespol
>>> wspolpracujacych OBIEKTOW a nie CZYNNOSCI. Czynnosci sa oferowane
>>> pzrez objekty. Ten prosty fakt znany jest i szanowany tak dlugo jak
>>> dlugo istniee owa technologia obiektowa.
>>>
>>
>> W ogólności masz rację. W rzeczywistości wyprowadzanie praw z nazwy
>> metody jest ograniczające, a czasem bywa błędne. Nie zawsze obiekt jest
>> rzeczą i ma być opisany rzeczownikiem jak również czasami rzeczownik i
>> czasownik (czy też inna część mowy) mają dokładnie tą samą formę. Nic
>> nam nie daje zasada: obiekt ma być nazwany rzeczownikiem.
>>
>
> jak juz pisalem: mozan rozne rzeczy nazywac jak sie chce. Tyle tylko,
> ze pewnych rzeczy nie mozan robic tak dlugo jak dlugo pozostaje sie w
> obszarze pewnej metodologii.
>

Nie traktuję OO jak religii tylko jako metodykę. Póki się sprawdza i 
jest efektywna to stosuję. Jak na jakimś obszarze zastosowanie czegoś 
innego jest efektywniejsze to stosuję coś innego. Religijnych argumentów 
w stylu stosujesz wszystko albo to nie jest OO nie uznaję.

> Programowanei w jave moze byc a mozie i nei byc obiektowe. Samo
> uzywanie klas nie powoduje ze program staje sie obiektowy. Jest tylko
> programam z klasami.
>
>> To że fakt jest znany i szanowany (powszechny) nie znaczy że jest
>> zasadą. To nigdzie ( w żadnej nauce)   nie obowiązuje.
>>
>
> Jak wyzej: jest zasada w obszarze okreslonej metodologii. Nie  ma
> obowiazku stosowanai tej metodologii.
>

Mam wrażenie że z przesłanki wynikającej z takiej a nie innej nazwy 
metodyki zrobiłeś dogmat.


>>
>>> Sprawy nazw klas nie maja nic wspolnego z czytelnoscia, a z
>>> architektura aplikacji. Nazwy wymuszaja okreslona strukture aplikacji
>>>
>>
>> "Byt określa świadomość" ??
>>
>> To struktura aplikacji wymusza nazwy.
>> I oczywiście źle dobrane nazwy pogarszają czytelność programu.
>>
>
> Struktura problemu wymusza nazwy. W methdologii obiektowej obowiazuje
> prosta zasada: przeczytaj wymagania czy use cases, zakresl olowkiem
> wszystkie rzeczowniki. To beda klasy. Zakresl olowkiem wszystkie
> czasowniki. To beda metody
>

Przypomina to nauczanie matematyki w klasach humanistycznych. Zakłada 
się że nie muszą poznawać granic stosowalności.


> A potem, struktuar tych nazw wymusza strukture aplikacji. Albowiem
> aplikacjama byc modelem dziedziny
>

Jak identyfikator (nazwa) ma wymuszać strukturę aplikacji?
Co gorsza ma to znamiona typowego zachowania. Jak coś powiem to będę 
tego bronił do upadłego: jak jakiś obiekt nazwę to ma mieć wszystkie 
własności wynikające z nazwy, a dalej struktura podlega nazwom a nie 
celom i wymaganiom (szczególnie że te się zmieniają). Powodzenia z takim 
podejściem.

Darek

On Tue, 31 Dec 2013 17:27:34 +0100, darekm <darekm@emadar.com> wrote:

>On 2013-12-30 16:50, A.L. wrote:
>> On Mon, 30 Dec 2013 13:07:04 +0100, darekm <darekm@emadar.com> wrote:
>>
>>> On 2013-12-28 04:10, A.L. wrote:
>>>
>>>>
>>>> Bardzo nieczestor to robie, ale tyym razem zrobie. Polecam Wikipedie
>>>>
>>>> http://en.wikipedia.org/wiki/Command_pattern
>>>>
>>>> g\tam pozrednei zaimplemenorano wzorzec Command
>>>>
>>>
>>> Jeżeli poprawnie Cię rozumiem to identyfikatory klas winny być
>>> rzeczownikami a nie czasownikami , czyli  FlipUpCommand a nie samo
>>> FlipUp, analogicznie KomendaZrobCosTam vs ZrobCosTam.
>>>
>>> I to *zawsze* ma być czytelniej, bardziej jednoznacznie? A może ma inną
>>> wartość?
>>
>> P.S. Podepre sie cytatem
>>
>> Class and Interface Names
>>
>
>Mimo niewątpliwej wartości to jest tylko Coding Style Guidelines, nie 
>zawiera żadnego uzasadnienia (bo nie musi).

Wkraczamy w niebezpieczny obszar bicia piany. 

Owszem, kazdy mzoe robic co chce, bo jezyk pewnych rzeczy nei wymusza.
Co nie znaczy ze WSZYSTKO, w OKRESLONYCH sytuacjach jest prawidlowe

Tym niemniej, pewne zasady sie utarly, i nei dlatego ze komus sie tak
widzialo, a dlatego ze owe zasady maja okreslone wsparcie
doswiadczalne.

Poki co, MOJ student proponujacy klase Licz wylatuje za dzrwi,
podobnie jak moj pracownik proponujacy klase Licz dostaje opierdol i
skierowanie na kurs.

Zas Kolega moze robic co chce.Wszak zyjemy w wolnym kraju. Ale
przypominam ze zawsze latwo odroznic profesjonaliste od amatora.

A.L.

W dniu 2013-12-30 18:02, A.L. pisze:
 >
 > Struktura problemu wymusza nazwy. W methdologii obiektowej obowiazuje
 > prosta zasada: przeczytaj wymagania czy use cases, zakresl olowkiem
 > wszystkie rzeczowniki. To beda klasy. Zakresl olowkiem wszystkie
 > czasowniki. To beda metody

Trochę masz racji, ale nie do końca.
Gdyby się ściśle trzymać tego, co napisałeś, to klasami byłyby tylko 
modele (w sensie MVC). Bo rzeczownikiem jest: konto, klient, rachunek itp
A walidacja danych? "waliduj" to czasownik. Czy musi być metodą?
Niekoniecznie bo gdy walidacja jest złożona, to mamy Walidator (z 
czasownika zrobiliśmy sobie rzeczownik).
Podobnie z "zapisaniem" - od tego można stworzyć "Zapis" (czy inny Writer).

Tak więc, zgadzając się jednak z Twoim tokiem rozumowania, chciałem 
zaznaczyć że życie jest bardziej złożone i trudno jest zdefiniować 
zasady (zasady nazewnictwa) które zawsze, by pasowały, zawsze były wygodne.

Pozdrawiam,
Wojtek

W dniu 02.01.2014 21:53, WOJSAL pisze:
> W dniu 2013-12-30 18:02, A.L. pisze:
>  >
>  > Struktura problemu wymusza nazwy. W methdologii obiektowej obowiazuje
>  > prosta zasada: przeczytaj wymagania czy use cases, zakresl olowkiem
>  > wszystkie rzeczowniki. To beda klasy. Zakresl olowkiem wszystkie
>  > czasowniki. To beda metody
>
> Trochę masz racji, ale nie do końca.
> Gdyby się ściśle trzymać tego, co napisałeś, to klasami byłyby tylko
> modele (w sensie MVC). Bo rzeczownikiem jest: konto, klient, rachunek itp
> A walidacja danych? "waliduj" to czasownik. Czy musi być metodą?
> Niekoniecznie bo gdy walidacja jest złożona, to mamy Walidator (z
> czasownika zrobiliśmy sobie rzeczownik).
> Podobnie z "zapisaniem" - od tego można stworzyć "Zapis" (czy inny Writer).
>
> Tak więc, zgadzając się jednak z Twoim tokiem rozumowania, chciałem
> zaznaczyć że życie jest bardziej złożone i trudno jest zdefiniować
> zasady (zasady nazewnictwa) które zawsze, by pasowały, zawsze były wygodne.
>

Ja też się zgodzę w takim stopniu jak ty, ale kultura A.L. pozostawia 
wiele do życzenia to po pierwsze.

Po drugie niech sobie A.L. uświadomi że OP dawał tylko przykład gdzie 
nazwał sobie klasę w owym przykładzie z "sufitu" :P