Decorator and Command PHP pattern

[slevinkelevra]

Καλησπερα

 

PHP patterns...Whats up with them , right? *crickets....*

 

Διαβαζω για τα pattern στη PHP και εχω καποιες αποριες σχετικα με την υλοποιηση τους.

 

Στο  Site: decorator pattern ,στο κομματι  Wrapping It All Together

 

οριζει ενα γενικο interface και μετα μια κλαση που το υλοποιει , η οποια by default κανει echo το Τhis is Main Email body

 

μετα οριζει τον decorator για να εχει προσβαση στη κλαση eMailBody . Με την constructor λεει οτι κατασκευαζει μια νεα eMailBody συμφωνα με την eMailBody  που του περασες. 

 

ΟΚ. Το 

abstract public function loadBody();

τι ακριβως σημαινει? Ειναι μια γενικη αναφορα στην loadBody της κλασης eMailBody ? Τι σημαινει αυτη η συνταξη, δεν την εχω ξαναδει.

 

 

~~~ Σχετικα με το command pattern ~~~

 

 

Στο  Site: command pattern , στο κομματι Putting It All Together

 

Η radioControl περιεχει τις εργασιες που οντως ανοιγουν η κλεινουν το ραδιο.

 

Η radioCommand ειναι ενα interface

 

Οι turnOnRadio / turnOffRadio υλοποιουν αυτο το interface και ουσιαστικα καλουν τις "εργασιες" της radioControl 

 

Ο client αποφασιζει να κλεισει το ραδιο , $ in = 'turnOffRadio'; για το παραδειγμα το βαζει σταθερη τιμη

 

Απο κει και μετα χανω τη μπαλα, παλι δεν εχω ξαναδει τετοια συνταξη.

Υποθετω οτι απο τη στιγμη που η τιμη του $ in ειναι ιδια με το ονομα μιας radioCommand (turnOnRadio / turnOffRadio ) - και θα πρεπει να ειναι παντα ιδια, αλλιως δε θα καλει τιποτα

τοτε

$command = new $in ( new radioControl () );

η command ειναι μια νεα κλαση turnOffRadio.

 

Βασικα γιατι να βαλεις μετα new radioControl μεσα στη  construct ? Αφου ενα radioControl  εχεις, βαλτο να ειναι η default τιμη της construct και αστο να δημιουργειτε αυτοματα, χωρις να περνας new radioControl. 

Και στη τελικη, εχει καποια τιμη το new radioControl εδω ή αλλαζει κατι?

 

Αν ειχα δηλαδη

public function __construct(radioControl) {
        $this->radioControl = radioControl;    }

που θα ηταν το λαθος?

 

Ευχαριστω πολυ

[defacer]

Μάλλον πρέπει να διαβάσεις και από κάτι καλύτερο γιατί το θέμα ειδικά με τα patterns είναι να καταλάβεις τι και πώς, όχι η ακριβής υλοποίηση. Παρόλο που γενικά οι υλοποιήσεις μοιάζουν μεταξύ τους, το όλο νόημα του pattern είναι να κρατήσεις τη γενική ιδέα και να μπορείς να κάνεις μια υλοποίηση κατάλληλη για τη συγκεκριμένη περίπτωση.

 

Για το abstract class και function δεν ξέρω τι να πω που δεν έχει γραφτεί ήδη άπειρες φορές, αλλά τέλος πάντων abstract function σημαίνει ότι υποχρεωτικά οποιαδήποτε derived class δεν είναι επίσης abstract θα πρέπει να την υλοποιεί.

 

Στην προκειμένη περίπτωση η decorator class (όπως επίσης και η "κανονική" email) πρέπει αναγκαστικά να κάνουν implement το interface και παντού τα πάντα να γίνονται in terms of that interface, διαφορετικά εκτός των άλλων δε θα μπορέσεις να υλοποιήσεις το pattern. Αλλά η decorator class δεν έχει νόημα να κάνει implement το interface γιατί τότε θα έπρεπε να γράφεις κάθε ένα email decorator που χρειάζεσαι από την αρχή. Οπότε πρέπει ταυτόχρονα και να το κάνει και να μην το κάνει implement, παράδοξο το οποίο ξεπερνάς κάνοντάς και την class και τη method abstract.

 

------

 

Για το command pattern το κλειδί είναι αυτό που λες "αφού ένα radioControl έχεις". Says who? Αυτή τη στιγμή έχω ένα, αύριο αν έχω δύο τι θα γίνει;

 

Technically θα μπορούσες να κάνεις hardcode το ένα και μοναδικό radioControl και πάλι θα ήταν command pattern, αλλά αυτό γενικά (όχι μόνο σαν command) είναι τελείως στραβή προσέγγιση γιατί πρακτικά είναι αδύνατον να φτιάξεις κάτι χρήσιμο έτσι.