Каковы преимущества объектно-ориентированного программирования? Поможет ли это написать лучший код?

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

Затем, когда вы сделаете это какое-то время, вы начнете обнаруживать, что объекты, созданные для одного приложения, также полезны для других, и вы также начнете улучшать повторное использование кода. Таким образом, в новом приложении часть работы уже выполнена, и в нем используется проверенный временем код: программное обеспечение создается быстрее, с меньшим количеством ошибок.

Люди будут рассказывать вам разные вещи об ООП с разных точек зрения. Но если вы хотите сформировать собственное мнение, а не принимать чье-то мнение, то я предлагаю прочитать «Объектно-ориентированное программное обеспечение» Бертрана Мейера.

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

Прочтите его, вы узнаете, почему, когда и что, и сможете подкрепить свои аргументы.

Да, если вы действительно это понимаете.

Это помогает вам визуализировать, как части более крупной системы могут взаимодействовать друг с другом. Это очень полезно на уровне дизайна.

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

Чтобы эффективно использовать его, вам также необходимо следовать разумным методам объектно-ориентированного проектирования. Всегда инкапсулируйте ВСЕ ваши данные, используя множество небольших классов, но никогда не используйте большие универсальные классы. Пусть класс сделает вашу работу за вас вместо того, чтобы запрашивать данные и выполнять работу вне класса и т. д.

Вероятно, какое-то время это вам не сильно поможет, и, возможно, никогда, если вы всегда делаете небольшие веб-сайты (я не могу сказать этого наверняка, я действительно не занимаюсь php), но со временем и в крупных проектах это может быть бесценным.

Было время, когда я только начинал программировать, я писал ориентированный на пользователя код. Он отлично работал, но его было сложно поддерживать.

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

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

Жизнь с OO хороша ...

В большой системе, такой как Wordpress, Drupal или XOOPS, используются концепции ООП. Вы можете увидеть преимущества их использования там. Повторное использование кода, модульность, ремонтопригодность и расширяемость.

У вас есть возможность изменять части объектов, и это влияет на все приложение; нет поиска, чтобы заменить каждое место, где вы выполнили какую-либо операцию (и, возможно, пропустили ее).

Вы можете повторно использовать объекты повсюду, сэкономив массу времени на копирование и вставку. Исправление ошибки требует исправления одного объекта, а не 16 страниц кода, которые все делают одно и то же.

Когда вы инкапсулируете логику и «скрываете» реализацию, легче использовать объекты, как для вас через 6 месяцев, когда вы забыли, почему вы что-то сделали, так и для парня или девчонки, которые используют ваш код. Например, все, что вы делаете для просмотра сообщений в Wordpress, - это вызов функции. Мне не нужно знать, как это работает, мне нужно только знать, как это назвать.

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

http://www.onlamp.com/pub/a/php/2005/07/28/oo_php.html

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

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

Я бы сказал так: если вы пишете что-то сложное, вы должны кодировать концепции, которыми вы думаете, а не пытаться мыслить концепциями, которые каким-то образом являются родными для языка, который вы используете. Так вы будете делать меньше ошибок. Формализация этих концепций называется дизайном.

Функциональное программирование позволяет вам определять концепции, связанные с глаголами, поскольку каждая функция по сути является глаголом (например, print ()). С другой стороны, объектно-ориентированное программирование позволяет вам также определять концепции, связанные с существительными.

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

1. Пока ваш объект имеет четко определенные входы и выходы, то, как объект делает то, что он делает, вообще не имеет значения - хранение / извлечение данных может происходить из плоского файла в XML, из кэша памяти, из MySQL в Oracle, и только когда-либо должны заботиться об одном единственном объекте.
2. Пока ваш объект имеет четко определенные входы и выходы, вы можете полностью заменить его другим объектом с такими же входами / выходами. Во время выполнения решите, нужны ли вам запросы MySQL, Postgres, memcached или HTTP POST / GET к отрывочному серверу в Индонезии.
3. OO упрощает модульное тестирование. Если вы можете определить, что должен делать конкретный объект (то есть какие результаты он должен дать вам для данного ввода), то вы можете легко написать код для проверки тысяч значений по этому коду и проверки результатов, и вы сразу узнаете, если что-то перерывы.
4. Чем больше кода вы «прячете» в объектах, тем меньше его нужно видеть при использовании этой функции. Однажды я написал приложение для опроса на PHP, которое обрабатывало все аспекты опроса - взаимодействие с базой данных, генерацию опроса, голосование, ранжирование, сортировку и отображение - и мне потребовалась только одна строка кода на моем веб-сайте (Poll::Display()), чтобы реализовать все то, что приложение могло делать это, что значительно упростило обслуживание моей домашней страницы.

Имейте в виду одну вещь - объектно-ориентированный объект в PHP (даже PHP5) не очень хороший объектно-ориентированный объект по сравнению с такими языками, как Python или Ruby. Модель «все является объектом» в Python - это то, что заставило меня программировать объектно-ориентированное программирование для меня, и, как бывший программист PHP (и дважды сертифицированный инженер Zend), я настоятельно рекомендую изучить объектно-ориентированное программирование Python, если вы хотите понять, что такое объектно-ориентированное программирование. это все о. Это, по крайней мере, поможет вам написать лучший PHP-код.

Одна вещь, о которой никто не упомянул, заключается в том, что объектно-ориентированный код облегчает написание читаемого кода:

sherry.changePhoneNumber();
phoneCompany.assignNewPhoneNumberTo(sherry);
sherry.receive(new PhoneNumber().withAreaCode("555").withNumber("194-2677"));

У меня от такой эстетики получается странное удовлетворение.

Я давний процедурный программист PHP, который иногда балуется объектно-ориентированным PHP. Приведенный выше ответ Джоэла - отличное обобщение преимуществ. На мой взгляд, второстепенным преимуществом является то, что он заставляет вас с самого начала лучше определять свои требования. Вы должны понимать отношения между объектами и методами, которые будут воздействовать на них.

Хорошей книгой, которая поможет с переходом, является "Object-Oriented PHP" Питера Лавина .

Чтобы изучить объектно-ориентированный объект на PHP, я бы рекомендовал попробовать использовать хорошо написанный объектно-ориентированный PHP-фреймворк.

Вы можете посмотреть Zend Framework.

Я бы сказал, что есть два основных преимущества:

• Инкапсуляция: код в библиотеках, который не следует вызывать из-за пределов библиотеки, можно скрыть, предотвращая неправильное использование и облегчая изменения внутренней структуры библиотеки при сохранении внешнего интерфейса. В хорошем объектно-ориентированном дизайне изменения вносятся легче после завершения кода.
• Абстракция: вместо массивов массивов вы имеете дело с сотрудниками, отделами и т. д. Это означает, что вы можете сосредоточиться на бизнес-логике и написать меньше строк кода. Меньше строк - меньше ошибок.

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

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

Я тоже PHP, хотя у меня есть сильный опыт работы с ООП, я бы сказал, что лучшая книга по использованию ООП с PHP должна быть Паттерны и практика объектов PHP 5

Огромный выигрыш для меня - это наследование, то есть создание объекта, который ведет себя почти так же, как другой, но с некоторыми отличиями. Вот реальный пример из моего офиса:

Нам нужен был код для обработки файлов TIFF, отправленных нам клиентом, преобразования их в стандартный формат, вставки некоторой информации о файле в базу данных, а затем отправки электронного письма с результатами. Я написал это в наборе классов (на Python, но идея та же). Класс «сборщика» получал электронные письма из почтового ящика POP3 и передавал их классу «контейнер», который знал, как читать вложения из электронного письма. Этот класс передал каждое изображение классу «файлового объекта», который произвел необходимую обработку.

Что ж, однажды у нас появился клиент, который хотел отправить файлы PDF. Я создал подклассы класса «объект файла TIFF» и переписал функцию «нормализации», чтобы вместо этого использовать PDF в качестве входных данных, но оставил все остальные биты кода нетронутыми. Это сработало с первого раза, и я был очень доволен.

Изменение нашего почтового сервера означало, что мне нужно было получать электронные письма через IMAP. Опять же, я создал подкласс «сборщика POP3», чтобы он мог говорить по протоколу IMAP. Проблема решена.

Другой клиент хотел отправить нам компакт-диски по почте, поэтому я разделил класс «контейнер электронной почты» на класс «каталог файловой системы». Вуаля - готово.

В каждом из этих случаев новый код был на 95% похож на старый. Например, в классе «файловый объект TIFF» около 15 методов. Класс «объект файла PDF» определяет ровно одно: метод, преобразующий файлы определенного формата в наш стандарт. Все остальные он получает от своего родительского класса.

Теперь вы определенно можете делать то же самое процедурно, например, написав:

if fileobjecttype == 'TIFF':
    data = <snip 30 lines of code to read and convert a TIFF file>
elif fileobjecttype == 'PDF':
    data = <another 45 lines to read a PDF>
elif fileobjecttype == 'PNG':
    data = <yep, another one>

Самая большая разница в том, что я считаю, что ООП можно сделать намного чище и организованнее. Мой класс PDF выглядит так:

class PDFReader(GenericImageReader):
    def normalize(self):
        data = <45 lines to read a PDF>

вот и все. С первого взгляда можно сказать, что он только в одном отношении отличается от класса, от которого наследуется. Это также заставляет вас - или, по крайней мере, сильно поощряет - создавать чистые интерфейсы между уровнями вашего приложения. В моем примере PDFReader не знает и не заботится о том, был ли его образ из почтового ящика POP3 или с компакт-диска. Сборщик POP3 абсолютно ничего не знает о вложениях, поскольку его задача - просто получать электронные письма и передавать их. На практике это позволило нам делать довольно удивительные вещи с минимальным количеством кода или редизайна.

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

Я бы сказал, что ООП подходит тем, кто мыслит «объектами», где объект состоит из данных, а также функций, которые работают с этими данными.

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

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

• Инкапсуляция
• Классы против экземпляров / объектов
• Наследование и полиморфизм

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

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

Вам следует изучить объектно-ориентированный объект, но не потому, что объектно-ориентированный объект обладает какой-то определенной магией, которая вам нужна.

Более общая форма:

• В: «Следует ли мне изучать (объектно-ориентированное, функциональное, параллельное, логическое, событийное и т. д.) Программирование?»
• A: «Да, изучение новой парадигмы всегда полезно, даже если вы не используете ее напрямую каждый день».

Одна из лучших вещей, которые я сделал с ООП в PHP, - это генератор классов. В любой данной таблице будут задействованы почти одни и те же операции SQL:

• вставлять
• Обновить
• Выбрать
• Удалить
• существует (проверьте, существует ли строка)
• поиск
• список

Теперь мне больше не нужно писать все эти операторы SQL, за исключением особых условий. Я не только сократил кодирование до 1 минуты, выполнив вышеизложенное, я также сэкономил время на отладке кодов.

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

Возможно, вам стоит попробовать то же самое, что и у меня, и у моих клиентов это нравится!