Разве внедрение зависимости Spring не повреждает сокрытие информации?
Эти фрагменты кода могут быть полезны. Если вы хотите отсортировать объект в моем случае, я хочу сортировать по VolumeName:
public List<Volume> getSortedVolumes() throws SystemException {
List<Volume> volumes = VolumeLocalServiceUtil.getAllVolumes();
Collections.sort(volumes, new Comparator<Volume>() {
public int compare(Volume o1, Volume o2) {
Volume p1 = (Volume) o1;
Volume p2 = (Volume) o2;
return p1.getVolumeName().compareToIgnoreCase(
p2.getVolumeName());
}
});
return volumes;
}
Это работает. Я использую его в jsp.
8 ответов
Если Вы код к интерфейсам , только необходимо представить методы set на реализациях. Поскольку Вы вводите интерфейсы в другие части системы, они не могут получить доступ к деталям реализации или состоянию объектов.
Я соглашаюсь с Вашей точкой зрения - вот почему я предпочитаю инжекцию конструктора.
Вам, (вероятно), придется сделать метод set, который сообщит за пределами некоторых Ваших внутренних деталей, но нет никакой потребности сделать метода get. Таким образом, Вы показываете приблизительно информация, но не действительно слишком много; это ни для чего не действительно полезно кроме своей намеченной цели.
Дополнительно я просто рекомендовал бы использовать аннотации и @Autowired, в этом случае Вы не должны делать общедоступный метод set.
При использовании пружинных аннотаций (@Autowired), Вы можете члены парламента, не занимающие официального поста DI.
, Если Вы идете для слабой связи и (единицы) тестируемость, по моему мнению, DI пружин вспыхивает информация, которая не должна быть скрыта.
У меня был в основном тот же вопрос здесь:
Инкапсуляция в возрасте платформ
я думаю, что ответ мог бы быть инжекцией конструктора. Представление Ваших свойств с методами set делает его действительно трудно к ecapsulate чем-либо, и поддержите хорошее объектное состояние.
Я предполагаю, что это - компромисс. Вы уменьшаете соединенные проводами зависимости, но Вы потенциально представляете кишки своей реализации. С правильными абстракциями можно уменьшить это также, но тогда Вы увеличиваете сложность кодовой базы (например, имея универсальное "Соединение", которое могло быть соединением LDAP или соединением SQL).
Лично, я не думаю с помощью инжекции конструктора, помогает с ним, также, потому что это более концептуально.
я должен буду проверить @Autowire, все же.
tj
Никогда не использовал @Autowired, мне нравится использовать параметры в конструкторах, но иногда трудно понять, что означают параметры, особенно если у вас много параметров - в этом случае я предпочитаю использовать подход «Builder», описанный в Эффективной Java. Конструктор получает объект сборки (у которого есть сеттеры) и строит себя с ним. Внедренные атрибуты класса являются окончательными (неизменяемость), класс «Builder» содержит сеттеры, но не геттеры (в этом нет необходимости, поскольку мы объявляем его внутренним классом создаваемого класса), и сеттеры не нужны будет создан только для Spring:
<bean id="runnable" class="MyClass">
<constructor-arg>
<bean class="MyClass$Builder">
<property name="p1" value="p1Value"/>
<property name="p2" value="p2Value"/>
<property name="p3" value="p3Value"/>
<property name="p4" value="p4Value"/>
</bean>
</constructor-arg>
</bean>
Код класса:
public class MyClass {
private final String p1;
private final String p2;
private final String p3;
private final String p4;
public MyClass(Builder builder) {
this.p1 = builder.p1;
this.p2 = builder.p2;
this.p3 = builder.p3;
this.p4 = builder.p4;
}
...
public static class Builder {
private String p1;
private String p2;
private String p3;
private String p4;
public void setP1(String p1) {
this.p1 = p1;
}
... and so on
}
}
Просто хотел упомянуть, что я Я (непреднамеренно) опубликовал более общую версию этого вопроса и что в ней есть некоторые дополнительные сведения о проблеме: Должно ли внедрение зависимости происходить за счет инкапсуляции?