имена методов с удобным интерфейсом

Question

У меня есть класс 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)

Answer 1

set{Property} лучше, чем просто {свойство} для передачи намерения. Однако, поскольку ваши примеры являются простыми булевыми свойствами, может быть даже лучший свободный интерфейс:

somePermissions.AllowRead().DenyWrite().AllowExecute();

Answer 2

Это классическая проблема с беглыми интерфейсами. Хотя я согласен с @Bozho, что setRead () более понятен, цель в свободно распространяемых интерфейсах - сделать целое «предложение» читабельным, а не делать читаемыми отдельные вызовы методов.

Таким образом, я бы пошел дальше. Как насчет:

somePermissions.readable().nonWritable().executable()

См. Также пост Мартина Фаулера об этой теме. Он говорит: «Создание такого плавного API приводит к некоторой необычной привычке API»

Answer 3

set{Property} определенно. Он рассказывает, что делает метод. Представьте, что ваша собственность называется visible или encoding или algorithm. Не использовать set не имеет никакого смысла.

Вы можете использовать более описательные имена действий, которые отличаются от имени свойства. Например:

visible -> show(..)
encoding -> encode(..)
read> makeReadable(..)
name -> giveName(..) («имя» - глагол, но неоднозначный)

Answer 4

set явно мешает ясности. На самом деле они не похожи на бобы, поэтому я говорю: брось.

Я бы также предложил отделить строителя от продукта. Предпочитают неизменность в продукте.

Если у вас есть флаги, я думаю, что гораздо лучше использовать логические значения, а не пары методов. В библиотеке Java это изменение изменилось с 1.0 на 1.1. Тем не менее, я все еще не люблю логические значения. В true и false не так много смысла более высокого уровня. enum лучше. Еще лучше, если вы говорите о чем-то, что можно считать набором (как в примере), тогда используйте Set (возможно, реализовано как EnumSet).