Меню
Что нового?

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

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

Суть это поста, желание понять, какое поведение программисты ожидают от среднестатистического пакета где используются необязательные параметры (опции).
 
WMix написал(а):
если ты переводишь деньги и не указываешь кому переводить, какое поведение ожидаешь?
Нажмите для раскрытия...
Сумма перевода и лицо получающее это обязательные параметры (критичные для бизнес логики), поэтому при неправильном указании ожидаю fast-fail. А вот если есть необязательный параметр, например сообщение (по умолчанию переведено от пользователя такого-то такого-то числа) и в него был передан мусор. Вы какое поведение ожидаете?
 
если заходишь в магазин и произносишь обязательные параметры "мне бутылочку вина", и не обязательные "2000 года, шато марго, из бургундии", а продается только молдавское, что делает продавец?
 
WMix написал(а):
если заходишь в магазин и произносишь обязательные параметры "мне бутылочку вина", и не обязательные "2000 года, шато марго, из бургундии", а продается только молдавское, что делает продавец?
Нажмите для раскрытия...
Зависит от продавца :) Хороший продавец попробует впарить молдавское.
 
WMix написал(а):
вот и выбирай какой ты продавец
Нажмите для раскрытия...
Когда писал ответ, понял что не совсем точная аналогия. Правильнее была бы аналогия: если заходишь в магазин и произносишь обязательные параметры "мне бутылочку вина", и не обязательные "балтику 9". Но мы точно знаем, что человек хочет вина :)
 
Дополнительные параметры лучше передавать объектом, а не массивом. И типизация, и нельзя мусор передать и при правильном объекте параметров в принципе нельзя допустить ошибку со стороны пользователя, все будет разруливаться на уровне языка
 
Yoskaldyr написал(а):
Дополнительные параметры лучше передавать объектом, а не массивом. И типизация, и нельзя мусор передать и при правильном объекте параметров в принципе нельзя допустить ошибку со стороны пользователя, все будет разруливаться на уровне языка
Нажмите для раскрытия...
Спасибо за ответ. 2-0 в пользу fast-fail, но только через дополнительный объект/коллекцию объектов.
 
Вы путаете ошибки бизнес-логики проекта и ошибки логики библиотеки.
Вы путаете "корректное" и "правильное" поведение.
Если с точки зрения библиотеки поведение корректное (при установке параметра А происходит действие Б, всегда) - вам ничего делать не нужно.
А правильно ли это поведение - решает программист, использующий вашу библиотеку, не вы.
 
@kudashevs тут ситуация такая: не хочется посылать, но мы понимаем, что объяснить не получится, поэтому тема ушла в игру в бисер.

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

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

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

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

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

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


Код: 
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 написал(а):
Нет, ожидаю, что такого говна не будет.
Нажмите для раскрытия...

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