`име ()` срещу `getName () наименование конвенция? - java, oop, naming-conventions

Виждал съм някои проекти (например KR), които използват тази нова конвенция за наименуване на сетер / сетер:

String name()
void   name(String value)

вместо старата конвертираща конверсия:

String getName()
void   setName(String value)

Какви са положителните и отрицателните аспекти на всяка конвенция за именуване? Кога и защо смятате, че човек трябва да бъде предпочитан пред другия?

Отговори:

Първият пример не се придържа към JavaBeans спецификация [Предупреждение PDF]. Има определени рамки като пролетта, които приемат тази конвенция за наименуване, особено когато правите нещо в EL като ${object.name}, която се превежда в object.getName(), Това ще се провали, ако не следвате конвенциите за именуване (въпреки че има начини да го заобиколите).

Без да се обсъждате кога / акода се използват getters / setters, по принцип е по-добре да се придържате към конвенцията за именуване, тъй като има по-малко изненади по този начин, особено когато се интегрирате с библиотеки или рамки на трети страни, които очакват нещата да бъдат наименувани според конвенцията.

Нищо освен четливост и API стил.

Някои приложни програмни интерфейси (API) приемат този стил и някои не го харесват Spring injections и JSF не могат да разпознаят този синтаксис (те изрично изискват получаване / задаване на свойства).

Харесва ми просто да го използвам name() когато обектът, с който се занимавам, е неизменна, т.е. никога няма да променя стойността на name област. Когато се занимавам с обект, който може да бъде променян, бих използвал втората конвенция, която споменахте, просто защото мисля, че е по-добра от гледна точка на разбираемостта.

Винаги предпочитам да го използвам глаголи за името на методите, така че това важи и за получателите и създателите.

използвам съществителни само за променливи.

Следвайте класическия стандарт JavaBean, за да се почувствате по-комфортно. :)

Предпочитам да използвам по-краткия стил, ако библиотеката е на ниско ниво и искам да ви обясня, че този компонент не е JavaBean.

Ако се съмнявате, бих използвал стил JavaBean.