имена методов с быстрым интерфейсом
У меня есть a Permissions класс в Java с методами в быстром стиле как это:
somePermissions.setRead(true).setWrite(false).setExecute(true)
Вопрос, должен ли я назвать эти методы set{Property} или только {property}. Последний был бы похож на это:
somePermissions.read(true).write(false).execute(true)
Если бы я смотрю на эти методы отдельно, я ожидал бы это read чтения что-то, но с другой стороны это ближе к намерению иметь что-то как именованные параматери как в Scala:
Permission(read=true, write=false, execute=true)
4 ответа
set {Property} лучше, чем просто {property} для передачи намерений. Однако, поскольку ваши примеры являются простыми логическими свойствами, еще более плавным интерфейсом может быть:
somePermissions.AllowRead().DenyWrite().AllowExecute();
Это классическая проблема с плавными интерфейсами. Хотя я согласен с @Bozho, что setRead () более понятен, цель свободных интерфейсов - сделать все "предложение" читаемым, а не делать отдельные вызовы методов читаемыми.
Таким образом, я бы пошел еще дальше. Как насчет:
somePermissions.readable().nonWritable().executable()
См. Также сообщение Мартина Фаулера по этой теме. Он говорит: «Создание такого плавного API приводит к некоторой необычной привычке к API»
set{Property} определенно. Он сообщает, что делает метод. Представьте, что ваше свойство называется visible или encoding или algorithm. Неиспользование set не будет иметь никакого смысла.
Вы можете использовать более описательные имена действий, которые отличаются от имени свойства. Например:
visible -> show(...)
encoding -> encode(...)
read > makeReadable(...)
name -> giveName(...) ("name" - глагол, но неоднозначный)
Набор set явно мешает ясности. Это не совсем бобовый метод, поэтому я предлагаю отказаться от него.
Я бы также предложил отделить конструктор от продукта. Предпочтите неизменяемость в продукте.
Если у вас есть флаги, я думаю, что гораздо лучше использовать булевы, а не пары методов. Библиотека Java внесла это изменение при переходе от версии 1.0 к версии 1.1. Однако мне по-прежнему не нравятся булевы. В true и false не так много смысла более высокого уровня. enum лучше. Еще лучше, если вы говорите о чем-то, что можно считать множеством (как в примере), тогда используйте Set (возможно, реализованный как EnumSet).