Wir haben kürzlich eine Codeüberprüfung des Java-Codes für mobile Anwendungen durchgeführt, der von einem externen Auftragnehmer entwickelt wurde, und festgestellt, dass alle Domänenobjekte / Datenübertragungsobjekte in diesem Stil geschrieben sind:
public class Category {
public String name;
public int id;
public String description;
public int parentId;
}
public class EmergencyContact {
public long id;
public RelationshipType relationshipType;
public String medicalProviderType;
public Contact contact;
public String otherPhone;
public String notes;
public PersonName personName;
}Natürlich wird auf diese Mitglieder dann direkt überall im Code zugegriffen. Als wir danach fragten, sagten uns die Entwickler, dass dies ein übliches Entwurfsmuster zur Leistungssteigerung ist, das auf mobilen Plattformen verwendet wird, da mobile Geräte ressourcenbeschränkte Umgebungen sind. Es scheint keinen Sinn zu ergeben; Der Zugriff auf private Mitglieder über öffentliche Getter / Setter scheint nicht viel Aufwand zu verursachen. Und die zusätzlichen Vorteile der Kapselung scheinen die Vorteile dieses Codierungsstils aufzuwiegen.
Ist das allgemein wahr? Wird dies normalerweise aus den oben genannten Gründen auf mobilen Plattformen durchgeführt? Alle Rückmeldungen willkommen und geschätzt -
quelle
Antworten:
Unter der Annahme, dass sich die Autoren nicht die Mühe gemacht haben, maßgebliche Referenzen zur Rechtfertigung ihrer "Entwurfsentscheidung" anzugeben, können Sie dies als einen Hirnfurz unterqualifizierter Codierer betrachten.
Ich bin seit mehreren Jahren im mobilen Java-Racket (habe immer noch einen 2- oder 3K-SO-Ruf in verwandten Tags, weil ich damit die Grundlagen nicht vergesse), habe viel Code überprüft und geschrieben, mehrere Spezifikationen, Tutorials und Stile studiert Anleitungen - keine dieser Anleitungen erwähnte jemals einen Unterschied, den dieses Design möglicherweise im Vergleich zu Java SE hätte haben können. Wenn Sie daran interessiert sind, solche Tutorials und Anleitungen selbst zu finden, überprüfen Sie die SO-Tag-Wikis in relevanten Tags wie Java-Me , Midp usw.
quelle
In der Behauptung Ihres Auftragnehmers steckt ein Körnchen Wahrheit .
Für einige Zeit wurden Android-Spieleentwickler aufgefordert, interne Getter und Setter aus Leistungsgründen zu vermeiden . Dieser Rat gilt jedoch nur für Spieleentwickler, die Geräte an ihre Grenzen bringen müssen und andere Vorteile opfern müssen , um ihre Ziele zu erreichen. Mit der Veröffentlichung von Gingerbread profitiert dieses Spiel sogar wenig von dieser Praxis.
Mehr als einmal habe ich Entwickler getroffen, die "Best Practice" -Ratschläge gaben oder Richtlinien befolgten, die in einem Szenario (oft historisch) vollkommen gültig sind, aber einfach nicht auf den vorliegenden Fall zutreffen. Meistens liegt dies daran, dass der Entwickler die Gründe, warum sein Rat überhaupt angewendet wurde, vergessen hat (oder nie wusste) , sodass er davon ausgeht, dass er für alle Fälle jederzeit gültig sein muss. Nach meiner Erfahrung ist dies besonders häufig bei der Erörterung der Leistungsoptimierung der Fall. Das scheint hier der Fall zu sein.
Der richtige Ansatz für die Leistung ist:
quelle
Sie haben Recht, dass dies für sich genommen wahrscheinlich keinen signifikanten Leistungsunterschied darstellt, aber wenn dies ein Zeichen dafür ist, dass die Entwickler im Allgemeinen die Anzahl der Methodenaufrufe (die relativ teuer sind) und anderen Overhead im Auge behalten, bedeutet dies Sie machen einen guten Job.
Ich würde mit ihnen ausführlicher über ihre allgemeine Codierungsphilosophie sprechen, um zu sehen, ob dies das ist, was sie anstreben.
(Sie gehen auch davon aus, dass öffentliche Felder zweifellos schlecht sind und Getter / Setter der einzige Weg sind, für den Sie meiner Meinung nach selbst auf dieser Website keine 100% ige Unterstützung finden würden.)
quelle
Es mag wahr sein, dass es historisch so gemacht wurde; zB weil frühere mobile Plattformen besonders ressourcenbeschränkt sind ... oder besonders schlechte Optimierer haben (keine Namen nennen :-)).
Aber ich denke nicht, dass "übliche" oder "historische Praxis" relevant ist. Sie haben das uneingeschränkte Recht zu sagen, welche Codierungsstandards Ihr Auftragnehmer einhalten soll. Außerdem, wenn Ihre Plattform nicht ressourcenbeschränkt ist (oder was auch immer), ist die Begründung Ihres Auftragnehmers "übliche Praxis" leer ... weil die Bedingungen, die diese unglückliche Praxis akzeptabel machen, nicht existieren.
quelle
Bei Domänenobjekten handelt es sich um Müllentwurf. Sie möchten, dass die Logik in den Domänenobjekten gekapselt ist, oder Sie möchten zumindest später problemlos Logik hinzufügen können .
Aber für DTOs verwende ich ein ähnliches Design, da sie keine Logik haben - sie sind DTOs.
Ich würde davon ausgehen, dass jeglicher Leistungsaufwand (der ohnehin winzig wäre) ohnehin von der virtuellen Java-Maschine optimiert wird.
quelle