Недавно я просматривал всегда популярную Эффективная Java автор: Джошуа Блох (Addison-Wesley, 2018). Надеюсь, если вы разработчик Java, вы не в первый раз слышите об этой книге. Возможно, вы похожи на меня, и когда вы впервые увидели это, вы подумали: “Это, наверное, старое и устаревшее”. Действительно, первое издание было выпущено в начале 2000-х годов. Однако, услышав много блестящих рекомендаций, я решил, что должен попробовать. Излишне говорить, что я был приятно удивлен. Увы, это неудивительно, хороший дизайн на самом деле не выходит из моды (мы все еще говорим о Gang of Four не так ли?)
Имея все это в виду, почему именно эта серия? Честно говоря, эгоистично, причина номер один – это я сам. Я твердо верю в то, что лучший способ чему-то научиться – это научить этому. Тем не менее, у меня есть любовь к хорошему дизайну, и я хотел бы поделиться этой любовью и, надеюсь, помочь другим узнать что-то новое и применить это на практике. Сказав это, я решил, что попытаюсь взять некоторые принципы из книги и делиться новыми каждую неделю. Пытаюсь оказать на себя небольшое давление, но в то же время дать себе темп для публикации.
Наконец, является ли эта серия заменой книге? Вовсе нет, я все же настоятельно рекомендую вам взять эту книгу в руки. Надеюсь, это может послужить дополнением к книге и дать вам другую точку зрения на темы, затронутые в ней.
Без лишних слов, давайте начнем.
Глава первая: Статические фабрики против Конструкторы
Одна из первых вещей, которые вы учитесь делать, когда начинаете заниматься объектно-ориентированным программированием (ООП), – это создавать объекты. Было бы бесполезно иметь все эти объекты, если бы вы не могли их создать. Обычно мы учимся создавать объекты с помощью конструкторов. Конструкторы довольно просты и понятны так что это действительно имеет смысл и может сослужить нам хорошую службу. Еще один вариант, который у нас есть и к которому, по мнению автора, многие программисты не прибегают, когда, возможно, им следует прибегнуть, – это статический фабричный метод. Итак, что такое статический фабричный метод? Проще говоря, статический фабричный метод – это статический метод, который возвращает и экземпляр класса. Итак, на что это похоже:
LocalDateTime date = new LocalDateTime(Instant.now());
против
LocalDateTime date = LocalDateTime.ofInstant(Instant.now());
Определенно, между ними нет большой разницы. Итак, какие преимущества дает фабричный метод?
Заводские Методы Могут Иметь Имена
Когда я впервые начал разрабатывать программное обеспечение, я не думаю, что понимал силу хорошего именования. Конструкторы не имеют возможности именоваться. Поскольку у них не может быть разных имен, у вас также не может быть двух конструкторов, которые выполняют разные действия и принимают одни и те же параметры в одном и том же порядке. Так, например, если бы мы хотели добавить к классу LocalDateTime конструктор, который занимает мгновение и создает LocalDateTime, который является случайным временем до указанного мгновения, скажем, как мы могли бы это сделать с помощью конструкторов? Измените его на что-то вроде?
LocalDateTime dateTime = new LocalDatetime(Instant.now(), shouldBeBefore);
Абсолютно нет. Но с помощью фабричного метода мы могли бы написать следующее:
LocalDateTime datetime = LocalDatetime.randomTimeBeforeInstant(Instant.now());
Намного чище.
Еще один трюк, который будут использовать программисты, – это изменение порядка параметров, это может быть не так грубо, как в приведенном выше примере но будущим разработчикам будет чрезвычайно трудно понять, кто что делает. Таким образом, это не большая победа в плане ремонтопригодности.
Заводские методы Не требуются для создания Нового Объекта каждый раз
Конструкторы по своей природе обязаны создавать новый объект каждый раз, когда они вызываются. Это не так с методами. Подумайте об одноэлементном шаблоне, с которым большинство знакомо. На самом деле шаблон, который использует статический фабричный метод! Само назначение метода getInstance в одноэлементном шаблоне не заключается в создании нескольких экземпляров. Есть и другие варианты. Возвращает кэшированные значения или перечисления.
Фабричные методы Могут Возвращать Объект Любого Подтипа Возвращаемого типа Методов
Это хорошая возможность иметь. Возможность отделить это требование от интерфейса дает нам дополнительные возможности. Это также дает вам возможность возвращать различные подтипы на основе параметров, переданных функции. Таким образом, мы можем не только возвращать подтипы, но и динамически выбирать подтипы для возврата во время выполнения. Продолжая развивать это, мы можем даже возвращать экземпляры классов, которые не существовали, когда был написан фабричный метод. Опять же, это приводит к большему количеству вариантов. Хороший дизайн часто сводится к тому, чтобы оставить варианты открытыми.
Так каковы некоторые недостатки заводских методов:
Они Влияют на Нашу Способность Использовать Наследование
Если все, что вы предоставляете пользователям вашего класса, – это фабричные методы и никаких открытых конструкторов, то нет возможности использовать наследование с этим классом. Это также можно рассматривать как преимущество (выпускные классы уже делают это). Просто еще один раз подумать о композиции, а не о наследовании. Это то, что мы должны иметь в виду при использовании этого метода.
Их может быть сложнее найти в общедоступном API
Поскольку конструкторы являются особенными, они выскакивают из документации и классов. Итак, как мы можем снизить этот риск? Один надежный способ – следовать соглашениям об именовании заводских методов. Некоторые из них из , из , getInstance ,
Дубль Кайла:
Я думаю, что это надежный инструмент для пояса с инструментами. Хотя мне все еще трудно использовать это в качестве базового примера того, что я делаю каждый раз, я стараюсь помнить об этом. Еще одна забавная часть паттернов заключается в том, что после нескольких лет разработки вы обнаруживаете, что натыкаетесь на эти паттерны и используете их, сами того не осознавая. Этот паттерн ничем не отличается. В моей жизни разработки и раньше были случаи, когда я использовал синглтоны, а также более общие статические фабричные методы. Всегда приятно слышать, что то, что вы сделали, является реальным шаблоном, который использовали другие.
А как насчет тебя? Вы использовали этот шаблон раньше? Как это сработало для вас?
Оригинал: “https://dev.to/kylec32/effective-java-tuesday-let-s-consider-static-factory-methods-170p”