OO & Application Objects

Question

В приложениях OO обычно используется класс приложения, в котором содержатся руководители высшего уровня или что-то еще. Это затрудняет отсутствие глобального объекта theApp или использование Singleton или что-то в этом роде.

Имеет ли это значение? Должны ли мы стремиться сделать это как ОО, насколько это возможно, или признать, что принципы ОО иногда ломаются?

Answer 1

Имеет ли это значение? Должны ли мы стремиться сделать это как ОО, насколько это возможно, или признать, что принципы ОО иногда ломаются?

Иногда теория ОО встречается с реальным миром, и вы должны стремиться к тому, чтобы все работало для ваших клиентов в первую очередь. Синглтон здесь или там не является проблемой для вашего клиента или для удобства обслуживания.

ООП в основном там, чтобы сделать код более удобным для обслуживания, повторного использования и понимания. Пока эти цели выполняются, нет необходимости в рефакторе только по соображениям чистоты.

Answer 2

Наличие глобального theApp объекта singleton не обязательно нарушает принципы OO, если данные, привязанные к нему, правильно инкапсулированы и еще много чего.

Существует также ситуация, когда на самом деле у немногих ОС есть ядро ​​OO, что означает, что Application Loader не является Object Oriented для начала.

В любом случае абсолютизм в этом пункте опасен; некоторые языки программирования имеют (ИМО) чрезмерно усердный подход ко всему этому, диктуя каждую функцию как метод или тому подобное, даже если это не лижет смысла. (System.Math.sin(x), кто-нибудь?)

Самый эффективный подход обычно смешивает две методологии, используя функции для функций и методы для методов; и, наконец, используя синглтоны для вещей, которые действительно являются единственными; таких как объект приложения или интерфейсы к , некоторые системные службы.

Edit: На System.Math.sin(x), должно быть ясно, что грех (х) есть функция вполне буквально всех смыслах этого слова, и положить его в качестве метода на одноточечного дико безответственным, или, по крайней мере, бит глупый. В комментариях может существовать случай, когда другой класс хотел использовать имя sin() для метода, но поскольку методы и функции находятся в отдельных пространствах имен в любом случае, это действительно не имеет значения.

Answer 3

Я думаю, что цель должна заключаться в том, чтобы проектировать как можно лучше. Я не хочу иметь менталитет поиска «значков» или марок одобрения, поэтому мне не интересно быть как «ОО, насколько это возможно», скорее я стараюсь сделать уловки. Мы предпочитаем такие концепции, как де-связь и единая ответственность, не потому, что это OO, или потому, что мы можем утверждать, что используем шаблон дизайна, а потому, что мы увеличиваем простоту разработки, ремонтопригодность, тестируемость и так далее. Мы также выступаем за простоту, потому что это слишком увеличивает основную способность и способность тестировать - принцип «Ты не нужен» всегда заставляет нас иногда оставлять вещи немного тесно связанными, потому что сейчас нам не нужна гибкость.

Итак, чтобы рассмотреть пример, может быть один синглтон в том смысле, что да, есть только один из них (пул потоков или некоторые из них), но использует ли он код, чтобы он знал, что это одноэлементный ? С небольшим вниманием, использованием фабрик или инъекций мы можем ограничить знание n-gleton-ness.

Answer 4

Нет разбиения ОО с помощью объекта «theApp».