Интерфейсы должны быть помещены в отдельный пакет? [закрытый]
Я смотрел на ту же проблему и пока не нашел идеального ответа для моей ситуации, но это может быть полезно для вас. Я довольно новичок в полнотекстовом поиске, поэтому любые эксперты тоже мне помогут.
Я делаю два выражения MATCH () ПРОТИВ () в выборке и объединяю оценки каждого из них, чтобы сформировать общую релевантность. Назначение различных множителей позволяет мне настраивать важность каждого набора результатов.
Мой первый MATCH () проверял бы по буквальному (или точному) поисковому запросу, используя двойные кавычки. Мой второй MATCH проверял бы нормально. Я применяю более высокий множитель к первому совпадению, поэтому он должен иметь более высокое значение релевантности, если он найден.
Примерно так.
SELECT *, ((MATCH(indexes) AGAINST ('"search_terms"' IN BOOLEAN MODE) * 10)
+ (MATCH(indexes) AGAINST ('search_terms' IN BOOLEAN MODE) * 1.5)) AS relevance
FROM ...
WHERE ...
AND (MATCH (indexes) AGAINST ('"search_terms"' IN BOOLEAN MODE) > 0
OR MATCH (indexes) AGAINST ('search_terms' IN BOOLEAN MODE) > 0)
...
ORDER BY relevance DESC
Если вы запустите функцию EXPLAIN, чтобы показать, как работает запрос, вы обнаружите, что дополнительные предложения MATCH () AGAINST () фактически не добавляют никаких накладных расходов к запросу из-за того, как работает MySQL.
9 ответов
Placing both the interface and the implementation is common place, and doesn't seem to be a problem.
Take for example the Java API -- most classes have both interfaces and their implementations included in the same package.
Take for example the java.util package:
It contains the interfaces such as Set, Map, List, while also having the implementations such as HashSet, HashMap and ArrayList.
Furthermore, the Javadocs are designed to work well in those conditions, as it separates the documentation into the Interfaces and Classes views when displaying the contents of the package.
Having packages only for interfaces may actually be a little bit excessive, unless there are enormous numbers of interfaces. But separating the interfaces into their own packages just for the sake of doing so sounds like bad practice.
If differentiating the name of a interface from an implementation is necessary, one could have a naming convention to make interfaces easier to identify:
Prefix the interface name with an
I. This approach is taken with the interfaces in the .NET framework. It would be fairly easy to tell thatIListis an interface for a list.Use the -
ablesuffix. This approach is seen often in the Java API, such asComparable,Iterable, andSerializableto name a few.
Я предпочитаю их в одном пакете. Нет смысла создавать пакет специально для интерфейсов. Это особенно излишне для команд, которым просто нравятся их префиксы и суффиксы интерфейсов (например, «I» и «Impl» для Java).
Если есть необходимость опубликовать набор интерфейсов как общедоступный API, это имеет больше смысла чтобы сохранить их в отдельном проекте и вместо этого создать зависимости проекта. Но все сводится к предпочтениям и удобству ситуации, я полагаю.
Put them in packages that reflect your projects. It is fine and common to put interfaces and implementations together if they're part of the same project, but if you're writing an API, then someone else would likely be choosing a package name relevant to their project.
In general, if it's for the same project, I don't see any benefit in keeping the interfaces in a separate package from their impls. If it's getting cluttered, there may be other package naming issues, irrespective of the interface arrangement.
У меня нет большого опыта работы с Java, но мне нравится делать это как хорошую практику в C # /. NET, потому что это допускает расширение в будущем, когда сборки с конкретными классами, реализующими интерфейсы не могут быть полностью распространены до клиента, поскольку они передаются фабрикой посредников или по сети в сценарии веб-службы.
Один из аргументов в пользу размещения интерфейсов в разных пакетах состоит в том, что проще создавать jar-файлы api, которые могут быть распространяются среди потребителей вашего продукта или услуги. Вполне возможно сделать это с интерфейсами и реализациями вместе, но проще создать сценарий, если они находятся в разных пакетах.
Во многих фреймворках, таких как OSGi, это почти обязательно. Я думаю, что это способствует более слабому соединению на уровне упаковки, а не на уровне банки.
Для любого языка их можно собрать в одном пакете. Важно то, что открыто для внешнего мира и как это выглядит снаружи. Никто не будет знать и не заботиться о том, находится ли реализация в том же пакете или нет.
Давайте посмотрим на этот конкретный экземпляр.
Если у вас есть все общедоступные объекты в одном пакете, а частные - в другом пакете, который не является общедоступным выставлен, клиент библиотеки видит один пакет. Если вы перемещаете личные вещи в пакет с общедоступными вещами, но не открываете их изнутри пакета, клиент видит в точности то же самое.
Таким образом, это пахнет правилом без веской причины: он принимает решение на основании чего-то публично видимого, но это решение не оказывает никакого влияния на то, что публично видно.
Это сказал, что если в каком-то конкретном случае кажется хорошей идеей разделить интерфейс и реализацию на отдельные пакеты, продолжайте и сделайте это. На ум приходят причины для этого: пакет огромен или у вас есть альтернативная реализация, которую вы, возможно, захотите подключить вместо стандартной.
если в каком-то конкретном случае кажется хорошей идеей разделить интерфейс и реализацию на отдельные пакеты, сделайте это. На ум приходят причины для этого: пакет огромен или у вас есть альтернативная реализация, которую вы, возможно, захотите подключить вместо стандартной. если в каком-то конкретном случае кажется хорошей идеей разделить интерфейс и реализацию на отдельные пакеты, сделайте это. На ум приходят причины для этого: пакет огромен или у вас есть альтернативная реализация, которую вы, возможно, захотите подключить вместо стандартной.Мы делаем это там, где я работаю (то есть: помещаем интерфейс в один пакет, а реализацию в другой), и главное преимущество, которое мы получаем от этого, заключается в том, что мы можем легко переключаться между реализациями.
Yes, it's a very good practice, because it allows you to publish the interface without publishing your specific implementation. That said, if you have no need to publish external interfaces, there's no problem with putting the interface definitions in the same package as the implementation.