Конструкция метода – ясность или многофункциональность

Я сделал класс как на Java, так и на C #, что позволяет мне выполнять SQL-запросы, в качестве примера у меня есть метод «Delete», который принимает несколько параметров;

public static int Delete(String table, String column, String operand, Object value) 

У меня есть значение как тип объекта, поскольку я могу удалить строки на основе String, Integer или booleans, это означает, что метод достаточно гибкий, чтобы поддерживать разные типы. Затем я добавляю дополнительные «» символы в запрос в зависимости от того, является ли это строкой или нет, используя тест instanceof в Java (или .GetType в C #)

Пример сырой:

 if (value instanceof String) { System.out.println("It's a String"); } else { System.out.println("It's not a String"); } 

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

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

Каков наилучший подход, который следует придерживаться с точки зрения объектно-ориентированных методов?

Спасибо за информацию!

    Ни.

    Вы должны использовать параметризованные запросы.

    Вы правы; вы должны держать его в одном методе.
    В C # иногда бывает полезно сделать такие методы обобщенными.

    Отбросив не заданный вопрос о том, является ли эта архитектура хорошей идеей …

    Как правило, объектно-ориентированный код получается лучше, удаляя, насколько это возможно, явную проверку типов. Это будет означать, что в той степени, в которой это важно, какой тип предоставляется в качестве параметра – версия кода с перегрузками типа может быть лучше. Это только улучшение, однако, если тип параметра известен во время компиляции, конечно, так как это происходит при разрешении перегрузки!

    Кроме того, в версии C # перегрузки методов будут избегать боксирования типов значений.

    Другое (в данном случае), возможно, противоречивое правило состоит в том, что дублирующий код следует удалять как можно больше. Это означает, что лучшим способом сделать это может быть один метод. В этом случае я бы рекомендовал string DelimitValueIfNecessary(object) код типа для других методов ( string DelimitValueIfNecessary(object) ), поскольку такие вещи не являются основной компетенцией метода, который создает инструкции delete.

    Я думаю, что это второе правило более важно, чем первое, поэтому я бы выбрал один метод.

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