Begründung für das Design von UITableViewDataSource

Question

Ich entwerfe eine API-Schnittstelle für einen Magazin-Viewer. Etwas wie iGizmo (für iPad). Die Ansicht, in der ein Magazin angezeigt wird, ist einer TableView sehr ähnlich. Wie man Artikel als Abschnitte und Seiten als Zellen denken kann.

Aus diesem Grund möchte ich DataSource & Delegate in der gleichen Weise verfügbar machen, wie UITableView tut. Ich bin mir jedoch nicht ganz sicher, warum Apple TableView deligate/DataSource so entworfen hat, dass es immer den TableView als Parameter in jeder Methode zur Verfügung stellt.

Ich habe versucht, es zu rationalisieren, und ich fand keine gute Entschuldigung für solche api Design. Ich überlege, den Parameter tableView/magazineView in meiner API wegzulassen.

Sehen Sie gute Gründe für ein solches API-Design?

Wäre es nicht einfacher und klarer, Methoden wie die folgende zu schreiben?

– cellForRowAtIndexPath: 
– numberOfSections 
– numberOfRowsInSection: 
– sectionIndexTitles 
– sectionForSectionIndexTitle:atIndex: 
– titleForHeaderInSection: 
– titleForFooterInSection: 

Answer 1

Interessante Frage. Während dies eine Vermutung ist, vermute ich, dass es da ist, so dass eine einzelne Datenquellenklasse der Delegat für mehrere Tabellenansichten mit unterschiedlichen Anforderungen sein kann. (z. B .: Sie kann das bereitgestellte tableView überprüfen und entsprechend reagieren.)

Wenn Sie diese Anforderung nicht voraussehen, können Sie höchstwahrscheinlich den entsprechenden Parameter aus Ihren Methodensignaturen weglassen.

Dann, wenn es überhaupt möglich ist, dass Sie vielleicht auf die "rufende" magnarview zugreifen möchten, könnten Sie den Parameter einfach dort lassen - es ist nicht so, als ob die Übergabe eines Zeigers unglaublich Ressourcen-ineffizient ist.