Μαλλον εγώ δεν πιάνω κατι, αλλά όταν λες χωρίς condition; Πως θα δεις εάν το flag έχει τιμή false ή οχι; Εννοώ μέσα σε Lambda statement το !flag πχ ή το flag == false κλπ, δεν παίζει σαν σενάριο;

Γιατί έγραψα κάτι, αλλά με τον παραπάνω τρόπο.

Εγώ πάλι δεν καταλαβαίνω τι χρειάζεται το flag και ο private delegate func. Έτσι κι αλλιώς δεν υπάρχει default (parameterless) constructor και, αν δεν κάνω λάθος, η παραπάνω κλάση μπορεί να γραφτεί:

public class Thunk<T>

   {

       private T value;

       public T Value

       {

           get

           {

               return value;

           }

       }

       public Thunk(Func<T> func)

       {

           this.value = func();

       }

   }

Α μάλιστα, τώρα κατάλαβα.. Αν και τώρα νυστάζω οπότε θα το δω αύριο.. Τόσο απλό αλλά τόσο ενδιαφέρον.

Το να εκτελέσεις την func στον constructor παρότι δείχνει βολική λύση είναι διαφορετική υλοποίηση από την δοθείσα αρχική,διότι λογικά δε θα θέλουμε να εκτελεστεί ο κώδικας της func παρά μόνο όταν ζητήσουμε για πρώτη φορά την τιμή της Value.

Το πρόβλημα με τη συνθήκη της άσκησης να μη χρησιμοποιήσουμε καθόλου conditional logic είναι ότι conditional logic κρύβεται σε πολλά σημεία.Π.χ αν στην υλοποίησή μας χρησιμοποιούσαμε foreach θα μέτραγε για conditional logic (παρεπιπτόντως μέσω αυτής βρήκα την πρώτη μου υλοποίηση,η δεύτερη που σκέφτηκα είναι λίγο πιο μακροσκελής και χρησιμοποιεί περισσότερο funcional programming από ότι η δοθείσα αρχική κλάση).

Το να εκτελέσεις την func στον constructor παρότι δείχνει βολική λύση είναι διαφορετική υλοποίηση από την δοθείσα αρχική,διότι λογικά δε θα θέλουμε να εκτελεστεί ο κώδικας της func παρά μόνο όταν ζητήσουμε για πρώτη φορά την τιμή της Value.

Το πρόβλημα με τη συνθήκη της άσκησης να μη χρησιμοποιήσουμε καθόλου conditional logic είναι ότι conditional logic κρύβεται σε πολλά σημεία.Π.χ αν στην υλοποίησή μας χρησιμοποιούσαμε foreach θα μέτραγε για conditional logic (παρεπιπτόντως μέσω αυτής βρήκα την πρώτη μου υλοποίηση,η δεύτερη που σκέφτηκα είναι λίγο πιο μακροσκελής και χρησιμοποιεί περισσότερο funcional programming από ότι η δοθείσα αρχική κλάση).

@darklynx: Δικό μου σφάλμα. Έχεις απόλυτο δίκιο. Υπό διαφορετικές συνθήκες ενδέχεται η μέθοδος που καλεί ο delegate να επιστρέψει διαφορετική τιμή για το ίδιο όρισμα, οπότε και η Value πρέπει να παίρνει την τιμή της όταν της ζητηθεί. Αυτό, όμως, δεν είναι λίγο επικίνδυνο; Ακόμα και μια φαινομενικά αθώα αντιστροφή της σειράς εκτέλεσης του κώδικα μπορεί να δώσει απρόσμενα αποτελέσματα αν μεταβάλει, για παράδειγμα, τιμές global παραμέτρων οι οποίες, όμως, χρησιμοποιούνται στην εν λόγω συνάρτηση. Πιο ασφαλές δεν είναι να δημιουργείται το object τη στιγμή που χρειάζεται και να υπολογίζεται η τιμή του property; Αυτό το σχόλιο, βέβαια, είναι ανεξάρτητο από το puzzle.

@Markos: Εξαρτάται αν η μόνη δουλειά που κάνει η κλάση είναι να μας δίνει την τιμή της Value.Φαντάσου όμως η κλάση να έχει και επιπλέον λειτουργικότητα και ακόμα ο delegate που περνάμε στον contructor να παράγει σημαντικό φόρτο στο σύστημα,τότε έχουμε κάθε λόγο να αναβάλλουμε τον πρώτο υπολογισμό της value (να ακολουθήσουμε τρόπο τινά μια lazy προσέγγιση στο σχεδιασμό της κλάσης).

Τελικά βρήκα καμιά 4αρια προσεγγίσεις επί του ζητούμενου και μάλλον το παράκανα :P.Ορίστε οι δυο πρώτες,που αν και αισχρές ως σύλληψη δουλεύουν κατά το αναμενόμενο:

class Solution1<T>

   {

       private T value;

       private List<Func<T>> execList;

       public T Value

       {

           get

           {

               foreach (Func<T> func in execList)

                   value = func();

               execList.Clear();

               return value;

           }

       }

       public Solution1(Func<T> func)

       {

           execList = new List<Func<T>>();

           this.execList.Add(func);

       }

   }

class Solution2<T>

   {

       private T value;

       private Func<T> func;

       public T Value

       {

           get

           {

               value = func();

               func = () => { return value; };

               return value;

           }

       }

       public Solution2(Func<T> func)

       {

           this.func = func;

       }

   }

Και τι κακό έχουν οι μέθοδοι; Φτιάχνεις το object όποτε θες και τις καλείς όποτε θες. Κατά τη γνώμη μου, έτσι όπως είναι γραμμένος ο αρχικός κώδικας, ακόμα και ένα απλό refactoring μπορεί να δημιουργήσει απρόβλεπτες καταστάσεις. Θα είναι δύσκολο να διαγνώσεις το πρόβλημα όταν έχεις μια property που η τιμή της γίνεται finilized ύστερα από την πρώτη κλήση.

Η δεύτερη λύση πάντως είναι πιο όμορφη. Περιμένουμε να δούμε τι έστειλε ο Νίκος.

Λύση βασιζόμενη σε Finite State Machine (καθώς δεν γνωρίζω F# ο κώδικας μπορεί να μην είναι συντακτικά ορθός).

Ενεργή κατάσταση: func

Δυνατές καταστάσεις: func_user, func_default

public class Thunk <T>

{

   private T value;

   private Func <T> func;

   private Func <T> func_user;

   private Func <T> func_default;

   private Func <T> func_user_core;

   {

       func  = func_user ( );

       return value;

   }

   private Func <T> func_user ( )

   {

       func  = func_default ( );

       value  = func_user_core ( );

       return value;

   }

   private

   public T value

   {

       get

       {

           return func ( );

       }

    }

   public Thunk ( Func <T> func )

   {

       func_user_core = func;

       this.func  = func_user;

   }

}