Почему можно было бы также использовать пустого конструктора?
Документы описывают атрибуты, доступные по запросу. В большинстве распространенных случаев request.data будет пустым, поскольку он используется в качестве запасного варианта:
request.data Contains the incoming request data as string in case it came with a mimetype Flask does not handle.
request.args: the key/value pairs in the URL query string
request.form: the key/value pairs in the body, from a HTML post form, or JavaScript request that isn't JSON encoded
request.files: the files in the body, which Flask keeps separate from form. HTML forms must use enctype=multipart/form-data or files will not be uploaded.
request.values: combined args and form, preferring args if keys overlap
Все это экземпляры MultiDict. Вы можете получить доступ к значениям, используя:
request.form['name']: use indexing if you know the key exists
request.form.get('name'): use get if the key might not exist
request.form.getlist('name'): use getlist if the key is sent multiple times and you want a list of values. get only returns the first value.
8 ответов
Я не уверен, что код, который Вы читали, был высококачественным (я рассмотрел некоторый код биоинформатики в прошлом, и это, к сожалению, часто не пишется профессиональными разработчиками). Например, тот третий конструктор не является конструктором копии и обычно в этом коде существуют проблемы, таким образом, я "не читал бы слишком много в него".
Первый конструктор является конструктором по умолчанию. Это только инициализирует абсолютный минимум и позволяет пользователям установить остальных с методами считывания и методами set. Другие конструкторы часто являются "конструкторами удобства", что справка создает объекты с меньшим количеством вызовов. Однако это может часто приводить к несоответствиям между конструкторами. На самом деле существует недавнее исследование, которое показывает, что конструктор по умолчанию с последующими вызовами к методам set предпочтителен.
Существуют также определенные случаи, где конструктор по умолчанию очень важен. Например, определенные платформы как систематизатор (раньше создавал объекты непосредственно из XML) используют конструкторов по умолчанию. JavaBeans в конструкторах по умолчанию общего использования, и т.д.
Кроме того, некоторые классы наследовались другим классам. можно видеть конструктора по умолчанию, когда инициализация родительского объекта "достаточно хороша".
В этом конкретном случае, если бы тот конструктор не был определен, нужно было бы знать все подробности заранее. Это не всегда предпочтительно.
И наконец, некоторые IDE автоматически генерируют конструктора по умолчанию, возможно, что, кто бы ни записал, класс боялся устранить его.
Действительно ли объект является сериализуемым?
Чтобы позволить подтипам несериализуемых классов быть сериализированными, подтип может принять на себя ответственность за сохранение и восстановление состояния общественности супертипа, защищенной, и (если доступный) поля пакета. Подтип может принять на себя эту ответственность, только если класс, который это расширяет, имеет доступного конструктора без аргументов для инициализации состояния класса. Это - ошибка объявить класс, сериализуемый если дело обстоит не так. Ошибка будет обнаружена во времени выполнения.
Во время десериализации поля несериализуемых классов будут инициализированы с помощью общественности или защитили конструктора без аргументов класса. Конструктор без аргументов должен быть доступен для подкласса, который является сериализуемым. Поля сериализуемых подклассов будут восстановлены от потока
Да, я соглашаюсь, что "пустой" конструктор не должен всегда существовать (по моему опыту, новички часто делают эту ошибку), хотя существуют случаи, когда пустой конструктор был бы достаточен. Однако, если пустой конструктор нарушает инвариант, что все участники правильно инстанцируют после конструкции не должен использоваться пустой конструктор. Если конструктор является сложным, лучше разделить конструкцию на несколько защищенные/закрытые методы. Затем используйте статический метод или другой класс Фабрики для вызова защищенных методов для конструкции по мере необходимости.
То, что я записал выше, является идеальным сценарием. Однако платформы как пружина удаляют логику конструктора из кода и в некоторые файлы настройки XML. Вы можете иметь метод считывания и функции метода set, но вероятно можете избежаться от интерфейса, как описано здесь.
Конструктор по умолчанию не обязателен.
Если никакие конструкторы, определенные в классе затем (пустой) конструктор по умолчанию, не будут созданы автоматически. При обеспечении какого-либо параметрического конструктора (конструкторов) затем, конструктор по умолчанию не будет создан автоматически, и лучше создать его собой. Платформы, которые используют внедрение зависимости и динамическое создание прокси во времени выполнения обычно, требуют конструктора по умолчанию. Так, это зависит от вариантов использования класса, который Вы пишете.
Это не конструктор копии. В основном Вы хотите пустых конструкторов при работе с некоторой платформой. Там всегда будет пустой конструктор, конечно, общедоступный или частный, но по крайней мере он позволяет Вам удерживать контроль над тем, как класс (или не) инстанцирован.
Конструктор по умолчанию is'nt хорошая практика для функционального представления. Конструктор по умолчанию используется, если объект имеет глобальную видимость в метод: например, Вы хотите, регистрируют реальное положение объекта в попытке/выгоде, которую можно кодировать
MyObejct myObject=null
try{...
}catch(Exception e){
log.error(myObject);//maybe print null. information?
}
или Вы предпочитаете
MyObejct myObject=new Object();
try{...
}catch(Exception e){
log.error(myObject);//sure print myobject.toString, never null. More information
}
?
Anotherway создавание Пустого объекта have'nt большая логика, но instatiate Несуществующий объект является harmuful, по-моему. Можно прочитать это сообщение
Я обычно пишу одному конструктору, который полностью инициализирует объект; если существуют другие, они все называют это (...) с соответствующими значениями по умолчанию.
Объект должен составить 100%, инициализированных и готовых к употреблению, когда он создается.
Некоторые платформы, например, Будьте в спящем режиме, потребуйте конструктора без аргументов. Путем они сталкиваются с лучшими практиками, делает меня обеспокоенным иногда.
Наличие пустого (пустого) конструктора по умолчанию не позволяет вам иметь какие-либо поля final. Это приводит к большой изменчивости там, где это часто не требуется.
Шаблон построителя позволяет вам смешивать эти два стиля и обеспечивает более гибкую инициализацию, сохраняя неизменность, скрывая конструктор с множеством аргументов за фабрикой.