В моей библиотеке (DLL) есть расширения для List, подобные следующему.
<Runtime.CompilerServices.Extension>
Public Sub Store(Of TVal As IFullyOperable)(items As List(Of TVal), w As BinaryWriter, closeAfter As Boolean)
Try
w.Write7BitEncodedInt(items.Count)
items.ForEach(Sub(i) i.Store(w))
Catch ex As Exception
Throw
Finally
If closeAfter Then w.Close()
End Try
End Sub
IFullyOperable
- публичный интерфейс, который должен быть реализован в классах, чтобы сделать их пригодными для обработки моей библиотекой.
Пока у меня есть флаг closeAfter
в большинстве вызовов False
, но я сомневаюсь, может лучше использовать leaveOpen
как в конструкторе BinaryWriter
из dotNet?
Использование leaveOpen
приведет к избыточным инверсиям, но сделает код более похожим на часть dotNet, и может улучшить удобство использования, или нет?
Каковы соображения по поводу использования обоих вариантов?
Для вариантов, подобных тому, который вы упомянули, наиболее важным соображением является когнитивная нагрузка, которую несет с собой каждый вариант. Это когнитивная нагрузка как для тех, кто поддерживает функцию, так и когнитивная нагрузка для пользователей функции.
Вам необходимо найти точку равновесия между тем, насколько легко случайно интерпретировать параметр неверно при чтении или внесении изменений в функции, и тем, насколько легко случайно передать неверное значение параметру при вызове функции.
Если в экосистеме .Net существует устоявшийся шаблон для параметра с семантикой leaveOpen
, то это уже само по себе является хорошим аргументом в пользу того, чтобы следовать этому шаблону, поскольку это приведет к меньшей путанице для ваших пользователей. Если эффект для вашего кода также будет всего лишь простым not
, то влияние на когнитивную нагрузку для ваших пользователей значительно перевесит когнитивную нагрузку для ваших сопровождающих.