Существует ли способ вынудить класс C# реализовать определенные статические функции?
Для URL или FIle используйте json.load (). Для строки, содержащей контент .json, используйте json.loads ().
#! /usr/bin/python
import json
from pprint import pprint
#json_file='a.json'
json_file='my_cube.json'
cube='1'
json_data=open(json_file)
data = json.load(json_data)
#pprint(data)
json_data.close()
print "Dimension: ", data['cubes'][cube]['dim']
print "Measures: ", data['cubes'][cube]['meas']
8 ответов
Нет, нет никакой поддержки языка этого в C#. Существует два обходных решения, о которых я могу сразу думать:
- отражение использования во времени выполнения; скрещенные пальцы и надежда...
- используют одиночный элемент / экземпляр по умолчанию / подобный для реализации интерфейса, который объявляет методы
( обновление )
На самом деле, пока у Вас есть поблочное тестирование, первая опция не на самом деле так плоха, как Вы могли бы думать, происходите ли (как я) Вы из строгой среды "статического контроля типов". Факт; это хорошо работает на динамических языках. И действительно, это точно, как мой универсальные операторы работы кода - это надежды у Вас есть статические операторы. Во времени выполнения, если Вы не делаете, это будет смеяться над Вами соответственно дразнящим тоном..., но это не может проверить во время компиляции.
Нет. В основном это кажется, что Вы после своего рода "статического полиморфизма". Это не существует в C#, хотя я предложил своего рода "статическое интерфейсное" понятие, которое могло быть полезным с точки зрения дженериков .
Одна вещь Вы могли делать быть записать простой модульный тест, чтобы проверить, что все типы в конкретном блоке соблюдают Ваши правила. Если другие разработчики будут также реализовывать интерфейс, Вы могли бы поместить тот тестовый код в некоторое общее место так, чтобы все реализующие интерфейс могли легко протестировать их собственные блоки.
Нет, в этой функции не было бы никакого смысла. Интерфейсы являются в основном уменьшенной формой множественного наследования. Они говорят компилятор, как настроить таблицу виртуальной функции так, чтобы нестатические виртуальные методы можно было назвать правильно в классах-потомках. Статические методы не могут быть виртуальными, следовательно, нет никакого смысла в использовании интерфейсов для них.
В то время как нет никакой поддержки языка этого, Вы могли использовать инструмент статического анализа для осуществления его. Например, Вы могли записать пользовательское правило для FxCop, который обнаруживает атрибут или интерфейсную реализацию на классе и затем проверяет на существование определенных статических методов.
Подход, который получает Вас ближе к тому, в чем Вы нуждаетесь, является одиночным элементом как предложенный Marc Gravell.
Интерфейсы, среди прочего, позволяют Вам обеспечить некоторый уровень абстракции к Вашим классам, таким образом, можно использовать данный API независимо от типа, который реализует его. Однако, так как ДЕЙСТВИТЕЛЬНО необходимо знать тип статического класса для использования его, почему Вы хотели бы осуществить тот класс для реализации ряда функций?
, Возможно, Вы могли использовать пользовательский атрибут как [ImplementsXXXInterface] и обеспечить некоторое время выполнения, проверяя, чтобы гарантировать, чтобы классы с этим атрибутом на самом деле реализовали интерфейс, в котором Вы нуждаетесь?
Одноэлементный шаблон помогает не во всех случаях. Мой пример взят из моего реального проекта. Это не надумано.
У меня есть класс (назовем его «Виджет»), который наследуется от класса в сторонней ORM. Если я создаю экземпляр объекта Widget (следовательно, создаю строку в базе данных) просто для того, чтобы убедиться, что мои статические методы объявлены, я создаю больший беспорядок, чем тот, который я пытаюсь очистить.
Если я создам это лишний объект в хранилище данных, я должен скрыть его от пользователей, вычислений и т. д.
Я использую интерфейсы в C #, чтобы убедиться, что я реализую общие функции в наборе классов.
Некоторые из методов реализующие эти функции требуют для запуска данных экземпляра. Я кодирую эти методы как методы экземпляра и использую интерфейс C #, чтобы убедиться, что они существуют в классе.
Некоторым из этих методов не требуются данные экземпляра, поэтому они являются статическими. Если бы я мог объявлять интерфейсы с помощью статических методов, компилятор мог бы проверить, существуют ли эти методы в классе, в котором говорится, что он реализует интерфейс.
Это отличный вопрос, с которым я сталкивался в своих проектах.
Некоторые люди считают, что интерфейсы и абстрактные классы существуют только для полиморфизма, а не для принуждения типов к реализации определенных методов. . Лично я считаю полиморфизм основным вариантом использования, а принудительную реализацию - второстепенным. Я довольно часто использую технику принудительной реализации. Обычно он появляется в коде фреймворка, реализующем шаблонный шаблон. Базовый / шаблонный класс инкапсулирует некоторую сложную идею, а подклассы предоставляют множество вариаций за счет реализации абстрактных методов. Одно прагматическое преимущество состоит в том, что абстрактные методы служат руководством для других разработчиков, реализующих подклассы. В Visual Studio даже есть возможность скрыть методы за вас. Это особенно полезно, когда разработчику сопровождения нужно добавить новый подкласс через несколько месяцев или лет.
Обратной стороной является то, что в C # нет специальной поддержки для некоторых из этих шаблонных сценариев. Статические методы - это одно. Другой - конструкторы; в идеале ISerializable должен вынудить разработчика реализовать защищенный конструктор сериализации.
Вероятно, самый простой подход - это (как предлагалось ранее) использовать автоматизированный тест, чтобы проверить, реализован ли статический метод для требуемых типов. Еще одна жизнеспособная идея, о которой уже упоминалось, - реализовать правило статического анализа.
Третий вариант - использовать структуру аспектно-ориентированного программирования, такую как PostSharp . PostSharp поддерживает проверку аспектов во время компиляции. Вы можете написать код .NET, отражающий сборку во время компиляции, генерация произвольных предупреждений и ошибок. Обычно вы делаете это, чтобы проверить, подходит ли использование аспекта, но я не понимаю, почему вы не можете использовать его и для проверки правил шаблона.