La stesura grafica di una GUI dovrebbe essere considerata "barare"?

Ho un amico che ha una quantità leggermente maggiore di esperienza di programmazione come me. Stavamo parlando di tutte le diverse tecnologie di programmazione che utilizziamo e Interface Builder è emerso in una conversazione.

Non avendo alcun background di programmazione, tranne per quello che ho insegnato a me stesso, credo personalmente che IB e tutte le sue caratteristiche ( IBOutlets, IBActions) aiutino i programmatori del mio livello di abilità (e tutti i livelli di abilità, per quella materia) a completare i loro progetti in meno tempo.

La sua visione di IB è un po 'entusiasta. Crede che i programmatori che utilizzano Interface Builder stiano "tradendo" il fatto che non devono disporre manualmente le interfacce.

Domanda:

L'uso di un generatore di GUI per disporre gli elementi dell'interfaccia dovrebbe essere considerato "imbroglione" (dal momento che la maggior parte della programmazione inizialmente richiedeva la disposizione manuale delle interfacce nel codice)? Perché?

Non è barare. Programmi come IB sono strumenti. Usa quello giusto per il lavoro. Non è necessario essere dogmatici al riguardo.

Se sei più efficace usando un tale strumento, usalo. L'unica avvertenza è che dovresti imparare i compromessi quando prendi le tue decisioni. Fare layout a mano ti dà un controllo preciso a scapito della facilità di trascinamento della selezione. Gli strumenti di trascinamento della selezione ti consentono di eseguire molte operazioni in modo rapido e semplice, ma potrebbero rendere il tuo codice più difficile da mantenere nel tempo.

Personalmente, non ho mai avuto successo o tratto molto piacere dall'utilizzo di uno strumento di progettazione dell'interfaccia utente con trascinamento della selezione, ma sono solo io. Trovo che la disposizione manuale delle GUI sia la più efficace per me e produce una base di codice che è più facile da mantenere nel tempo. Altri hanno l'esperienza opposta.

La programmazione come lavoro non è uno sport né un gioco. Quindi l'argomento barare è molto sottile. Se gli strumenti visivi aumentassero la tua produttività, saresti stupido a non usarli. La mia esperienza è che questi mi fanno passare più tempo sull'effettivo codice per la risoluzione dei problemi senza dover ricorrere ripetutamente alla banale interfaccia.

Attenzione però, è facile che impostazioni o dati si insinuino nell'interfaccia. Sii radicale nel mantenere separate la presentazione e la logica.

Imbroglia solo se stai sacrificando qualcosa per arrivarci. La maggior parte dei layout della GUI genera semplicemente il codice che creeresti comunque (e spesso deve essere modificato manualmente poiché il layout non è sufficiente).

Quindi sostanzialmente no.

A parità di tutti gli altri, qualsiasi strumento che ti consente di fare la stessa cosa più velocemente è buono.

Barare è il nome del gioco. Dovresti sempre prendere la strada più semplice che puoi quando prendi qualsiasi tipo di decisione di sviluppo. Chiamalo barare, chiamalo "essere produttivo"; non fa differenza. Dovresti scegliere lo strumento che ti aiuta a fare il lavoro con il minimo sforzo (ovviamente, non dimenticare di manutenzione e scalabilità).

Ora, in particolare con IB, dovresti soppesare il tempo risparmiato da IB rispetto al costo di dover mantenere un codice più scadente e di cui hai meno familiarità. Questo è davvero un caso per caso e persona per persona tipo di decisione. In molti casi, strumenti e procedure guidate ti consentono di svolgere molto più lavoro con un basso costo di manutenzione aggiunto ... e a volte introducono codice slop e astrazione più permeabile di quanto tu sappia cosa fare. Sembra che tu abbia preso la decisione per te stesso che IB vale tutti i costi che aggiunge allo sviluppo, tuttavia, il tuo amico potrebbe altrettanto facilmente scoprire che lo strumento lo ostacola più di quanto non aiuti.

Diavolo, no. Farlo interamente a mano, tuttavia, è un chiaro caso di lavoro inutile per te stesso.

(Generalmente lo farei usando un builder e se fosse necessaria una messa a punto, tende - ma non sempre - a fare a mano).

Non è certo un imbroglio, anche se avrei un po 'meno rispetto per uno sviluppatore che non avrebbe potuto disporre di una GUI senza. IMO, l'utilizzo di uno non è diverso dall'uso di un tipo di dati fornito dal sistema: perché implementare il proprio elenco di collegamenti o mappa hash se è possibile utilizzarne uno dalla libreria di sistema?

FWIW un paio di mesi fa ho dovuto implementare un'interfaccia utente in Java Swing. Non l'avevo mai usato, quindi ho scritto tutto a mano per capire meglio come funzionava. Ora che conosco l'API di base, non potrò mai più scriverne una a mano se posso aiutarla!

Come afferma @Bryan Oakley , è solo uno strumento e non un "imbroglione". Dipende tutto da cosa stai esattamente proponendo. Se a mano lo rende un esercizio incredibilmente laborioso, allora dovresti davvero cercare altre alternative che ti rendano più produttivo.

Una volta ero nel campo della mano che codificava l'interfaccia, ma più tardi dopo un attacco di interfacciamento ho preso una freccia fino al ginocchio e ho avuto un'opinione diversa. Se posso e mi rende più produttivo, utilizzare uno strumento grafico per strutturare la GUI.

Ultimamente usando il modello MVVM, con la distinzione di View e ViewModel, rende un po 'più chiaro quando useresti gli strumenti grafici. Phil Haack ne discute brevemente nell'episodio di Github per Windows del podcast di Herding Code quando gli viene chiesto del passaggio dallo sviluppo Web a quello delle applicazioni. È più sensato eseguire ViewModel con la codifica "a mano" e consentire al progettista di creare graficamente la vista (e collegare i ViewModel di conseguenza).

Uno dei grandi vantaggi di strumenti come Interface Builder è che consentono di separare il lavoro di progettazione dell'interfaccia utente dall'implementazione del programma. Qualcuno con abilità di codifica minime può facilmente cambiare il layout dell'interfaccia utente, cambiare le didascalie dei pulsanti e dei menu, tradurre l'interfaccia utente in una lingua diversa, ecc.