Pagina 6 di 6 primaprima ... 4 5 6
Visualizzazione dei risultati da 51 a 56 su 56
  1. #51
    Utente di HTML.it L'avatar di _debo
    Registrato dal
    Mar 2012
    residenza
    London, UK
    Messaggi
    858
    Beh qui possono essere utili solo se gestisci tipologie di utenza differente... ma anche in questo caso opterei per una soluzione differente.... piu' semplice e meno coesa. Per queste cose farei appunto o 1 classe user con i metodi di login etc.,... oppure la classe user la usarei solo come stdClass e quindi come struttura dati e poi la classe loginManager, sessionManager etc etc che usa le strutture dati popolate. Tutte classi atomiche e blandamente coese.

    Beh poi ognuno usi l'approccio con cui si trova piu' comodo
    In tal caso infatti per esempio utilizzerei una classe user ed una classe acl
    Ma secondo il tuo ragionamento quando le usi le abstract? visto che prediligi compositions..
    Abstraction la usi quando devi definire degli adapter, per esempio, db adapter, config adapter. In generale se puoi isolare perfettamente il ruolo delle classi e degli oggetti usa composition. Esempio tipico è quello dell'attore e del regista. Tu potresti pensare di creare un abstract person e poi estenderla per creare una classe actor ed una classe director, funziona alla grande, ma cosa fai se un attore è anche un regista? In tal caso meglio creare una classe person che implementa le interfacce actor e director. Il lato negativo nell'uso delle interfacce è che devi effettuare un ottimo design a monte, perché, se un giorno modifichi un abstract in teoria tutto funziona ancora, se modifichi un interface spacchi tutto. Ma per quello esiste unit test :-)

  2. #52
    Utente di HTML.it L'avatar di Plopper
    Registrato dal
    Mar 2012
    Messaggi
    102
    Quanto vi complicate la vita certo

    da una semplice classe siete finiti a discutere sull'utilizzo degli abstract

    comunque è pur sempre interessante

  3. #53
    Utente di HTML.it L'avatar di _debo
    Registrato dal
    Mar 2012
    residenza
    London, UK
    Messaggi
    858
    Ci si "complica" la vita prima per stare sereni poi.

  4. #54
    Utente di HTML.it L'avatar di Virus_101
    Registrato dal
    Sep 2008
    Messaggi
    2,497
    Si una buona a progettazione a monte ti risolve un sacco di casini a valle

    Per il caso specifico credo che vada benissimo anche una semplice classe user con i relativi metodi in quanto il sistema non pare troppo complesso.

    Per sviluppare sistemi riadattabili o di grosse dimensioni che abbiano cicli di vita molto lunghi. Bisogna purtroppo pensare bene prima come fare e come poi si potrà estendere il tutto e che problematiche potrebbero verificarsi .

  5. #55
    Originariamente inviato da _debo
    In tal caso infatti per esempio utilizzerei una classe user ed una classe acl

    Abstraction la usi quando devi definire degli adapter, per esempio, db adapter, config adapter. In generale se puoi isolare perfettamente il ruolo delle classi e degli oggetti usa composition. Esempio tipico è quello dell'attore e del regista. Tu potresti pensare di creare un abstract person e poi estenderla per creare una classe actor ed una classe director, funziona alla grande, ma cosa fai se un attore è anche un regista? In tal caso meglio creare una classe person che implementa le interfacce actor e director. Il lato negativo nell'uso delle interfacce è che devi effettuare un ottimo design a monte, perché, se un giorno modifichi un abstract in teoria tutto funziona ancora, se modifichi un interface spacchi tutto. Ma per quello esiste unit test :-)
    l'ideale sarebbe che php gestisse il polimorfismo.. cosa che ora si può fare solamente con le interfacce purtroppo..
    Questa volta, più che un voto.. è favoreggiamento.

  6. #56
    Utente di HTML.it L'avatar di _debo
    Registrato dal
    Mar 2012
    residenza
    London, UK
    Messaggi
    858
    Beh lo gestisce appunto con le interfaces.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2020 vBulletin Solutions, Inc. All rights reserved.