2014-02-27 5 views
1

Скажем, у меня есть этот общий класс:Общий, который реализует интерфейс или является двойным?

abstract class Foo<T> where T : IBar 

Это нормально до здесь, однако я хотел бы также быть в состоянии пройти double, а также. Теперь мне сказали, что это плохая идея, и единственный способ решить эту проблему - написать дублирующий класс, обрабатывающий двойной случай. Мне также сказали, что играть с примитивными типами, как это, не очень хорошая идея.

Что я думал об этом, было обертывание double в классе, который реализует IBar. Это позволило бы мне использовать обернутый двойник. Я могу увидеть некоторые проблемы с использованием класса, и мне снова сказали, что обертывание примитивных типов для этих целей - плохая идея.

  • Что было бы хорошим способом обойти это?
  • Пришло время пересмотреть использование двухместных?
  • Должен ли я просто создать отдельный дублирующий класс для обработки удвоений? (по-моему, это звучит так, как будто я не повторно использую).
  • Что такое правило большого пальца (если оно есть), когда нужно иметь дело с примитивами общим способом?

В Структуры, которые являются catagorised double, которые мы знаем из и BigRational структуры. Это представление отношения между двумя членами System.Numerics.BigInteger. Арифметика полностью определена на этой структуре и то, что Foo делает с T, должно быть определено для double и BigRational.

Теперь причина в том, соединяющий что эти неродственного и поэтому плохая практика создать интерфейс, чтобы объединить их (не говоря уже о оберточной примитива в первую очередь).

Моя идея для интерфейса IBar заключалась в том, чтобы иметь арифметику как требование. Теперь в будущем, если я попытаюсь использовать Foo для других классов/структур, которые реализуют IBar, все должно быть хорошо. Но я хочу, чтобы double работал. Итак, теперь я ищу хорошую причину, чтобы даже обернуть double в первую очередь и как это будет совпадать с хорошей практикой.

ответ

5

Я бы рассмотрел обертывание double в struct, а не класс.

Там нет никакого способа сказать «T должен быть либо double или реализовать IBar», но оборачивать элементарное значение в структуры вполне разумно (при условии, что на самом деле имеет смысл смысла IBar, мы ничего об этом не знаю в данный момент).

+0

Мне сказали (еще раз), что было бы * плохой практикой * создавать и связывать «IBar» исключительно с целью категоризации несвязанных классов/структур, особенно «double». Теперь причина, по которой я хотел бы сделать это, в первую очередь потому, что интуитивно они похожи. Я добавлю к вопросу, дающему более подробную информацию. –

+1

@Alizter: Когда кто-то говорит, что не нужно делать что-то естественное, требуйте объяснения. Вы не должны делать что-то только потому, что вам сказали, что это просто пропагандирует мифы.(Возможно, человек, говорящий вам, что, например, не понял что-то.) –

+0

Объяснение, которое я получил: «Существует фундаментальное различие между« double »и« BigRational »[См. OP]. Двойной добавляет два удвоения и возвращает double, BigRational добавляет два BigRationals и возвращает BigRational. Интерфейс, связанный с этими двумя, не может быть выполнен, поскольку они возвращают разные вещи. Это недостаток ». –

Смежные вопросы