Что является лучшим Pro аргумент ООП? [закрытый]

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

Я согласен с объяснением Лассе В. Карлсена.

Одним из возможных решений для вас в этом случае является фактическое удаление явных слепков (найти и заменить их) в вашем коде, если вы действительно ищете «предупреждения», когда существует такой кастинг. Это будет означать, что вы должны будете вручную пройти все слепки, которые произошли (в списке предупреждений) и определить, являются ли они действительными или нет. Так что ваш код будет выглядеть следующим образом:

Int64 x = 123456789000;
Int32 y = x;

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

Абстракция помогает управлять сложностью приложения: раскрывается только та информация, которая необходима.

Существует множество способов достижения этой цели: ООП - не единственная дисциплина, продвигающая эту стратегию.

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

Убийственная фраза: с помощью ООП вы можете моделировать мир «как он есть» * кашляет *.

Повторное использование существующего кода через иерархии.

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

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

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

Я согласен с объяснением Лассе В. Карлсена .

Одним из возможных решений для вас в этом случае является фактическое удаление явных слепков (найти и заменить их) в вашем коде, если вы действительно ищете «предупреждения», когда существует такой кастинг. Это означает, что вам придется вручную пройти через все сделанные слепки (в списке предупреждений) и определить, являются ли они действительными или нет. Так что ваш код будет выглядеть следующим образом:

Int64 x = 123456789000;
Int32 y = x;

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

OOP не имел смысла для меня, пока я не работал над приложением, подключенным к двум разным базам данных. Для обеих баз данных нужна была функция getEmployeyName (). Я решил создать два объекта, по одному для каждой базы данных, чтобы инкапсулировать функции, которые выполнялись против каждой (не было функций, которые выполнялись против обеих одновременно). Не эпитомия ООП, но хорошее начало для меня.

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

Убийственный аргумент - IMHO, это занимает гораздо меньше времени на перепроектирование кода. Вот похожий вопрос, объясняющий почему.

Всегда приводите примеры.

Взгляните на их код, который вы считаете плохим. Перепишите, чтобы было лучше. Объясните, почему так лучше. Ваши коллеги либо согласятся, либо не согласятся.

Никто не использует (и не должен использовать) техники, потому что они хорошие методы, они (должны) использовать их, потому что они дают хорошие результаты. Преимущества очень простого использования классов и объектов обычно довольно легко увидеть, например, когда у вас есть массив объектов со свойствами n вместо массивов n , по одному для каждого поля. вы заботитесь, и так далее.

У меня есть немного странная мысль. Я не знаю, но возможно есть области, где ООП не нужно или даже вредно (очень-очень ИМХО: программирование на javascript).

Возможно, вы и ваша команда работаете в одной из таких областей. В другом случае вы бы провалились много лет назад из-за того, что команды, использующие ООП и все его преимущества (такие как различные фреймворки, UML и так далее), просто делали бы свою работу более эффективно.

Я имею в виду, что если вы все еще хорошо работаете без oop, то, возможно, просто оставьте его.