links to oop

Author: dg

best-practices/bg/@home.texy

@@ -41,6 +41,7 @@
 - [Защо Nette не използва суфикса Interface? |https://blog.nette.org/bg/prefiksite-i-sufiksite-ne-prinadlezat-na-imenata-na-interfejsite]
 - [Съвети за използване на Composer |composer]
 - [Съвети за редактори и инструменти |editors-and-tools]
+- [Въведение в обектно-ориентираното програмиране |nette:introduction-to-object-oriented-programming]
 
 </div>
 <div>

best-practices/bg/form-reuse.texy

@@ -152,7 +152,7 @@ class EditFormFactory
 }
 ```
 
-Много е важно обвързването между класовете `FormFactory` и `EditFormFactory` да се реализира чрез композиция, а не чрез наследяване на обекти:
+Много е важно връзката между класовете `FormFactory` и `EditFormFactory` да се осъществява [чрез композиция |nette:introduction-to-object-oriented-programming#composition], а не [чрез |nette:introduction-to-object-oriented-programming#composition] [наследяване на обекти |https://doc.nette.org/en/introduction-to-object-oriented-programming#inheritance]:
 
 ```php
 // ⛔ НЕ! НАСЛЕДСТВОТО НЕ ПРИНАДЛЕЖИ ТУК
@@ -172,7 +172,7 @@ class EditFormFactory extends FormFactory
 Използването на наследяване в този случай би било напълно непродуктивно. Много бързо ще се сблъскате с проблеми. Например, ако искате да добавите параметри към метода `create()`; PHP ще отчете грешка, че сигнатурата му е различна от тази на родителя.
 Или при предаване на зависимост на класа `EditFormFactory` чрез конструктора. Това би довело до това, което наричаме " [ад на конструкторите" |dependency-injection:passing-dependencies#Constructor hell].
 
-Като цяло е по-добре да се предпочита композицията пред наследяването.
+Като цяло е по-добре да се предпочита [композицията пред наследяването |dependency-injection:faq#Why composition is preferred over inheritance].
 
 
 Обработка на формуляри .[#toc-form-handling]

best-practices/bg/presenter-traits.texy

@@ -2,7 +2,7 @@
 ****************************
 
 .[perex]
-Ако трябва да приложим един и същ код в няколко презентатора (например проверка дали потребителят е влязъл в системата), изкушаващо е да поставим този код в общ предшественик. Вторият вариант е да се създадат едноцелеви признаци.
+Ако трябва да приложим един и същ код в няколко презентатора (например проверка дали потребителят е влязъл в системата), изкушаващо е да поставим кода в общ предшественик. Втората възможност е да се създадат едноцелеви [черти |nette:introduction-to-object-oriented-programming#traits].
 
 Предимството на това решение е, че всеки презентатор може да използва само чертите, от които действително се нуждае, докато в PHP не е възможно многократно наследяване.
 

best-practices/cs/@home.texy

@@ -41,6 +41,7 @@ Obecné
 - [Proč Nette nepoužívá příponu Interface? |https://blog.nette.org/cs/predpony-a-pripony-do-nazvu-rozhrani-nepatri]
 - [Composer: tipy pro použití |composer]
 - [Tipy na editory & nástroje |editors-and-tools]
+- [Úvod do objektově orientovaného programování |nette:introduction-to-object-oriented-programming]
 
 </div>
 <div>

best-practices/cs/form-reuse.texy

@@ -152,7 +152,7 @@ class EditFormFactory
 }
 ```
 
-Velmi důležité je, aby vazba mezi třídami `FormFactory` a `EditFormFactory` byla realizována kompozicí, nikoliv objektovou dědičností:
+Velmi důležité je, aby vazba mezi třídami `FormFactory` a `EditFormFactory` byla realizována [kompozicí|nette:introduction-to-object-oriented-programming#kompozice], nikoliv [objektovou dědičností|https://doc.nette.org/cs/introduction-to-object-oriented-programming#dedicnost]:
 
 ```php
 // ⛔ TAKHLE NE! SEM DĚDIČNOST NEPATŘÍ
@@ -172,7 +172,7 @@ class EditFormFactory extends FormFactory
 Použití dedičnosti by bylo v tomto případě zcela kontraproduktivní. Na problémy byste narazili velmi rychle. Třeba ve chvíli, kdybyste chtěli přidat metodě `create()` parametry; PHP by zahlásilo chybu, že se její signatura liší od rodičovské.
 Nebo při předávání závislosti do třídy `EditFormFactory` přes konstruktor. Nastala by situace, které říkáme [constructor hell |dependency-injection:passing-dependencies#Constructor hell].
 
-Obecně je lepší dávat přednost kompozici před dědičností.
+Obecně je lepší dávat přednost [kompozici před dědičností|dependency-injection:faq#Proč se upřednostňuje kompozice před dědičností].
 
 
 Obsluha formuláře

best-practices/cs/presenter-traits.texy

@@ -2,7 +2,7 @@ Skládání presenterů z trait
 ***************************
 
 .[perex]
-Pokud potřebujeme ve více presenterech implementovat stejný kód (např. ověření, že je uživatel přihlášen), nabízí se umístit kód do společného předka. Druhou možností je vytvoření jednoúčelových trait.
+Pokud potřebujeme ve více presenterech implementovat stejný kód (např. ověření, že je uživatel přihlášen), nabízí se umístit kód do společného předka. Druhou možností je vytvoření jednoúčelových [trait|nette:introduction-to-object-oriented-programming#traity].
 
 Výhoda tohoto řešení je, že každý z presenterů může použít právě ty traity, které skutečně potřebuje, zatímco vícenásobná dědičnost není v PHP možná.
 

best-practices/de/@home.texy

@@ -41,6 +41,7 @@ Allgemein
 - [Warum verwendet Nette nicht das Suffix Interface? |https://blog.nette.org/de/praefixe-und-suffixe-gehoeren-nicht-in-schnittstellennamen]
 - [Tipps zur Verwendung des Composers |composer]
 - [Tipps zu Editoren und Tools |editors-and-tools]
+- [Einführung in die objektorientierte Programmierung |nette:introduction-to-object-oriented-programming]
 
 </div>
 <div>

best-practices/de/form-reuse.texy

@@ -152,7 +152,7 @@ class EditFormFactory
 }
 ```
 
-Es ist sehr wichtig, dass die Bindung zwischen den Klassen `FormFactory` und `EditFormFactory` durch Komposition und nicht durch Objektvererbung implementiert wird:
+Es ist sehr wichtig, dass die Bindung zwischen den Klassen `FormFactory` und `EditFormFactory` [durch Komposition |nette:introduction-to-object-oriented-programming#composition] und nicht [durch |nette:introduction-to-object-oriented-programming#composition] [Objektvererbung |https://doc.nette.org/en/introduction-to-object-oriented-programming#inheritance] implementiert wird:
 
 ```php
 // ⛔ NEIN! VERERBUNG GEHÖRT HIER NICHT HIN
@@ -172,7 +172,7 @@ class EditFormFactory extends FormFactory
 Die Verwendung von Vererbung wäre in diesem Fall völlig kontraproduktiv. Sie würden sehr schnell auf Probleme stoßen. Wenn Sie z.B. der Methode `create()` Parameter hinzufügen wollten, würde PHP einen Fehler melden, dass sich die Signatur der Methode von der des Elternteils unterscheidet.
 Oder bei der Übergabe einer Abhängigkeit an die Klasse `EditFormFactory` über den Konstruktor. Dies würde zu dem führen, was wir [Konstruktorhölle |dependency-injection:passing-dependencies#Constructor hell] nennen.
 
-Im Allgemeinen ist es besser, Komposition der Vererbung vorzuziehen.
+Im Allgemeinen ist es besser, die [Komposition der Vererbung |dependency-injection:faq#Why composition is preferred over inheritance] vorzuziehen.
 
 
 Handhabung von Formularen .[#toc-form-handling]

best-practices/de/presenter-traits.texy

@@ -2,7 +2,7 @@ Zusammenstellung von Moderatoren aus Merkmalen
 **********************************************
 
 .[perex]
-Wenn wir denselben Code in mehreren Presentern implementieren müssen (z. B. die Überprüfung, ob der Benutzer angemeldet ist), ist es verlockend, den Code in einem gemeinsamen Vorgänger zu platzieren. Die zweite Möglichkeit ist die Erstellung von Single-Purpose-Traits.
+Wenn wir denselben Code in mehreren Presentern implementieren müssen (z. B. die Überprüfung, ob der Benutzer angemeldet ist), ist es verlockend, den Code in einem gemeinsamen Vorgänger zu platzieren. Die zweite Möglichkeit besteht darin, [Einzweck-Traits |nette:introduction-to-object-oriented-programming#traits] zu erstellen.
 
 Der Vorteil dieser Lösung ist, dass jeder Präsentator nur die Traits verwenden kann, die er tatsächlich benötigt, während Mehrfachvererbung in PHP nicht möglich ist.
 

best-practices/el/@home.texy

@@ -41,6 +41,7 @@
 - [Γιατί η Nette δεν χρησιμοποιεί την κατάληξη Interface; |https://blog.nette.org/el/ta-prothemata-kai-ta-epithemata-den-anekoun-sta-onomata-diasyndeses]
 - [Συμβουλές χρήσης του Composer |composer]
 - [Συμβουλές για επεξεργαστές & εργαλεία |editors-and-tools]
+- [Εισαγωγή στον αντικειμενοστραφή προγραμματισμό |nette:introduction-to-object-oriented-programming]
 
 </div>
 <div>

best-practices/el/form-reuse.texy

@@ -152,7 +152,7 @@ class EditFormFactory
 }
 ```
 
-Είναι πολύ σημαντικό ότι η σύνδεση μεταξύ των κλάσεων `FormFactory` και `EditFormFactory` υλοποιείται με σύνθεση και όχι με κληρονομικότητα αντικειμένων:
+Είναι πολύ σημαντικό ότι η σύνδεση μεταξύ των κλάσεων `FormFactory` και `EditFormFactory` υλοποιείται [με σύνθεση |nette:introduction-to-object-oriented-programming#composition] και όχι με [κληρονομικότητα αντικειμένων |https://doc.nette.org/en/introduction-to-object-oriented-programming#inheritance]:
 
 ```php
 // ⛔ ΟΧΙ! Η ΚΛΗΡΟΝΟΜΙΆ ΔΕΝ ΑΝΉΚΕΙ ΕΔΏ
@@ -172,7 +172,7 @@ class EditFormFactory extends FormFactory
 Η χρήση κληρονομικότητας σε αυτή την περίπτωση θα ήταν εντελώς αντιπαραγωγική. Θα αντιμετωπίζατε προβλήματα πολύ γρήγορα. Για παράδειγμα, αν θέλατε να προσθέσετε παραμέτρους στη μέθοδο `create()`, η PHP θα ανέφερε ένα σφάλμα ότι η υπογραφή της ήταν διαφορετική από την υπογραφή του γονέα.
 Ή όταν περνούσατε μια εξάρτηση στην κλάση `EditFormFactory` μέσω του κατασκευαστή. Αυτό θα προκαλούσε αυτό που ονομάζουμε [κόλαση του κατασκευαστή |dependency-injection:passing-dependencies#Constructor hell].
 
-Γενικά, είναι προτιμότερο να προτιμάτε τη σύνθεση από την κληρονομικότητα.
+Είναι γενικά προτιμότερο να προτιμάτε τη [σύνθεση από την κληρονομικότητα |dependency-injection:faq#Why composition is preferred over inheritance].
 
 
 Χειρισμός φόρμας .[#toc-form-handling]

best-practices/el/presenter-traits.texy

@@ -2,7 +2,7 @@
 ***********************************
 
 .[perex]
-Αν πρέπει να υλοποιήσουμε τον ίδιο κώδικα σε πολλούς παρουσιαστές (π.χ. επαλήθευση ότι ο χρήστης είναι συνδεδεμένος), είναι δελεαστικό να τοποθετήσουμε τον κώδικα σε έναν κοινό πρόγονο. Η δεύτερη επιλογή είναι να δημιουργήσουμε γνωρίσματα ενός σκοπού.
+Εάν πρέπει να υλοποιήσουμε τον ίδιο κώδικα σε πολλούς παρουσιαστές (π.χ. επαλήθευση ότι ο χρήστης είναι συνδεδεμένος), είναι δελεαστικό να τοποθετήσουμε τον κώδικα σε έναν κοινό πρόγονο. Η δεύτερη επιλογή είναι η δημιουργία [χαρακτηριστικών |nette:introduction-to-object-oriented-programming#traits] ενός μόνο σκοπού.
 
 Το πλεονέκτημα αυτής της λύσης είναι ότι κάθε παρουσιαστής μπορεί να χρησιμοποιήσει μόνο τα γνωρίσματα που πραγματικά χρειάζεται, ενώ η πολλαπλή κληρονομικότητα δεν είναι δυνατή στην PHP.
 

best-practices/en/@home.texy

@@ -41,6 +41,7 @@ Common
 - [Why Nette doesn't use the Interface suffix? |https://blog.nette.org/en/prefixes-and-suffixes-do-not-belong-in-interface-names]
 - [Composer usage tips |composer]
 - [Tips on editors & tools |editors-and-tools]
+- [Introduction to object-oriented programming |nette:introduction-to-object-oriented-programming]
 
 </div>
 <div>

best-practices/en/form-reuse.texy

@@ -152,7 +152,7 @@ class EditFormFactory
 }
 ```
 
-It is very important that the binding between the `FormFactory` and `EditFormFactory` classes is implemented by composition, not object inheritance:
+It is very important that the binding between the `FormFactory` and `EditFormFactory` classes is implemented [by composition |nette:introduction-to-object-oriented-programming#composition], not [object inheritance |https://doc.nette.org/en/introduction-to-object-oriented-programming#inheritance]:
 
 ```php
 // ⛔ NO! INHERITANCE DOESN'T BELONG HERE
@@ -172,7 +172,7 @@ class EditFormFactory extends FormFactory
 Using inheritance in this case would be completely counterproductive. You would run into problems very quickly. For example, if you wanted to add parameters to the `create()` method; PHP would report an error that its signature was different from the parent.
 Or when passing a dependency to the `EditFormFactory` class via the constructor. This would cause what we call [constructor hell |dependency-injection:passing-dependencies#Constructor hell].
 
-In general, it is better to prefer composition over inheritance.
+It is generally better to prefer [composition over inheritance |dependency-injection:faq#Why composition is preferred over inheritance].
 
 
 Form Handling

best-practices/en/presenter-traits.texy

@@ -2,7 +2,7 @@ Composing Presenters from Traits
 ********************************
 
 .[perex]
-If we need to implement the same code in multiple presenters (e.g. verification that the user is logged in), it is tempting to place the code in a common ancestor. The second option is to create single-purpose traits.
+If we need to implement the same code in multiple presenters (e.g. verification that the user is logged in), it is tempting to place the code in a common ancestor. The second option is to create single-purpose [traits |nette:introduction-to-object-oriented-programming#traits].
 
 The advantage of this solution is that each presenter can use just the traits it actually needs, while multiple inheritance is not possible in PHP.
 

best-practices/es/@home.texy

@@ -41,6 +41,7 @@ Común
 - [¿Por qué Nette no utiliza el sufijo Interface? |https://blog.nette.org/es/los-prefijos-y-sufijos-no-pertenecen-a-los-nombres-de-interfaz]
 - [Consejos de uso de Composer |composer]
 - [Consejos sobre editores y herramientas |editors-and-tools]
+- [Introducción a la programación orientada a objetos |nette:introduction-to-object-oriented-programming]
 
 </div>
 <div>

best-practices/es/form-reuse.texy

@@ -152,7 +152,7 @@ class EditFormFactory
 }
 ```
 
-Es muy importante que la unión entre las clases `FormFactory` y `EditFormFactory` se implemente por composición, no por herencia de objetos:
+Es muy importante que la unión entre las clases `FormFactory` y `EditFormFactory` se implemente [por composición |nette:introduction-to-object-oriented-programming#composition], no por [herencia de objetos |https://doc.nette.org/en/introduction-to-object-oriented-programming#inheritance]:
 
 ```php
 // ⛔ ¡NO! LA HERENCIA NO PERTENECE AQUÍ
@@ -172,7 +172,7 @@ class EditFormFactory extends FormFactory
 Utilizar la herencia en este caso sería totalmente contraproducente. Se encontraría con problemas muy rápidamente. Por ejemplo, si quisiera agregar parámetros al método `create()`; PHP reportaría un error de que su firma es diferente a la del padre.
 O al pasar una dependencia a la clase `EditFormFactory` a través del constructor. Esto causaría lo que llamamos el infierno del [constructor |dependency-injection:passing-dependencies#Constructor hell].
 
-En general, es mejor preferir la composición a la herencia.
+En general, es mejor preferir la [composición a la herencia |dependency-injection:faq#Why composition is preferred over inheritance].
 
 
 Manejo de Formularios .[#toc-form-handling]

best-practices/es/presenter-traits.texy

@@ -2,7 +2,7 @@ Composición de presentadores a partir de rasgos
 ***********************************************
 
 .[perex]
-Si necesitamos implementar el mismo código en varios presentadores (por ejemplo, verificar que el usuario ha iniciado sesión), resulta tentador colocar el código en un ancestro común. La segunda opción es crear rasgos de propósito único.
+Si necesitamos implementar el mismo código en varios presentadores (por ejemplo, la verificación de que el usuario ha iniciado sesión), resulta tentador colocar el código en un ancestro común. La segunda opción es crear [rasgos |nette:introduction-to-object-oriented-programming#traits] de propósito único.
 
 La ventaja de esta solución es que cada presentador puede utilizar sólo los rasgos que realmente necesita, mientras que la herencia múltiple no es posible en PHP.
 

best-practices/fr/@home.texy

@@ -41,6 +41,7 @@ Commun
 - [Pourquoi Nette n'utilise pas le suffixe Interface ? |https://blog.nette.org/fr/les-prefixes-et-les-suffixes-n-ont-pas-leur-place-dans-les-noms-d-interface]
 - [Conseils d'utilisation de Composer |composer]
 - [Conseils sur les éditeurs et les outils |editors-and-tools]
+- [Introduction à la programmation orientée objet |nette:introduction-to-object-oriented-programming]
 
 </div>
 <div>

best-practices/fr/form-reuse.texy

@@ -152,7 +152,7 @@ class EditFormFactory
 }
 ```
 
-Il est très important que la liaison entre les classes `FormFactory` et `EditFormFactory` soit mise en œuvre par composition et non par héritage d'objets :
+Il est très important que la liaison entre les classes `FormFactory` et `EditFormFactory` soit mise en œuvre [par composition |nette:introduction-to-object-oriented-programming#composition] et non par [héritage d'objets |https://doc.nette.org/en/introduction-to-object-oriented-programming#inheritance]:
 
 ```php
 // ⛔ NO ! L'HÉRITAGE N'A PAS SA PLACE ICI
@@ -172,7 +172,7 @@ class EditFormFactory extends FormFactory
 L'utilisation de l'héritage dans ce cas serait totalement contre-productive. Vous rencontreriez des problèmes très rapidement. Par exemple, si vous vouliez ajouter des paramètres à la méthode `create()`, PHP signalerait une erreur parce que sa signature est différente de celle du parent.
 Ou lorsque vous passez une dépendance à la classe `EditFormFactory` via le constructeur. Cela provoquerait ce que nous appelons l'[enfer du constructeur |dependency-injection:passing-dependencies#Constructor hell].
 
-En général, il est préférable de préférer la composition à l'héritage.
+Il est généralement préférable de préférer la [composition à l'héritage |dependency-injection:faq#Why composition is preferred over inheritance].
 
 
 Traitement des formulaires .[#toc-form-handling]