Enterprise-версия программы FizzBuzz с правильной архитектурой

    Здравствуй, хабрачитатель. Я – редактор блога ABBYY. Сегодня утром ко мне пришли разработчики, принесли вот этот текст и попросили напечатать. Я не смогла придумать, почему этот текст должен появиться в корпоративном блоге, но разработчики говорят, что он смешной и принесёт радость людям. Так тому и быть!

    Устали от полных кривизны и костылей сложных в поддержке программ? Постоянно слышите о правильной архитектуре, но так и не видели ее? Встречайте на Гитхабе Enterprise-версию программы FizzBuzz, показывающую, как должно выглядеть серьезное решение с правильной архитектурой.

    Изначально FizzBuzz — очень простая программа, задуманная в качестве задания при собеседовании разработчиков для того, чтобы проверить, что они вообще в состоянии писать код. Обычно предполагается, что претендент напишет цикл с цепочным условием внутри и в общей сложности программа займет примерно 10 строк. Это годится в стрессовых условиях собеседования, но не подходит для серьезного бизнеса.

    Enterprise версия решает ту же задачу, используя 10 интерфейсов, заботливо разложенных по пакету com.seriouscompany.business.java.fizzbuzz.packagenamingpackage.interfaces и соответствующее серьезности задачи количество тщательно продуманных классов, разложенных по пакету com.seriouscompany.business.java.fizzbuzz.packagenamingpackage.impl

    Прекрасен класс NewLineStringReturner, который возвращает перенос строки, который затем используется механизмом вывода переноса строки NewLinePrinter. Такое претендент на собеседовании вряд ли напишет – он ничего не понимает в правильной архитектуре.

    Отдельно прекрасен список «проблем»: «не используется XML», «репозиторий должен быть в Perforce», «нужен SOAP API», «нужна многопоточность» и другие в том же стиле. Все эти проблемы наверняка будут скоро решены, и мы получим эталон серьезного решения с правильной архитектурой.

    Наконец-то.
    ABBYY
    144.43
    Решения для интеллектуальной обработки информации
    Share post

    Comments 34

      +10
      Так ведь можно и ООП головного мозга подхватить.
        +4
        Это для уже инфицированных…
          +4
          Наоборот, этот проект — лучшая вакцина от него.
            +3
            Прививка — самый уместный термин здесь.
            0
            Подписался на репозиторий. Надеюсь проект будет развиваться )
            0
            0
            Адский ад!
            Хотя не совсем понял, на что намекал следующий кусок:
            String myString = myStringBuilder.toString();
            return new String(myString);
            

            На то, что энтерпрайз-код на Java нередко пишется индусами?
              +5
              Это очень нужный паттерн. Если вы вернете ссылку на строку, а на эту же строку есть ссылки еще где-то, то «мало ли что» может быть. А если вы создадите новую строку, то возвращаемая вами ссылка точно будет единственной и уже точно «все будет хорошо».
                +3
                Понял. Защита от того случая, если в новой версии Java строки вдруг станут мутабельными :)
                  0
                  Не совсем, по причине описанной выше, такое обычно делается когда именно «все» является объектами (тот же питон), там тоже нужно применять для коллекций например «deep copy». Т.е. это не связано с immutable и прочим.
                  P.S. и это не паттерн, ну т.е. не паттерн проектирования, просто у каждого под «паттерн» что-то свое :S
              +2
              >>Прекрасен класс NewLineStringReturner, который возвращает перенос строки,

              Он не прекрасен а ужасен. Вместо того, что бы сконфигурировать фабрику локалью и культурой и получить класс, возвращающий перенос(или какой-то подобный бред) имеем.
              ================================
              StringBuilder myStringBuilder = new StringBuilder(systemDefaultNewLineString);
              String myString = myStringBuilder.toString();
              return new String(myString);
              ================================
              Ну можно было еще пустой цикл вставить. Ахаха-бугга!
                +2
                Вы серьезно?
                  +6
                  Главное, что остальной код комментатора выше полностью удовлетворяет.
                    0
                    в рамках усугубления — вполне
                      +2
                      ну разве что так.
                      +7
                      Абсолютно. Доведение до абсурда и демонстрация интерпрайза головного мозга — это может быть забавно. Тупой говнокод(еще и бессмысленный к тому же) — нет.
                      ИМХО, конечно.
                    +10
                    Нужно просто убрать FizzBuzz из названия и на собеседовании спрашивать результат выполнения
                      +4
                      Умиление. Джааааавочка! Короткие имена пакетиков!

                      package com.seriouscompany.business.java.fizzbuzz.packagenamingpackage.impl;
                      
                        +2
                        Как-то скучно :) Одно и тоже по всем классам распихано.
                        Лучше бы Spring прикрутили :)
                        +14
                        Еще надо сделать так, чтобы приложение запускалось только под какой нибудь древней версией Java и падало с ошибками на любой свежей, иначе на Enterprise не тянет.
                          +6
                          Я не могу назвать это архитектурой. Сильная связность у класса FizzBuzz.java повергнет разработчика интерпрайза в тяжёлые необратимые психологические мучения при изменении требований.
                          Архитектура — это каркас приложения который позволит в дальнейшем решать подобные задачи с минимальными усилиями. В данном случае необходимо будет написать еще десяток интерфейсов и классов.

                          Нарушена большая часть базовых принципов хорошей архитектуры — SOLID. Разве что Принцип единственной обязанности и Принцип разделения интерфейсов удались на славу.

                          Срочно на рефакторинг!
                            +1
                            При этом надо заметить, что другую крайность никто не упоминает. Например, предложение потратить несколько часов на подумать и потом хоть сколько-нибудь структурировать программу в 90% натыкается на возражение — не хотим делать универсальный всемогутор, это не по аджайлу, да потом перепишем, и все дела
                              0
                              А почему без Spring?
                              +1
                                0
                                Да, как раз напоминает ответ на PHP реализацию сложения в рамках Java.

                                Наше ООП, самое ООпастое ООП в мире…
                                +5
                                Я не совсем понял, почему абсолютно не используется DI? А вдруг я захочу другой генератор новой строки? И что мне теперь, во всех местах менять имплементацию что ли?
                                +1
                                Напоминает эволюцию кода «Hello World».
                                  +5
                                  Если я не знаю большинства примененных в проекте шаблонов и абстракций, это значит, что я плохой программист и не смогу писать на Java?
                                    0
                                    Нет, просто с вами все в порядке :)

                                  Only users with full accounts can post comments. Log in, please.