Возможно ли объявить поле каким-то локальным свойством [duplicate]
Я использую pandas 0.14.1 на macos в ноутбуке ipython. Я попробовал предложенную строку выше:
df[df['A'].str.contains("Hello|Britain")]
и получил ошибку:
"cannot index with vector containing NA / NaN values"
, но она отлично работала, когда было добавлено условие «== Истина», например:
df[df['A'].str.contains("Hello|Britain")==True]
8 ответов
Нет никакого способа сделать это, кроме как просто следовать своему собственному соглашению и делать это. Если вам действительно нужно пройти через ваше публичное свойство.
Я не понимаю, почему вам нужно будет / хотеть сделать это, поскольку, поскольку это ваш внутренний класс, вы контролируете код, и вы можете определить, что / как он используется, поэтому не должно быть проблем.
-
1Ого! Извините @ Митчел - я случайно отредактировал неправильный пост. Извините, это так. – Marc Gravell♦ 16 July 2010 в 15:08
-
2@Marc - вы получили бит от прекрасной случайной функции заказа? У меня это случалось не раз, когда я автоматически предполагал, что мой вопрос был в том же положении после редактирования (или представления) и слепо нажал кнопку редактирования. Не помогает, когда ответ в этой позиции начинается практически с одного и того же текста. – tvanfosson 16 July 2010 в 15:13
Вы должны получить доступ к свойству только через общедоступное свойство Hello. Это и есть причина этого шаблона. Если вы добавите какие-либо функции в get или set, если вы обращаетесь к частному экземпляру, вы введете ошибки в свой код. Но anwer - НЕТ, вы не можете запретить кому-то звонить Частным, когда они находятся внутри вашего класса, изменяя ваш код.
-
1Возможно, он может идти в обоих направлениях: вы можете захотеть напрямую ссылаться на фоновое поле, чтобы на вас не повлияло какое-либо дополнение к публичному свойству. Было бы неплохо быть последовательным в этом отношении, и, возможно, хорошая идея четко идентифицировать поддерживающие переменные, что ясно, что свойство обходит. Например, вы можете суффиксом их с помощью
_Propили что-то в этом роде. – Steven Sudit 16 July 2010 в 15:22 -
2Я предпочитаю последовательность и просто хочу указать причину шаблона. Всегда есть причина для каждого решения, не делает его лучшей практикой. – CkH 16 July 2010 в 15:37
Лично я не вижу ничего плохого в доступе к частному члену внутри класса. Фактически, это то, что я обычно делаю (если в составе свойства getter / setter нет логики, которую я всегда хочу использовать).
Это имеет смысл для меня: код внутри класса составляет реализация этого класса; зачем скрывать реализацию от себя?
Вот пример того, что я имею в виду. Предположим, что у меня есть член, m_denominator, и я хочу, чтобы он никогда не был равен нулю:
private int m_denominator = 1;
public int Denominator
{
get { return m_denominator; }
set
{
if (value == 0)
throw new ArgumentException("Denominator must not be zero.");
m_denominator = value;
}
}
Я мог бы сказать себе: «Хорошо, везде я устанавливаю это значение в этом классе, я должен использовать Denominator, чтобы убедиться, что я не устанавливаю его в ноль ». Но я полностью контролирую, что я устанавливаю Denominator - я внутри класса! В сценарии этого точкой логики в свойстве Denominator является защита класса от недопустимых значений, установленных клиентским кодом. Нет никакого оправдания для установки внутреннего состояния на какое-то недопустимое значение в реализации самого класса.
Конечно, это не абсолютное правило. Конечно, времена, когда использование свойства для его логики внутри класса может быть разумным выбором в качестве защитной меры; действительно, я просто утверждаю, что не ошибается для доступа к закрытым членам внутри класса.
-
1Итак, что происходит, когда вы возвращаетесь к коду через 6 месяцев, чтобы добавить важную логику в средство настройки свойств? Все внутренние коды вашего класса теперь будут обходить новые реализации. – Dr Herbie 16 July 2010 в 15:16
-
2Я предпочитаю по умолчанию использовать свойство именно потому, что не хочу отслеживать места, где свойство делает что-то особенное. Оптимизатор обычно будет заботиться об оптимизации вызова метода в любом случае, по крайней мере, для простого доступа. Я буду использовать свойство только тогда, когда знаю, что свойство делает что-то «специальное». и я хочу избежать этого для определенной цели. – tvanfosson 16 July 2010 в 15:17
-
3@Dr Herbie: Но по моему опыту так же вероятно, что вы добавите логику в свойство, но не будет хотеть, чтобы эта логика выполнялась при каждом доступе, происходящем внутри класса, - только при доступе из внешнего кода. Я определенно работал с разработчиками, добавившими логику к их свойствам, и вдруг они обнаружили, что некоторые из их кодов выполняются намного чаще, чем они предполагали. Очевидно, это призыв к суду; Я просто указываю, что существует разница между скрытием вашей реализации от внешнего мира и скрытием ее от ... самого. – Dan Tao 16 July 2010 в 15:22
-
4Я нахожу это очень подозрительное рассуждение. Как правило, вы добавляете дополнительный код в средство настройки свойств для принудительного применения некоторых правил зависимости или бизнес-правил. Мой опыт в том, что вы обычно не хотите избежать этого, даже в классе. Конечно, есть исключения - и я хотел бы ссылаться на свойство поддержки в этих случаях, но поскольку они являются исключительными, я использую свойство в случае по умолчанию, а не наоборот. Обратившись к вашему примеру, я бы сказал, что в инициализаторе, использующем поле, прямо в порядке, но где-нибудь еще в вашем классе, вы действительно хотите использовать свойство – tvanfosson 16 July 2010 в 15:35
-
5@tvanfosson: Эй, я не говорю, что вы ошибаетесь. Моя перспектива в основном такова: ОП, похоже, ищет способ запретить доступ к частному члену изнутри реализации. Я говорю: это не обязательно то, что вам нужно сделать. Что касается того, какая логика должна или не должна входить в свойство getter / setter, это другой аргумент. В любом случае мы оба склонны признавать, что иногда один подход разумный, а иногда другой подход имеет больше смысла; это все, на что я действительно пытаюсь спорить - не тот, который является исключением, и который является правилом. – Dan Tao 16 July 2010 в 15:43
Если вы обнаруживаете, что хотите скрыть детали от себя, это может быть запахом кода, который у вашего класса слишком много обязанностей. Подумайте об извлечении одной из обязанностей в новый класс.
-
1Иногда это не «сам». но есть и другие члены вашей команды, которые не могли следовать правилам. Я знаю, теоретически все имеет простое решение, но жизнь жесткая ... – bpiec 1 September 2017 в 06:36
-
2@JoeWhite: это интересная точка зрения. Однако фрагментация классов до уровня, где каждый из них имеет почти тривиальную ответственность, звучит хорошо в теории, но на практике может быть кошмаром, чтобы понять в своем собственном праве. – oliver 7 March 2018 в 11:30
Как и другие, это должно быть ответом ...
Вы можете использовать автоматические свойства в C # 3 при таргетинге на .NET 2.0 вместе с еще несколько других функций C # 3 . В отличие от (например) деревьев выражений, автоматическим свойствам не требуется ничего особенного из CLR или фреймворка, помимо атрибута [CompilerGenerated] (который был введен в .NET 2.0).
Итак, если вы используя VS2008 или VS2010, тогда было бы полезно использовать автоматическое свойство.
Для чего это стоит, я бы тоже хотел эту способность. Я хотел бы иметь возможность переменные области видимости в свойстве:
public string Name
{
private string name;
get { return name; }
set { name = value; }
}
Я рассматриваю это как похожее на то, чтобы сделать частную переменную readonly - это не имеет никакого отношения к клиентам, но это помогает обеспечить правильность внутри сам код класса.
-
1+1 - Я полностью согласен с переменной свойств частной области. Мне бы очень хотелось, чтобы у обоих как произвольный код в методах свойств , так и ограничивал доступ к полю поддержки для свойства только таким образом, чтобы я случайно не избегал «правил». в коде getter / setter. – tvanfosson 16 July 2010 в 17:28
-
2Связанный с Tangentially, я бы хотел иметь неизменяемые автоматические свойства (настраиваемый через синтаксис конструктора или инициализатора), а затем только gettable оттуда внутри. Поддерживается поле
readonly, сгенерированное компилятором. – Jesse C. Slicer 21 August 2013 в 15:27
Нет. Любой метод внутри класса будет иметь доступ к обоим.
Ваша команда должна стандартизировать использование (свойство или приватная переменная).
Как только вы решите, что использовать, вы можете попробовать для использования стандартного правила FxCop для обеспечения соблюдения стандарта.
Нет, в принципе. Ну, вы могли бы что-то делать с предупреждениями компилятора через [Obsolete] и #pragma, но это было бы чрезмерно.
Вы могли бы , вероятно, сделать это с инструментами, но в конечном итоге вам нужно доверять людям, чтобы они не делали глупые вещи. В конце концов, есть ли у вас специальные правила:
while(true) { }
, или вы просто ставите это, чтобы «не быть глупым»? ; Р
-
1
while(true)плюсbreakвнутри тела цикла является вполне допустимой конструкцией программирования. Есть намного хуже, чем это. – user 16 July 2010 в 15:49 -
2
-
3
Вы можете выполнить это через наследование:
abstract class A // A is not instantiatable due to being abstract
{
private string m_hello = null;
public string Hello
{
get{return m_hello;}
set{m_hello = value;}
}
}
class B : A
{
// B now cannot access the private variable, use B in your code instead of A
}
Я не утверждаю, что это хорошо. Просто это можно сделать.
-
1