Действительно ли это верно, что я не должен делать “длительных” вещей в средстве доступа свойства?
Это выглядит немного лучше
column.dt. позволяет функции datetime для столбцов datetime, как column.str. делает для строковых столбцов
datetime-like properties Справочник по API
import pandas as pd
# test df
df = pd.DataFrame([{'old_column':pd.Timestamp('2015-07-18 13:53:33.280')}])
df['new_column'] = df['old_column'].dt.round('15min')
df
8 ответов
Как вы упомянули, это сюрприз для пользователя класса. Люди привыкли делать такие вещи с помощью свойств (см. Надуманный пример:)
foreach (var item in bunchOfItems)
foreach (var slot in someCollection)
slot.Value = item.Value;
Это выглядит очень естественно, но если item.Value на самом деле попадает в базу данных каждый раз, когда вы обращаетесь к ней, она было бы незначительной катастрофой и должно быть написано в стиле, эквивалентном следующему:
foreach (var item in bunchOfItems)
{
var temp = item.Value;
foreach (var slot in someCollection)
slot.Value = temp;
}
Пожалуйста, помогите людям, использующим ваш код, избежать скрытых опасностей, подобных этой, и добавьте медленные вещи в методы, чтобы люди знали, что они медленные.
. Конечно, есть исключения. Ленивая загрузка - это нормально, если она не займет безумно много времени, а иногда создание свойств вещей действительно полезно по причинам, связанным с отражением и привязкой данных, так что, возможно, вы захотите нарушить это правило. Но есть'
Чтение db в методе доступа к свойству было бы хорошо - в этом весь смысл отложенной загрузки. Я думаю, что наиболее важным было бы хорошо задокументировать это, чтобы пользователи класса понимали, что при доступе к этому свойству может произойти снижение производительности.
In addition to the good answers already posted, I'll add that the debugger automatically displays the values of properties when you inspect an instance of a class. Do you really want to be debugging your code and have database fetches happening in the debugger every time you inspect your class? Be nice to the future maintainers of your code and don't do that.
Also, this question is extensively discussed in the Framework Design Guidelines; consider picking up a copy.
Вы можете делать все, что хотите, но вы должны помнить о потребителях вашего API. Ожидается, что аксессоры и мутаторы (геттеры и сеттеры) будут очень легкими. Исходя из этого, разработчики, использующие ваш API, могут часто и болтать с этими свойствами. Если вы потребляете внешние ресурсы в своей реализации, может возникнуть неожиданное узкое место.
В целях согласованности рекомендуется придерживаться соглашения для общедоступных API. Если ваши реализации будут исключительно частными, то, вероятно, нет никакого вреда (кроме непоследовательного подхода к решению проблем в частном или публичном порядке).
Это просто «хорошая практика» - не заставлять методы доступа к свойствам выполнять много времени. Это потому, что свойства выглядят как поля для вызывающего и, следовательно, вызывающий (пользователь вашего API) обычно предполагает, что нет ничего, кроме «return smth»;
Если вам действительно нужно какое-то «действие» за кулисами, подумайте о создании метода для этого ...
Я не понимаю, в чем проблема, если вы предоставите документацию XML, чтобы Intellisense уведомил потребителя объекта
Я думаю, что это одна из тех ситуаций, когда нет единственного правильного ответа. Мой девиз: «Сказать всегда - почти всегда неправильно». Вы должны делать то, что имеет наибольший смысл в любой конкретной ситуации, без оглядки на широкие обобщения.
Доступ к базе данных в средстве получения свойств допустим, но попробуйте ограничить количество обращений к базе данных путем кэширования значения.
Часто люди используют свойства в циклах не думая о производительности, поэтому вы должны предвидеть это использование. Программисты не всегда сохраняют значение свойства, когда они собираются использовать его много раз.
Кэшируйте значение, возвращаемое из базы данных, в частной переменной, если это возможно для этого фрагмента данных. Таким образом доступ обычно происходит очень быстро.
Это не имеет прямого отношения к вашему вопросу, но рассматривали ли вы вариант использования подхода однократной загрузки в сочетании с параметром обновления?
class Example
{
private bool userNameLoaded = false;
private string userName = "";
public string UserName(bool refresh)
{
userNameLoaded = !refresh;
return UserName();
}
public string UserName()
{
if (!userNameLoaded)
{
/*
userName=SomeDBMethod();
*/
userNameLoaded = true;
}
return userName;
}
}