class SmsSender implements ISender{...}
class EmailSender implements ISender{...}
public class Sender{
private static final ISender smsSender = SmsSender.getInstance();
private static final ISender emailSender = EmailSender.getInstance();
public static ISender getInstance(){
return condition ? smsSender : emailSender;
}
....
}
Не знаю как у вас, у меня ни разу не было случая, что бы это «когда-то» наступило. Закладывать в основу кода, то, что когда-то что-то может изменится, зачастую есть ошибочным, ибо это когда-то никогда не наступит. Но, конечно случаи бывают.
Инициализирую прямо в поле. Конструкторами — тоже хорошая практика. Главное что бы было удобно, и понятно, каждый выбирает как ему удобнее. С конструкторами мне не очень нравится, потому что иногда синглтонов может быть много, и тогда конструктор становится большим и принимать много параметров, и это становится не удобным и не красивым кодом.
Как и любой другой код. Тем же JUnit + Mockito или powermock. Если вы будете писать код в стиле спринга — а именно, сохранять ссылки на синглтон в полях класса — не будет никаких проблем с тем что бы их замокать. + никто не запрещает вам, делать конструктор синглтона не приватным, а пекедж-протектеж, что бы Ваши моки могли без проблемно мокать. Кроме того, end-to-end/интегрейшн тесты никто не отменял. Да и уровень покрытия с ними намного лучше, чем с юнитами. + Автотесты от QA. Не вижу никаких проблем.
Для начала — да есть. Но даже если бы и не было — это не должно быть чем-то страшным. Всё что делает сваггер — принимает JSON с описанием. Никакой магии он не делает, и я не вижу никаких проблем реализовать это в течении одного дня.
https://swagger.io/playing-with-swagger-using-swagger-and-swagger-ui-with-the-play-framework/
На самом деле автор статьи достаточно прав. Используя спринг на проекте — вы все больше и больше пишите кода, не связанного с проектом, но связанный со спрингом. В некотором смысле, спринг обязывает вас говнокодить. Код должен содержать бизнес логику, а не фабрики, интерфейсы, конверторы, дто и т д. В этом и есть «болезнь» джавы, потому что когда-то давно «умные» дяди придумали кучу стандартов под маркой Java EE, и все фреймворки начали под него подстраиваться. Ребят, задайте вопрос, «что делает спринг у меня на проекте»? Делает DI? А сколько у вас реализаций на интерфейс? Одна?? Так какой это нахрен DI? То есть вы юзаете спринг для того что бы создать ОДИН СРАНЫЙ СИНГЛТОН? Рилли??? Service/@Repository/@Controller и для этого всего-то спринг??? Так может вы просто не знаете как писать тестируемый код с синглтонами? Так почитайте! Опять таки. Спринг, даже со своей гибкостью кривой! И не покрывает некоторые простейшкие случаи! К примеру Spring-Data-Jpa. Простейший кейс. Почему нельзя было добавить слово limit в синтаксис spring-data??? Почему когда дело доходит до более-менее сложных операций (а не CRUD) постоянно приходится отходить от «идеалов» спринга, и постоянно что-то дописывать? Ребят, если вы говорите что спринг мега-крутой и хороший фреймвок, скорее всего вы просто не пробовали что-либо другое. Попробуйте пописать годик-два проект например на Play Framework-е, желательно на старом, что бы без DI. Попробуйте Vert.X с его реактивным программированием. Или попробуйте сами построить нужную вам архитектуру на простом веб-сервере, без сервлетов вообще. Попробуйте писать код БЕЗ JPA, продумайте архитектуру и тогда вы начнете мыслить по другом. А то у нас бл*ть не программист, а Senior Spring-Framework Developer, и если что-то не входит в спринг, не в силах решить проблему. А самое интересное, что отказавшись от спринга, вы хоть и напишите «маленький» велосипед в виде кастомной архитектуры. НО! Вы увидите, что ваш код стал намного чище и намного гибче, чем со спрингом. И вы имеет ПОЛНЫЙ контроль над своим кодом! Я пишу на джаве с 2010 года, за это время были совершенно разные проекты с соершенно разными подходами. И к огромному сожалению, я заметил, что мода «богатых дядек» на ентерпрайз только усугубляет вещи в джаве. «Типичные вещи» в джаве можно делать намного проще, чем вы можете себе представить. (PHP программисты наверное офигивают, когда видят, как на джаве пишутся веб приложения, потому что у них нету джава ЕЕ, спринга и т.д., и там всё гораздо чище и проще).
Жителям бывшего СССР это не грозит.
Сначала нужно сделать дороги и инфраструктуру.
Потом интеграцию инфраструктуры с сетью, и предоставить открытый API для получения информации о ситуации.
И ВОЗМОЖНО только после этого, беспилотники гугл будут у нас.
Не знаю как у вас, у меня ни разу не было случая, что бы это «когда-то» наступило. Закладывать в основу кода, то, что когда-то что-то может изменится, зачастую есть ошибочным, ибо это когда-то никогда не наступит. Но, конечно случаи бывают.
https://swagger.io/playing-with-swagger-using-swagger-and-swagger-ui-with-the-play-framework/
Это форк IntelliJ IDEA с поддержкой C# и Unity.
Сначала нужно сделать дороги и инфраструктуру.
Потом интеграцию инфраструктуры с сетью, и предоставить открытый API для получения информации о ситуации.
И ВОЗМОЖНО только после этого, беспилотники гугл будут у нас.