Ответы пользователя по тегу ООП
  • Зачем нужно ООП?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Абстракции являются способом добавить системе модульности. Потому что требования к (крупной) системе постоянно меняются. Тут заменяемость и расширяемость - важные факторы. Обычно это еще называют "гибкостью". Привязываться к конкретным имплементациям - очень быстро выходит боком. Поэтому все на абстракциях, даже там где они возможно не нужны. Но поскольку инженер не знает, что заказчик захочет завтра - сразу все заворачивает в абстракции. Отсюда появляется масса кода который просто поддерживает эту расширяемость. Поэтому когда смотришь на конечный продукт и на тот код из которого он сделан, думаешь это ведь можно было уместить в 100МБ, а у нас система на 6 Гб. Да, если конечный алгоритм отлить в железе он будет компактным но не будет расширяемым. Это "цена" за возможность внесения корректировок в систему, не переделывая систему целиком.
    Ответ написан
    Комментировать
  • Как избежать глаголов в наименовании классов?

    lxsmkv
    @lxsmkv
    Test automation engineer
    DataForUserCreation или UserCreationDTO
    Ответ написан
    Комментировать
  • Как залезть на несколько уровней абстракции ниже, не плодя кривой код?

    lxsmkv
    @lxsmkv
    Test automation engineer
    может запрашивать только команды для определенного сервиса? при таком подходе можно выполнять обработку асинхронно. будет выигрыш в перформансе. (чем больше логики в передающем механизме тем больше он становится узким местом. парсинг xml вообще дело сравнительно медленное) тогда разбирать сваленные в кучу данные придется сервису подающему вам данные.
    Ответ написан
    Комментировать
  • Как назвать простейший класс?

    lxsmkv
    @lxsmkv
    Test automation engineer
    "$1"
    Обоснование: пока вы придумываете название классам - индусы деплоят свои поделки на продакшн.
    Ответ написан
    2 комментария
  • Как избавиться от повторяющегося кода?

    lxsmkv
    @lxsmkv
    Test automation engineer
    В пхп вроде есть mixins, называются traits php.net/manual/en/language.oop5.traits.php
    Ответ написан
    Комментировать
  • Почему не работает код?

    lxsmkv
    @lxsmkv
    Test automation engineer
    интерфейс не может имплементировать интерфейс а только расширять (extends)
    Ответ написан
    Комментировать
  • Как понять создание дочернего экземпляра типа родителя?

    lxsmkv
    @lxsmkv
    Test automation engineer
    class Main {
      public static void main(String[] args) {
        Phone p = new MyPhone();
        p.sayHello();
      }
    }
    class Phone{
      void sayHello(){System.out.println("Hello Phone");}
    }
    class MyPhone extends Phone{
      void sayHello(){System.out.println("Hello MyPhone");}
    }

    дочерний класс переписывает/перекрывает (overrides) метод родительского класса. Если убрать имплементацию из дочернего класса то будет вызван родительский метод. Используется тип ссылки более общего типа, потому что это "наименьший общий делитель" всего семейного древа, так сказать. Дочерние классы могут может еще много чего, но то что определено в родительском классе они могут гарантированно.
    Ссылка родительского общего типа может использоваться при обходе коллекций, когда эелементы коллекции могут быть разными детьми но нужно у каждого вызвать этот метод. Так работает например шаблон наблюдатель. Используется тип интефейса как общий знаменатель, все классы которые хотят получать обновления, заносятся в список. И когда событие наступает, пробегаем список и у каждого элемента дергаем метод update, a что произойдет при update решает каждый класс для себя сам.
    Ответ написан
    Комментировать
  • Почему говорят, что ООП это зло?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Парадигма программирования навязывает (в нейтральном смысле слова) определенный образ мышления при анализе и декомпозиции задачи. Говорить что ооп это зло все равно что говорить что вегетарианство это зло. Другая перспектива она не лучше и не хуже - она другая. Domain Driven Design это подход к декомпозиции задачи для впихивания ее в объектно-ориентированную модель так чтобы обьекты/классы соотносились с обьектами реального мира из области применения. Логично. Просто когда это все объекто ориентированное добро начиналось люди писали классы просто чтобы впихнуть туда свои функции, и класс был просто контейнером функций и не был вроде как по сути объектно-ориентированным. Оно и до сих пор часто так. Эти всякие ConnectionManager, CoreUtilInitializer и прочее, попытка разделить классы по задаче в алгоритмической иерархии а не в соответствии с реальными действиями пользователя. Ну вот оттуда эта вся дискуссия на тему и произрастает. Художники гиперреалисты говорят мол нужно больше деталей, а абстракционисты говорят -меньше. И те и те художники. Так что переживать не о чем, правда у каждого своя :)
    Ответ написан
    1 комментарий
  • Как правильно с точки зрения ООП?

    lxsmkv
    @lxsmkv
    Test automation engineer
    То что вы сделали похоже на шаблон Factory (передаем параметры обьекта на вход, получаем обьект на выходе). https://ru.wikipedia.org/w/index.php?title=Factory
    Все что по шаблонам - все фен-шуй. Другой вопрос выгодно ли применять тот или иной шаблон для конкретной задачи.
    Ответ написан
  • Как наилучшим способом протестировать программу?

    lxsmkv
    @lxsmkv
    Test automation engineer
    если система имеет интерфейсы и новый функционал строится используя имеющиеся интерфейсы, то "сломать" систему невозможно. Интерфейсы на то и интерфейсы.
    https://habrahabr.ru/post/30444/
    Ваша задача - гарантировать неизменность интерфейсов. Для этого нужно код покрыть юнит-тестами, которые бы указывали разработчикам если рефакторинг нарушает существующий интерфейс. Еще есть конечно опасения, что не имея представления об имеющихся функциях будут строить велосипед рядом. Но тут нужно предоставить документацию.
    Ответ написан
    Комментировать
  • Почему не public переменная, а функции get/set?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Допустим есть класс барометр, у него переменная давление, которая постоянно записывается с датчика давления. Все подсистемы которые будут обращаться к вашему классу, смогут взять и перезаписать значение переменной. Переменная-то глобальная. В самолете например, а? Я в такой самолет не сяду под дулом пистолета :)
    В системах с повышеными требованиями к безопасности, да и не только, необходимо контролировать доступ к переменным. Вот вы и пишете public обертку для чтения private переменной. Функция записи в таком случае будет тоже private. Никто не должен иметь доступа к записи переменной, кроме самого класса.
    Ответ написан
    Комментировать
  • Возможно ли в java унаследовать generic класс, другим generic классом?

    lxsmkv
    @lxsmkv
    Test automation engineer
    "restrict generic type java" загуглил и вот:
    https://docs.oracle.com/javase/tutorial/java/gener...
    Ответ написан
    Комментировать
  • Как лучше разбить логику?

    lxsmkv
    @lxsmkv
    Test automation engineer
    На мой взгляд указаные функции относятся к работе с учетной записью и разделять их не нужно. Выглядеть это может как-то так:
    AccountManager.is_account_available_for_username(..)
    AccountManager.create_new_account_with_uname_and_pw(..)
    AccountManager.remove_authentication_for_user(..)
    AccountManager.log_in_user(..)
    AccountManager.is_user_logged_in(..)

    Принадлежность этих функций классу АccountManager мне видится логичной.
    Ответ написан