Qual è l'API migliore: table.add_row () o table.rows.add ()?

Se tutto ciò che stai facendo è mappare i comandi API di Word, potresti non fornire alcun valore effettivo solo tramite lo spooling di un'istanza di winword.exe e utilizzando l'API su COM . Quindi, dovresti considerare che cosa stai cercando di raggiungere.

1. Se stai provando a sostituire le chiamate COM con un'implementazione nativa , dovresti essere il più vicino possibile all'API sottostante. Sarebbe utile poter invocare una libreria di processo uguale per generare il WordML appropriato come archivio XML o ZIP'd (ovviamente rinominato in DOCX, ovviamente), ma se lo fai non c'è alcun valore in deviando dall'API esistente .

2. Se invece stai provando a semplificare il processo di creazione o popolamento di un documento di Word in Python, la tua API dovrebbe essere focalizzata sul caso d'uso presentato piuttosto che replicare ciò che fornisce Word . Ci sono molti concetti nel modello di Word che hanno senso solo a causa delle peculiarità della parola e non sono necessari se si sta compilando un "modulo" basato su campi o aggiungendo più paragrafi o aggiungendo righe da alcuni dati query. In generale, dovresti implementare i tuoi metodi e copiare l'interfaccia di Word solo quando necessario .

Personalmente, sono un grande fan dei metodi di attività di livello superiore, come il tuo metodo Table.add_row() proposto, che fornisce funzionalità aggiuntive. Essere in grado di chiamare add_row e passarlo i valori per quella riga sarebbe utile, specialmente se si potesse astrarre un metodo add_rows per creare una tabella da una matrice bidimensionale o un costrutto simile.

In genere è più semplice gestire un sistema gerarchico di cose che una struttura piatta quando ce ne sono più di una. I tuoi due metodi non rivelano questo, ce ne sono solo due. Ma hai anche bisogno di delete_column, move_column, sort_column, column_width, column_border e così via, più lo stesso per le righe ...

Sospetto che scoprirai che c'è un grande albero di proprietà e metodi collegati al tavolo. E solo le proprietà saranno una lista abbastanza lunga. Probabilmente avrà categorie di proprietà: aspetto, struttura, comportamento e altro ancora. Ogni proprietà avrà metodi e proprietà proprie. Migliaia di loro, con ogni probabilità.

La combinazione di nodi come questi, più i collegamenti tra di loro (i punti, in questa notazione - così il nodo "tabella" si collega a "colonna") ti dà un grande, complesso grafico. Si noti che il grafico potrebbe avere loop e altre cose, non è solo un albero. Il che significa che potrebbe non essere nemmeno possibile appiattirlo nel modo in cui stai pensando.

Ad esempio, la tabella, la colonna, la cella hanno tutti una proprietà font. E i caratteri hanno una proprietà in grassetto. Quindi, quante proprietà "in grassetto" avrà la lista appiattita?

Questa è una delle cose che il design orientato agli oggetti ha iniziato a cercare di risolvere, BTW - "cose" nel codice che hanno entrambi gli attributi (grassetto) e il comportamento (add_row). Le relazioni in questo caso sono solo attributi "ha un" (riferimenti e puntatori) o "è un" (ereditarietà).