Какое поведение вы ожидаете/используете при инициализации объектов?

[WMix]

Если вы косячите с указанием необязательных параметров, какое поведение лично вы ожидает от класса/пакета? Если сократить варианты ответов до двух: - fast-fail или молчаливое исполнение.

если ты переводишь деньги и не указываешь кому переводить, какое поведение ожидаешь?
если ты видишь вопрос с возможностью ответить одновременно и да и нет, кто виноват?

 

[kudashevs]

Ну это как не вопрос программирования, а вопрос постановки задачи. Если надо чтобы сообщалось пользователю - так сообщайте, если нет, то не надо

Постановка задачи не ясна. Это и есть фактически попытка понять, какие есть требования к необязательным параметрам. То есть с обязательными параметрами все ясно, что-то не то пришло, fast-fail без каких-либо исключений. А вот с необязательными мне не совсем ясно, потому что я встречал три варианта поведения, и два из них, это молчаливое исполнение при неправильных параметрах.

Суть это поста, желание понять, какое поведение программисты ожидают от среднестатистического пакета где используются необязательные параметры (опции).

 

[kudashevs]

если ты переводишь деньги и не указываешь кому переводить, какое поведение ожидаешь?

Сумма перевода и лицо получающее это обязательные параметры (критичные для бизнес логики), поэтому при неправильном указании ожидаю fast-fail. А вот если есть необязательный параметр, например сообщение (по умолчанию переведено от пользователя такого-то такого-то числа) и в него был передан мусор. Вы какое поведение ожидаете?

 

[WMix]

если заходишь в магазин и произносишь обязательные параметры "мне бутылочку вина", и не обязательные "2000 года, шато марго, из бургундии", а продается только молдавское, что делает продавец?

 

[kudashevs]

если заходишь в магазин и произносишь обязательные параметры "мне бутылочку вина", и не обязательные "2000 года, шато марго, из бургундии", а продается только молдавское, что делает продавец?

Зависит от продавца Хороший продавец попробует впарить молдавское.

 

[WMix]

Зависит от продавца Хороший продавец попробует впарить молдавское.

вот и выбирай какой ты продавец, пожелаю, чтоб тебе на пути попадались только хорошие продавцы

 

[kudashevs]

вот и выбирай какой ты продавец

Когда писал ответ, понял что не совсем точная аналогия. Правильнее была бы аналогия: если заходишь в магазин и произносишь обязательные параметры "мне бутылочку вина", и не обязательные "балтику 9". Но мы точно знаем, что человек хочет вина

 

[Yoskaldyr]

Дополнительные параметры лучше передавать объектом, а не массивом. И типизация, и нельзя мусор передать и при правильном объекте параметров в принципе нельзя допустить ошибку со стороны пользователя, все будет разруливаться на уровне языка

 

[WMix]

Но мы точно знаем, что человек хочет вина

не уверен

 

[kudashevs]

Дополнительные параметры лучше передавать объектом, а не массивом. И типизация, и нельзя мусор передать и при правильном объекте параметров в принципе нельзя допустить ошибку со стороны пользователя, все будет разруливаться на уровне языка

Спасибо за ответ. 2-0 в пользу fast-fail, но только через дополнительный объект/коллекцию объектов.

 

[kudashevs]

не уверен

можно еще круче сформулировать: если заходишь в магазин и произносишь обязательные параметры "мне бутылочку вина", и не обязательные "далее неразборчиво", т.к. клиент сильно пьян

 

[AnrDaemon]

Вы путаете ошибки бизнес-логики проекта и ошибки логики библиотеки.
Вы путаете "корректное" и "правильное" поведение.
Если с точки зрения библиотеки поведение корректное (при установке параметра А происходит действие Б, всегда) - вам ничего делать не нужно.
А правильно ли это поведение - решает программист, использующий вашу библиотеку, не вы.

 

[grigori]

@kudashevs тут ситуация такая: не хочется посылать, но мы понимаем, что объяснить не получится, поэтому тема ушла в игру в бисер.

Если хочешь ответ, начнем с начала.
1. Есть критерии допуска задачи в спринт, называются INVEST. Напиши правила проверки задачи QA-отделом.
2. У задачи есть функциональные и нефункциональные требования. Просто напиши их.

 

[fixxxer]

Не надо валить все в одну кучу. Тут и валидация пользовательского ввода, и бизнес-констрейнты, и фиг знает что свалено в кучу.

Конечно, во многом проблема типична для программистов на похапе с одним типом данным Map<String | Int, any>. Ну дык, а не надо так.

Внутри программы есть типы данных, в широком понимании. Интерфейс внутри программы строится на типах. Там, где встроенных в язык типов не хватает, делаются собственные. В PHP свои типы делаются с помощью классов, при невозможности преобразования типа из более "широкого" в более "узкий" (скажем, из произвольной строки в тип username, определенный как "строка от 1 до 20 символов a-z0-9_" выбрасывается исключение из конструктора, принимающего строку).

Что касается данных от клиента (грубо говоря пользовательский ввод) - это обычно какая-то generic-структура, типа form-data (которая Map<String, String>) или json, которую надо отдельно провалидировать и отдать клиенту ответ в понятном ему формате (в т.ч. с ошибками). Это отдельный этап валидации, относящийся к интерфейсу между сервером и клиентом.

Что касаемо "мусора" в сообщении - непонятно, что такое мусор. Невалидный юникод? Превышение длины сообщения? Сообщение "за 10 грамм роскомнадзора"? Надо не выдумывать из головы, а определиться с бизнес- и техническими констрейнтами.

 

[grigori]

типична для программистов на похапе с одним типом данным Map<String | Int, any>

предпочитаешь string, float и object в JS для всего вообще?

 

[fixxxer]

с этой точки зрения предпочел бы язык с зависимыми типами, но на эти дела мозгов хватит у полутора человек в мире

 

[kudashevs]

С интересом наблюдаю как трактуется казалось бы подробно расписанный вопрос. Уже появилась бизнес-логика, пользовательский ввод, но позволю обратить внимание, что про это вообще не было написано ни слова.

Признаю, что вопрос описал плохо, вместо сервис надо было использовать слово класс/модуль, однако постарался описать все максимально подробно, поэтому получилось витиевато. Думаю, что в данном случае код будет гораздо лучше любых словесных описаний.

class File
{
    /**
     * @var array[
     *  'permissions' integer Permissions in chmod format (default 644).
     *  'timestamp' string Timestamp (default null).
     *  'rewrite' bool Rewrite if file exists  (default false).
     *  'append' bool Append content if file exists (default true).
     * ]
     */
    private $options;

    public function __construct(string $filename, array $options)
    {
        $this->options ...
    }
}

Мы хотим использовать сторонний класс. У этого класса есть необязательные опции задаваемые на входе, которыми не факт что вообще пользоваться будем. Но вдруг мы ими все таки решили воспользоваться.

Вопросов тут несколько:
- ожидаете ли вы, что этот $options будет проверен в момент инстанцирования и будут выброшены исключения или все упадет с ошибкой при неправильных данных в полях массива?
- если же он не делает никакой проверки полей, какое поведение вы ожидаете в случае неверно заданного поля:

- падение с ошибкой в месте где будет исполняться?​

- объект выполнит задачу молчаливо подставив какие-то дефолтные значения?​

- какое-то другое поведение?​

 

[MiksIr]

Мы ожидаем, что нам не придется использовать такой класс, а если и придется по каким-то причинам - напишем ему адаптер.

 

[fixxxer]

ожидаете ли вы, что этот $options будет

Нет, ожидаю, что такого говна не будет.

 

[kudashevs]

Мы ожидаем, что нам не придется использовать такой класс, а если и придется по каким-то причинам - напишем ему адаптер.

Нет, ожидаю, что такого говна не будет.

Спасибо всем за исчерпывающую аргументацию. Думаю, что больше не стоит тратить время друг друга и ветку я бы попросил прикрыть.