Зачем концептуально нужны интерфейсы?
> В каком случае следует концептуально использовать интерфейсы?
Когда одну реализацию можно заменить на другую реализацию.
> И если я пишу класс для менеджера базы данных (mySQL) в своем инет-магазине, то стоит ли мне все сигнатуры вынести в интерфейс, если позже планируется миграция с mySQL на MSSQL?
Если это получается довольно просто, то стоит.
> И где при этом оставить стринговые константы SQL-запросов, в классе, имплементирующем интерфейс или вынести в сам интерфейс?
Смотря где проходит линия интерфейса.
Когда одну реализацию можно заменить на другую реализацию.
> И если я пишу класс для менеджера базы данных (mySQL) в своем инет-магазине, то стоит ли мне все сигнатуры вынести в интерфейс, если позже планируется миграция с mySQL на MSSQL?
Если это получается довольно просто, то стоит.
> И где при этом оставить стринговые константы SQL-запросов, в классе, имплементирующем интерфейс или вынести в сам интерфейс?
Смотря где проходит линия интерфейса.
> И где при этом оставить стринговые константы SQL-запросов, в классе, имплементирующем интерфейс или вынести в сам интерфейс?
Смотря где проходит линия интерфейса.
не совсем так. Интерфейс - это набор сигнатур функций. Если он еще включает какие-то данные или логику, то это уже не интерфейс, а абстрактный класс.
В общем, ничего не мешает сделать (высокоуровневый) интерфейс "менеджера данных", реализующий его абстрактный класс "менеждер данных СУБД" и производные от него классы настроенные уже непосредственно на MSSQL или MySQL
Если данные запихать в enum или константы - то тогда можно это будет назвать интерфейсом?
В Яве интерфейс вполне может содержать static final поля.
Если эти static final поля буду содержать СУБД-ориентированные SQL-запросы, то при переходе на другую СУБД они могут не работать.
Поэтому, похоже, надо SQL-запросы выносить в класс.
Поэтому, похоже, надо SQL-запросы выносить в класс.
перечисляемый тип - это само по себе, набор констант (кстати, фактически - тоже перечисляемый тип) - само по себе. Интерфейс, конечно, может от них зависить (например, параметр метода - перечисляемого типа, или одна из констант но содержать не может.
Что то не ясно о чем разговор 
Если и есть формальное определение того, что такое интерфейс то это interface в Java. Никаких enum-ов в ней нет. А если вы про С++, где они есть, так там нет слова interface так что нет смысла спорить, что интерфейс может содержать, а чего нет.
Если же заниматься философским вопросом, что следует называть интерфейсом, то мое мнение -- практически что угодно. Понятие интерфейса даже к ООП не имеет отношения. Написал 3 прототипа в С-шный header вот тебе и интерфейс. Формат BMP файла -- это тоже в некотором смысле интерфейс.
Если и есть формальное определение того, что такое интерфейс то это interface в Java. Никаких enum-ов в ней нет. А если вы про С++, где они есть, так там нет слова interface так что нет смысла спорить, что интерфейс может содержать, а чего нет.Если же заниматься философским вопросом, что следует называть интерфейсом, то мое мнение -- практически что угодно. Понятие интерфейса даже к ООП не имеет отношения. Написал 3 прототипа в С-шный header вот тебе и интерфейс. Формат BMP файла -- это тоже в некотором смысле интерфейс.
Я вот к этому и клоню.
Что если рассматривать интерфейс, как логическую сущность, то в этом случае, в интерфейсе может быть все что угодно
Что если рассматривать интерфейс, как логическую сущность, то в этом случае, в интерфейсе может быть все что угодно
если позже планируется миграция с mySQL на MSSQL?
Программирование - не то место, где можно "подстелись соломку" даже зная где упадешь.
То есть, что бы ты не предпринял заранее, миграция вряд ли будет легкой. Нельзя составить адекватный интерфейс просто медитируя, сидя на диване. Обязательно придется долго прощупывать его с обеих сторон - и со стороны реализации, и со стороны использования. Это как метафизика уступила место экспериментальной физике. Будет большой победой, если этот интерфейс в итоге сформируется уже после, точнее во время этой самой миграции на M$SQL. Я это все говорю не из-за больших познаний в mySQL, а просто из общих соображений. 
Итого. Стоит ли задумываться о предстоящем переходе на MSSQL при программировании реализации под mySQL?- да. Но провести удачный разрез - это не формальная деятельность, а весьма интеллектуальная и творческая, так что
стоит ли мне все сигнатуры вынести в интерфейс
совсем не отражает сути этой деятельности. А уж
где при этом оставить стринговые константы SQL-запросовэто совсем мелочи.
Спасибо за внимание.
могу посоветовать только одно (из того, что я здесь обсуждается):
Перепиши все вункции для работы с базой как отдельный надор или клас... Потом просто заменишь внутри своих функций стандартные функции для MySQL на msSQL..
Перепиши все вункции для работы с базой как отдельный надор или клас... Потом просто заменишь внутри своих функций стандартные функции для MySQL на msSQL..
Оставить комментарий
stm7481822
В каком случае следует концептуально использовать интерфейсы?И если я пишу класс для менеджера базы данных (mySQL) в своем инет-магазине, то стоит ли мне все сигнатуры вынести в интерфейс, если позже планируется миграция с mySQL на MSSQL?
И где при этом оставить стринговые константы SQL-запросов, в классе, имплементирующем интерфейс или вынести в сам интерфейс? Насколько я знаю, некоторые запросы для mySQL и MSSQL могут отличаться.