Неужели невозможно скрыть некоторые классы в jar файле?
Я хотел не допускать прямого создания экземпляров классов, чтобы сделать его более гибким. Из этой банки должен быть виден только завод (или фасад).
Есть ли другой способ, кроме как решить эту проблему, кроме создания двух проектов? (Два проекта: первый содержит классы (реализация), а другой ссылается на первый и содержит фабрику; позже будет ссылка только на второй)
Я думаю, у вас будет либо сбой компилятора, либо предупреждение, если ваш общедоступный фабричный метод попытается вернуть что-то «скрытое».
Нет, вы не можете скрыть публичный класс, не реализовав свой собственный ClassLoader, не используя OSGi или что-то подобное.
Что вы можете сделать, так это отделить интерфейс api от реализации, например иметь один проект, содержащий только интерфейсы, и другой проект, содержащий имплементации. Однако скрыть классы реализации по-прежнему нельзя.
Я понимаю, что вы не хотите скрывать фактические классы, просто предотвращайте их построение за пределами фабричного класса. Я думаю, что этого можно довольно легко достичь, используя частную (по умолчанию) видимость пакета в конструкторах классов. Единственное ограничение заключается в том, что вам нужно иметь классы и фабрику в одном пакете, поэтому в средней и большой кодовой базе все может стать излишне сложным.
Если я правильно понимаю ваш вопрос, вы хотели бы убедиться, что пользователи вашей библиотеки вынуждены использовать вашу фабрику для создания экземпляров своих объектов, а не использовать сами конструкторы.
На мой взгляд, есть две возможности, одна из которых глупая, но может использоваться в немногих конкретных случаях, а другая - наиболее практичный и, вероятно, наиболее часто используемый способ сделать это.
protected, чтобы ограничить доступ к конструкторам вашего класса. Это обычная практика при использовании заводского шаблона.Обфускация может помочь вам как-то.
Со стандартными загрузчиками классов и простыми старыми файлами jar это невозможно. В OSGi есть концепция сделать видимыми только некоторые пакеты для другого пакета (т. Е. Разделение общедоступного API и внутренней реализации).
Если вы используете eclipse, вы можете применить такие правила с помощью this
Если я правильно вас понял, когда вы говорите «не разрешать прямое создание экземпляров классов, чтобы сделать его более гибким», правильно выполненный паттерн фасада справится с этим.
Ограничьте конструкторы всех классов, которые вы хотите скрыть, областью пакета. Откройте класс фасада в публичной области.
http://mindprod.com/jgloss/packagescope.html
«Если у вас есть переменная или метод в вашем классе, к которым вы не хотите, чтобы клиенты вашего класса имели прямой доступ, не давайте ему публичное, защищенное или частное объявление. Из-за недосмотра в дизайне Java вы можете» t явно объявить доступность «пакета» по умолчанию. Другие члены пакета смогут его видеть, но классы за пределами пакета, наследующие от вашего, не будут. Атрибут защищенного доступа обеспечивает немного более заметную видимость. Защищенный метод виден для наследования классов, даже если они не являются частью одного и того же пакета. Метод области действия пакета (по умолчанию) - нет. Это единственное различие между защищенной областью и областью пакета ».
Есть два решения вашего вопроса, которые не связаны с хранением всех классов в одном пакете.
Первый - использовать шаблон Friend Accessor / Friend Package, описанный в (Практическое проектирование API , Тулач 2008).
Второй - использовать OSGi. здесь, объясняющая как OSGi это делает.
Связанные вопросы: 1, 2, 3 и 4.
Вы можете творить такую магию с помощью специального загрузчика классов, но:
В таких ситуациях я бы сделал что-то похожее на то, что мы можем видеть в стандартной Java. Например, вы видите javax.xml.stream.XMLInputFactory, но где-то у вас есть com.sun.xml.internal.stream.XMLInputFactoryImpl. Он отлично компилируется, если вы напишете:
new com.sun.xml.internal.stream.XMLInputFactoryImpl()
хотя вы вряд ли это сделаете :-) С помощью системного свойства вы можете контролировать фактическую загружаемую реализацию. Мне такой подход подходит во многих ситуациях.
Надеюсь, я правильно понял ваш вопрос;)
Ваше здоровье!
