point = [-1, 0, 1] ix = pd.MultiIndex.from_product([point, point], names=['a', 'b']) df = pd.DataFrame(index=ix).reset_index() df = df[df.a != df.b]
(скорее) эффективно получит вам фрейм данных с уникальными комбинациями двух координат, как при внешнем соединении в SQL:
a b 1 -1 0 2 -1 1 3 0 -1 5 0 1 6 1 -1 7 1 0
После этого вы можно получить расстояние с
>>> (df.a - df.b).abs().min() 1
Да, комбинирование статического и абстрактного бессмысленно. Идея static заключается в том, что не нужно представлять экземпляр класса, чтобы использовать рассматриваемый член; однако с абстрактным можно ожидать, что экземпляр будет производным классом, который обеспечивает конкретную реализацию.
Я понимаю, почему вам нужна такая комбинация, но факт заключается в том, что единственным эффектом будет отказ в использовании реализации of this или любых нестатических членов. То есть родительский класс будет диктовать ограничение в реализации производного класса, даже если нет основной разницы между вызовом абстрактного или статического абстрактного члена (поскольку обоим потребуется конкретный экземпляр, чтобы выяснить, какую реализацию использовать)
Если вы не против отложить реализацию для разумной реализации свойства Description, вы можете просто сделать
public abstract string ClassDescription {get; }
// ClassDescription is more intention-revealing than Description
И реализация классов будет делать что-то вроде этого:
static string classDescription="My Description for this class";
override string ClassDescription { get { return classDescription; } }
Тогда ваши классы требуется соблюдать договор о наличии описания, но вы предоставляете им делать это разумно. Невозможно определить реализацию объектно-ориентированным способом (кроме жестоких, хрупких взломов).
Однако, на мой взгляд, это Описание является метаданными класса, поэтому я предпочел бы использовать механизм атрибутов, как описано другими. Если вас особенно беспокоит многократное использование отражения, создайте объект, который отражает атрибут, который вас интересует, и сохраните словарь между типом и описанием. Это минимизирует отражение (кроме проверки типов во время выполнения, что не так уж и плохо). Словарь может храниться как член любого класса, который обычно нуждается в этой информации, или, если это требуется клиентам в домене, через одноэлементный объект или объект контекста.
Вы не можете.
Это можно сделать с помощью атрибутов.
Например,
[Name("FooClass")]
class Foo
{
}
Если он статический, существует только один экземпляр переменной, я не понимаю, как наследование имело бы смысл, если бы мы могли делать то, что вы хотите, с помощью статических переменных в производных классах. Лично я думаю, что вы зайдете слишком далеко, пытаясь избежать экземпляра var.
Почему не просто классический способ?
abstract class AbstractBase
{
protected string _Description = "I am boring abstract default value";
}
class Foo : AbstractBase {
public Foo() {
_Description = "I am foo!";
}
}
Он не статичен, если его нужно вызывать в экземпляре.
Если вы не вызываете его в экземпляре, то здесь нет никакого полиморфизма (т.е. ChildA.Description полностью не имеет отношения к ChildB.Description в том, что касается языка).