Klasy pochodne od klasy "Application" - Revision history

Krashan: Link redirected to Polish version.

2011-01-28T12:53:03Z

Link redirected to Polish version.

Krashan: Translation finished.

2011-01-27T12:47:59Z

Translation finished.

Krashan: Translation in progress.

2011-01-27T12:34:58Z

Translation in progress.

Krashan: Translation in progress.

2011-01-27T09:25:47Z

Translation in progress.

Krashan: Translation started.

2011-01-27T09:05:53Z

Translation started.

New page

''Grzegorz Kraszewski''
----
<small>Ten artykuł w innych językach: [[Subclassing Application Class|angielski]]</small>

Every MUI application is (or at least should be) an event driven one. This means the application provides a set of actions, which may be triggered with user activity (like using the mouse and keyboard). The straightforward way of implementing this set of actions is to implement it as a set of methods added to some MUI object. For simple programs, the best candidate for adding such methods is the master ''Application'' object. More complex programs (for example ones using a multi-document interface) may add actions to other classes, for example the ''Window'' class.

Why methods? Implementing actions as methods has many advantages:
* Methods may be used directly as notification actions. It saves a programmer from using hook tricks or cluttering the main loop with lots of ''ReturnID'' values.
* Methods may be coupled directly with scripting language interface (formerly known as ARexx interface) commands.
* Methods used in notifications are executed immediately in response to user actions. No delay is introduced by the main loop (especially if it is not empty).
* A notification triggering attribute value may be [[Event Driven Programming, Notifications#Reusing Triggering Value|passed directly]] to a method as its parameter.
* Using methods improves code modularity and object encapsulation. Functionality meant to be handled in the scope of an object is handled in its method, without the code spreading across the project.

In a well designed MUI program, all program actions and functionality are implemented as methods and the program internal state is stored as a set of attributes and internal application instance data fields. An example of such a program is discussed throughly in the [[MUI Subclassing Tutorial: SciMark2 Port]] article.

← Older revision		Revision as of 12:53, 28 January 2011
Line 13:		Line 13:
	* Użycie metod zwiększa modułowość kodu i enkapsulację danych. Funkcje, które działają na danym obiekcie, są metodami tego obiektu, kod dotyczący obiektu nie jest rozrzucony po całym projekcie.		* Użycie metod zwiększa modułowość kodu i enkapsulację danych. Funkcje, które działają na danym obiekcie, są metodami tego obiektu, kod dotyczący obiektu nie jest rozrzucony po całym projekcie.

−	W dobrze zaprojektowanej aplikacji MUI cała funkcjonalność programu zawarta jest w metodach, a wewnętrzny stan programu i danych jest pamiętany jako zestaw atrybutów i pól w strukturze danych obiektu (lub obiektów). Przykład takiego programu został szczegółowo omówiony w artukule "[[~~MUI Subclassing Tutorial~~: SciMark2 ~~Port~~]]".	+	W dobrze zaprojektowanej aplikacji MUI cała funkcjonalność programu zawarta jest w metodach, a wewnętrzny stan programu i danych jest pamiętany jako zestaw atrybutów i pól w strukturze danych obiektu (lub obiektów). Przykład takiego programu został szczegółowo omówiony w artukule "[[Tworzenie klas pochodnych: port programu SciMark2]]".

← Older revision		Revision as of 12:47, 27 January 2011
Line 13:		Line 13:
	* Użycie metod zwiększa modułowość kodu i enkapsulację danych. Funkcje, które działają na danym obiekcie, są metodami tego obiektu, kod dotyczący obiektu nie jest rozrzucony po całym projekcie.		* Użycie metod zwiększa modułowość kodu i enkapsulację danych. Funkcje, które działają na danym obiekcie, są metodami tego obiektu, kod dotyczący obiektu nie jest rozrzucony po całym projekcie.

−	~~In a well designed~~ MUI ~~program~~, ~~all program actions and functionality are implemented as methods and the program internal state is stored as~~ a ~~set of attributes and internal application instance data fields~~. ~~An example of such a program is discussed throughly in the~~ [[MUI Subclassing Tutorial: SciMark2 Port]] ~~article~~.	+	W dobrze zaprojektowanej aplikacji MUI cała funkcjonalność programu zawarta jest w metodach, a wewnętrzny stan programu i danych jest pamiętany jako zestaw atrybutów i pól w strukturze danych obiektu (lub obiektów). Przykład takiego programu został szczegółowo omówiony w artukule "[[MUI Subclassing Tutorial: SciMark2 Port]]".

@@ Line 6: / Line 6: @@
 Każdy program używający MUI jest (a przynajmniej powinien być) [[Programowanie sterowane zdarzeniami, notyfikacje|sterowany zdarzeniami]]. Oznacza to, że program dostarcza zestawu akcji, które mogą być wyzwalane przez użytkownika (najczęściej za pośrednictwem myszy albo klawiatury). Najprostszym sposobem umieszczenia w programie takiego zestawu akcji jest zaimplementowanie ich jako zestawu metod jakiegoś obiektu MUI. Dla prostych aplikacji najlepszym kandydatem do dodania takich metod jest główny obiekt programu klasy ''Application''. Bardziej złożone programy, na przykład używające interfejsu z wieloma oknami dokumentów (ang. ''multi-document interface''), mogą dodawać akcje do innych klas, na przykład do klasy ''Window''.
-Why methods? Implementing actions as methods has many advantages:
+Dlaczego metody? Napisanie akcji programu w postaci metod ma kilka zalet:
-* Methods may be used directly as notification actions. It saves a programmer from using hook tricks or cluttering the main loop with lots of ''ReturnID'' values.
+* Metody mogą być użyte bezpośrednio jako akcje w [[Programowanie sterowane zdarzeniami, notyfikacje#Notyfikacje w MUI|notyfilacjach]]. Programista nie musi używać hooków ani zaśmiecać głównej pętli dekodowaniem zdarzeń.
-* Methods may be coupled directly with scripting language interface (formerly known as ARexx interface) commands.
+* Metody mogą być bezpośrednio przyporządkowane poleceniom dostępnym w językach skryptowych poprzez port komunikacyny (zwany tradycyjnie portem ARexxa).
-* Methods used in notifications are executed immediately in response to user actions. No delay is introduced by the main loop (especially if it is not empty).
+* Metody wywołane z notyfikacji są wykonywane bezpośredno w odpowiedzi na zdarzenia. Nie ma opóźnień wprowadzanych przez główną pętlę, zwłaszcza gdy pętla ta nie jest pusta.
-* A notification triggering attribute value may be [[Event Driven Programming, Notifications#Reusing Triggering Value|passed directly]] to a method as its parameter.
+* Wartość atrybutu wyzwalającego notyfikację może być [[Programowanie sterowane zdarzeniami, notyfikacje#Wykorzystanie wartości wyzwalającej|bezpośrednio przekazana]] do metody jako jej parametr.
-* Using methods improves code modularity and object encapsulation. Functionality meant to be handled in the scope of an object is handled in its method, without the code spreading across the project.
+* Użycie metod zwiększa modułowość kodu i enkapsulację danych. Funkcje, które działają na danym obiekcie, są metodami tego obiektu, kod dotyczący obiektu nie jest rozrzucony po całym projekcie.
 In a well designed MUI program, all program actions and functionality are implemented as methods and the program internal state is stored as a set of attributes and internal application instance data fields. An example of such a program is discussed throughly in the [[MUI Subclassing Tutorial: SciMark2 Port]] article.

← Older revision		Revision as of 09:25, 27 January 2011
Line 4:		Line 4:


−	~~Every~~ MUI ~~application is~~ (~~or at least should be~~) ~~an event driven one~~. ~~This means the application provides a set of actions~~, ~~which may be triggered with user activity~~ (~~like using the mouse and keyboard~~). ~~The straightforward way of implementing this set of actions is to implement it as a set of methods added to some~~ MUI ~~object~~. ~~For simple programs, the best candidate for adding such methods is the master~~ ''Application'' ~~object~~. ~~More complex programs~~ (~~for example ones using a~~ multi-document interface) ~~may add actions to other classes~~, ~~for example the~~ ''Window'' ~~class~~.	+	Każdy program używający MUI jest (a przynajmniej powinien być) [[Programowanie sterowane zdarzeniami, notyfikacje\|sterowany zdarzeniami]]. Oznacza to, że program dostarcza zestawu akcji, które mogą być wyzwalane przez użytkownika (najczęściej za pośrednictwem myszy albo klawiatury). Najprostszym sposobem umieszczenia w programie takiego zestawu akcji jest zaimplementowanie ich jako zestawu metod jakiegoś obiektu MUI. Dla prostych aplikacji najlepszym kandydatem do dodania takich metod jest główny obiekt programu klasy ''Application''. Bardziej złożone programy, na przykład używające interfejsu z wieloma oknami dokumentów (ang. ''multi-document interface''), mogą dodawać akcje do innych klas, na przykład do klasy ''Window''.

	Why methods? Implementing actions as methods has many advantages:		Why methods? Implementing actions as methods has many advantages: