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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

Люди расскажут вам разные вещи о ООП, с разных точек зрения. Но если вы хотите сформировать собственное мнение, а не брать кого-то другого, тогда я предлагаю прочитать Bertrand Meyer "Объектно-ориентированное программное обеспечение".

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

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

Ответ 4

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

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

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

Ответ 5

Да, если вы действительно получите его.

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

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

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

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

Ответ 6

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

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

Я получаю странное удовлетворение от такой эстетики.

Ответ 7

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

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

Хорошо, однажды мы получили клиента, который хотел отправить PDF файлы. Я подклассифицировал класс "файл файл TIFF" и переписал функцию "normalize", чтобы вместо этого взять PDF файл, но оставил все остальные части кода нетронутыми. Он работал в первый раз, и я был очень доволен.

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

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

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

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

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 абсолютно ничего не знает о приложениях, поскольку его работа - просто получать электронные письма и передавать их вместе. На практике это позволило нам сделать некоторые довольно удивительные вещи с абсолютным минимальным количеством кодирования или редизайна.

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

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

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

Ответ 10

Кажется, каждый реагирует на ваш вопрос буквально, то есть конкретные преимущества/недостатки OO.

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

Более общий вид:

• Q: "Должен ли я изучать (OO, FP, параллельное, логическое, управляемое событиями...) программирование?"
• A: "Да, изучение новой парадигмы всегда полезно, даже если вы не используете ее напрямую каждый день".

Ответ 11

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

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

Ответ 12

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

Хорошая книга, чтобы помочь с переходом - Питер Лавин "Объектно-ориентированный PHP".

Ответ 13

Чтобы подробно рассказать о Джори, немного:

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

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

Обратите внимание, что слово: change. Сокрытие информации касается потенциальных событий, таких как изменение сложных проектных решений в будущем.

Рассмотрим класс с двумя методами: метод a(), который является информацией, скрытой внутри класса, и метод b(), открытый и доступный напрямую другими классами.

Существует определенная вероятность того, что в будущем изменении метода a() потребуются изменения в методах других классов. Также существует определенная вероятность того, что в будущем изменении метода b() потребуются изменения в методах в других классах. Вероятность того, что такие изменения пульсаций произойдут для метода a(), однако, будет обычно ниже, чем для метода b(), просто потому, что метод b() может зависеть от большего количества классов.

Эта уменьшенная вероятность воздействия пульсаций является ключевым преимуществом инкапсуляции.

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

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

Теория инкапсуляции говорит нам, что, учитывая систему из n общественных узлов, MPE этой системы n (n-1). Таким образом, MPE наших 1000 общественных методов составляет 999 000.

Теперь позвольте разбить эту систему на два класса, каждый из которых имеет 500 методов. Поскольку у нас теперь есть классы, мы можем выбрать, чтобы некоторые методы были общедоступными, а некоторые - частными. Это будет иметь место, если каждый метод фактически не зависит от любого другого метода (что маловероятно). Скажем, что 50 методов в каждом классе являются общедоступными. Каким будет MPE системы?

Теория инкапсуляции говорит нам, что это: n ((n/r) -1 + (r-1) p), где r - число классов, а p - количество публичных методов для каждого класса. Это даст нашей двухклассовой системе MPE 499 000. Таким образом, максимальная потенциальная стоимость изменения этой системы двух классов уже значительно ниже, чем у некапсулированной системы.

Скажем, вы разбиваете свою систему на 3 класса, каждая из которых имеет 333 класса (ну, у каждого будет 334), и каждый из них имеет 50 общедоступных методов. Что такое MPE? Используя приведенное выше уравнение, MPE будет составлять примерно 482 000.

Если система разбита на 4 класса по 250 методов, MPE будет 449 000.

Если может показаться, что увеличение количества классов в нашей системе всегда будет уменьшать его MPE, но это не так. Теория инкапсуляции показывает, что количество классов, в которые система должна быть разложена, чтобы минимизировать MPE: r = sqrt (n/p), что для нашей системы фактически 4. Система с 6 классами, например, имела бы MPE из 465 666.

Принцип бремена принимает две формы.

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

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

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

Максимальное потенциальное бремя, которое может наложить модифицированный программный блок, - это воздействие всех программных единиц, которые зависят от него.

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

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

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

Ответ 14

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

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

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

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

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

Ответ 15

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

Ответ 16

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

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

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

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

Ответ 17

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

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

Ответ 18

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

Ответ 19

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

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

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

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

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