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

WMix

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

kudashevs

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

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

kudashevs

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

WMix

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

kudashevs

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

kudashevs

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

Yoskaldyr

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

kudashevs

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

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 грамм роскомнадзора"? Надо не выдумывать из головы, а определиться с бизнес- и техническими констрейнтами.
 

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

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

kudashevs

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