Лучший способ записать функцию преобразования

Используйте перечисления, если Ваш язык позволяет его для спецификаций единицы.

Я сказал бы, что код внутри будет легче с два. У меня была бы таблица с, предварительно добавляют, multiplty, и постдобавляют и выполняют значение через объект для одной единицы, и затем через объект для другой единицы наоборот. В основном преобразование входной температуры к общей базе оценивает внутри, и затем к другой единице. Эта целая функция была бы табличной.

Мой голос является двумя параметрами для типов преобразования, один для значения (как в Вашем первом примере). Я использовал бы перечисления вместо строковых литералов, как бы то ни было.

Я думаю, что пошел бы целый пожиратель ресурсов одно направление или другой. Вы могли записать мини-язык, который делает любой вид преобразования как единицы, делает:

$ units 'tempF(-40)' tempC
    -40

Или используйте отдельные функции как недавнее Преобразование:: Температурный модуль Perl делает:

use Convert::Temperature;

my $c = new Convert::Temperature();

my $res = $c->from_fahr_to_cel('59');

Но это поднимает важный момент---, делает язык, который Вы используете, уже имеют функции преобразования? Если так, какое кодирование конвенции они используют? Таким образом, если бы язык является C, было бы лучше последовать примеру atoi и strtod (непротестированных) библиотечных функций:

double fahrtocel(double tempF){
    return ((tempF-32)*(5/9));
}

double celtofahr(double tempC){
    return ((9/5)*tempC + 32);
}

В записи этого сообщения я натыкался на очень интересное сообщение при использовании emacs для преобразования дат. Еда на дом для этой темы - то, что она использует один стиль функции на преобразование. Кроме того, преобразования могут быть очень неясными. Я склонен делать вычисления даты с помощью SQL, потому что кажется маловероятным, что в том коде существует много ошибок. В будущем я собираюсь изучить использование emacs.

Между прочим, это не должно быть больше работы для реализации версии с тремя параметрами, как предложено в операторе вопроса.

Это все линейные функции, таким образом, можно реализовать что-то как

float LinearConvert(float in, float scale, float add, bool invert);

где последний bool указывает, хотите ли Вы сделать прямое преобразование или инвертировать его.

В Вашем методе преобразования у Вас может быть масштабировать/добавлять пара для X-> Kelvin. Когда Вы заставляете запрос преобразовывать формат X в Y, можно сначала работать X-> Kelvin, затем Kelvin-> Y путем инвертирования Y-> процесс Kelvin (путем зеркального отражения последнего bool в LinearConvert).

Эта техника дает Вам что-то как 4 строки реального кода в Вашей функции преобразования и одну часть данных для каждого типа, между которым необходимо преобразовать.

Подобный тому, какой @Rob @wcm и @David объяснен...

public class Temperature
{
    private double celcius;

    public static Temperature FromFarenheit(double farenheit)
    {
        return new Temperature { Farhenheit = farenheit };
    }

    public static Temperature FromCelcius(double celcius)
    {
        return new Temperature { Celcius = celcius };
    }

    public static Temperature FromKelvin(double kelvin)
    {
        return new Temperature { Kelvin = kelvin };
    }

    private double kelvinToCelcius(double kelvin)
    {
        return 1; // insert formula here
    }

    private double celciusToKelvin(double celcius)
    {
        return 1; // insert formula here
    }

    private double farhenheitToCelcius(double farhenheit)
    {
        return 1; // insert formula here
    }

    private double celciusToFarenheit(double kelvin)
    {
        return 1; // insert formula here
    }

    public double Kelvin
    {
        get { return celciusToKelvin(celcius); }
        set { celcius = kelvinToCelcius(value); }
    }

    public double Celcius
    {
        get { return celcius; }
        set { celcius = value; }
    }

    public double Farhenheit
    {
        get { return celciusToFarenheit(celcius); }
        set { celcius = farhenheitToCelcius(value); }
    }
}

Я всегда в поисках способов использовать объекты решить мои проблемы программирования. Я надеюсь, что это означает, что я - больше OO чем тогда, когда я только использовал функции для решения проблем, но это еще неизвестно.

В C#:

interface ITemperature
{
     CelciusTemperature ToCelcius();
     FarenheitTemperature ToFarenheit();
}

struct FarenheitTemperature : ITemperature
{
    public readonly int Value;
    public FarenheitTemperature(int value)
    {
        this.Value = value;
    }

    public FarenheitTemperature ToFarenheit() { return this; }
    public CelciusTemperature ToCelcius()
    {
        return new CelciusTemperature((this.Value - 32) * 5 / 9);
    }

}

struct CelciusTemperature
{
    public readonly int Value;
    public CelciusTemperature(int value)
    {
        this.Value = value;
    }

    public CelciusTemperature ToCelcius() { return this; }
    public FarenheitTemperature ToFarenheit()
    {
        return new FarenheitTemperature(this.Value * 9 / 5 + 32);
    }
}

и некоторые тесты:

        // Freezing
        Debug.Assert(new FarenheitTemperature(32).ToCelcius().Equals(new CelciusTemperature(0)));
        Debug.Assert(new CelciusTemperature(0).ToFarenheit().Equals(new FarenheitTemperature(32)));

        // crossover
        Debug.Assert(new FarenheitTemperature(-40).ToCelcius().Equals(new CelciusTemperature(-40)));
        Debug.Assert(new CelciusTemperature(-40).ToFarenheit().Equals(new FarenheitTemperature(-40)));

и пример ошибки, которой избегает этот подход:

        CelciusTemperature theOutbackInAMidnightOilSong = new CelciusTemperature(45);
        FarenheitTemperature x = theOutbackInAMidnightOilSong; // ERROR: Cannot implicitly convert type 'CelciusTemperature' to 'FarenheitTemperature'

Добавление преобразований Кельвина оставляют как осуществление.

Мне жаль, что не было некоторого способа принять несколько ответов. На основе общих рекомендаций я думаю, что буду придерживаться нескольких параметров, меняя струны к перечислениям/константам, и перемещая значение, которое будет преобразовано в первое положение в списке параметров. В функции я буду использовать Kelvin в качестве общего второго плана.

Ранее я записал отдельные функции для каждого преобразования и полного convertTemperature (), функция была просто оберткой с вложенными операторами переключения. Я пишу и в классическом ASP и в PHP, но я хотел оставить вопрос открытым для любого языка.

Я сделал бы перечисление из температурных типов и передал бы в этих 2 масштабных коэффициентах. Что-то как (в c#):

public void ConvertTemperature(TemperatureTypeEnum SourceTemp,
                               TemperatureTypeEnum TargetTemp, 
                               decimal Temperature)
{}

В C# (и probaly Java) было бы лучше создать Класс температуры, который хранит температуры конфиденциально как Celcius (или безотносительно) и который имеет Celcius, Фаренгейта и свойства Kelvin, которые делают все преобразования для Вас в их получать и установить операторы?

Я выбрал бы

Пример 1 - разделяет параметры: функционируйте convertTemperature ("Цельсия", "Фаренгейт", 22)

Иначе в рамках Вашего функционального определения необходимо было бы проанализировать "c-f" в "Цельсия" и "Фаренгейта" так или иначе для получения необходимых шкал перевода, которые могли стать грязными.

Если Вы обеспечиваете, что-то как поле поиска Google пользователям, имея удобные ярлыки как "c-f" хорошо для них. Внизу, тем не менее, я преобразовал бы "c-f" в "Цельсия" и "Фаренгейта" во внешней функции прежде, чем назвать convertTemperature () как выше.

Ваша функция будет намного более устойчивой при использовании первого подхода. Если необходимо добавить другой масштаб, это - еще одно значение параметра для обработки. Во втором подходе, добавляя другой масштаб означает добавлять столько значений, сколько у Вас уже были масштабы в списке, времена 2. (Например, для добавления K к C и F необходимо было бы добавить K-C, K-F, C-K и C-F.)

Достойный способ структурировать Вашу программу состоял бы в том, чтобы сначала преобразовать то, что входит к произвольно выбранному промежуточному масштабу, и затем преобразуйте от того промежуточного масштаба до исходящего масштаба.

Лучший путь состоял бы в том, чтобы иметь немного библиотеки наклонов и прерываний для различных масштабов, и просто искать числа для поступления и исходящих масштабов и сделать вычисление на одном универсальном шаге.

Зависит, сколько преобразований Вы собираетесь иметь. Я, вероятно, выбрал бы один параметр, данный как перечисление: Рассмотрите эту расширенную версию преобразования.

enum Conversion
{
  CelsiusToFahrenheit,
  FahrenheitToCelsius,
  KilosToPounds
}

Convert(Conversion conversion, X from);

У Вас теперь есть нормальная безопасность типов в точке вызова - нельзя дать правильно введенные параметры, которые дают неправильный результат во время выполнения. Рассмотрите альтернативу.

enum Units
{
  Pounds,
  Kilos,
  Celcius,
  Farenheight
}

Convert(Unit from, Unit to, X fromAmount);

Я могу ввести безопасно вызов

Convert(Pounds, Celcius, 5, 10);

Но результат бессмыслен, и необходимо будет перестать работать во времени выполнения. Да, я знаю, что Вы только имеете дело с температурой в данный момент, но общее понятие все еще содержит (я верю).

При записи таких проектов мне нравится думать мне, "Если бы я должен был добавить дополнительную единицу, что разработало бы, то сделал бы это самым легким, чтобы сделать так?" Делая это, я прихожу к выводу, что перечисления были бы самыми легкими по следующим причинам:

1) Добавление новых значений легко. 2) я стараюсь не делать сравнение строк

Однако, как Вы пишете метод преобразования? 3p2 6. Таким образом, это означает, что существует 6 различных комбинаций Цельсия, Фаренгейта и кельвина. Что, если я хотел добавить новый умеренный формат "нечто"? Это означало бы 4p2, который равняется 12! Еще два? 5p2 = 20 комбинаций. Еще три? 6p2 = 30 комбинаций!

Можно быстро видеть, как каждая дополнительная модификация требует все большего количества изменений в коде. Поэтому я не делаю прямых преобразований! Вместо этого я делаю промежуточное преобразование. Я выбрал бы одну температуру, сказал бы Kelvin. И первоначально, я преобразовал бы в кельвин. Я затем преобразовал бы кельвин в желаемую температуру. Да, Это действительно приводит к дополнительному вычислению. Однако это делает масштабирование кода тонной легче. добавление добавления новой температурной единицы будет всегда приводить только к двум новым модификациям к коду. Легкий.

Зависит от языка.

Обычно я использовал бы отдельные споры с перечислениями.

Если бы это - объектно-ориентированный язык, то я рекомендовал бы класс температуры, с температурой, сохраненной внутренне однако, Вам нравится, и затем функционирует для вывода его в любых единицах, необходимы:

temp.celsius ();//возвращает температуру объектного временного файла в Цельсия

Несколько вещей:

• Я использовал бы перечислимый тип, который программа проверки синтаксиса или компилятор могут проверить, а не строка, которая может быть введена с опечаткой. В Pseudo-PHP:

  определите ('kCelsius', 0); определите ('kFarenheit', 1); определите ('kKelvin', 2); $a = ConvertTemperature (22, kCelsius, kFarenheit);

Кроме того, для меня кажется более естественным поместить вещь, которой Вы используете на, в этом случае температура, которая будет преобразована, сначала. Это дает логическое упорядочивание Вашим параметрам (преобразуйте - что? от?кому?) и таким образом помогает с мнемоникой.

В этом случае единственные параметры выглядят полностью неясными;

Функциональная температура преобразования от одного масштаба до другого масштаба.
IMO более естественно передать входные и выходные масштабы как отдельные параметры. Я определенно не хочу пытаться схватить формат первого аргумента.