Я упустил смысл объектно-ориентированного программирования?

Question

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

Пример

Вот как выглядит типичный запрос к БД в моем коде.

$bindings = array(':name'=>$articleName);

Db::query('SELECT id, name, title, image, content FROM ' . CONFIG_MYSQL_TABLE_PREFIX . 'articles WHERE name = :name LIMIT 1', $bindings);

А вот как я изменяю размер / обрезаю / кэширую изображения

$image = Img::thumbnail($imagePath, 200);

$imgHtml = '<img alt="' . $this->getTitle() . '" src="' . '' . $image['src'] . '" width="' . $image['width'] . '" height="' . $image['height'] . '" />';

Оба статических метода используют одноэлементный шаблон. Первый создает один объект PDO, а второй создает один класс ImageResize, который я нашел в коде Google.

Должны ли это быть 2 объекта, если я действительно хотел бы назвать это объектно-ориентированным программированием? т.е.

$db = new Db();

$image = new Image($src, $width, $height);

За каждый раз, когда я их использую? Я читал, что синглтоны тоже плохая идея, если они не используются для записи в файл. Но разве синглтон не подходит для одного соединения с БД, которое открывается и закрывается только тогда, когда оно используется и заканчивается?

У меня вопрос: я все еще застрял в процедурном мышлении, и если да, то, что я делаю, считается плохой практикой? Как я могу погрузиться в правильные ОО-модели мышления?

Обновление

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

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

Answer 1

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

Я говорю это, потому что PHP по умолчанию не существует в состоянии между запросами. Каждый отдельный HTTP-запрос полностью воссоздает среду PHP с нуля (что является достаточно дешевым), то есть между запросами не сохраняется статических данных. Вы можете сказать: «А как насчет данных сессии?» (и, возможно, добавьте «ха!»), но это не постоянные данные в смысле PHP. Они (как правило) хранятся в файловой системе и хранятся в файле cookie, отправляемом клиентом.

Почему я упоминаю эти две вещи?

Потому что «глобальная» область не похожа на глобальную область в C, Java, C ++ или этих других языках, потому что они имеют тенденцию сохраняться между запросами. PHP больше похож на модель программирования CGI 90-х годов (что не случайно, потому что именно там она и возникла).

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

Для меня это далеко не так плохо. На самом деле, я часто нахожу это вполне приемлемым. Иногда это все необходимо (например, в обратном вызове preg_replace_callback, если вы хотите отправить информацию обратно вызывающей стороне или передать состояние обратного вызова без выполнения хаков eval () / create_function ()).

И смысл в том, что PHP не является объектно- ориентированным , заключается в том, что даже в PHP 5 функции OO все еще несколько «привязаны», что означает, что вы вполне можете успешно кодировать и кодировать в PHP без использования их. Это отличается, скажем, от Java, где вы должны создать класс, даже если все, что вы делаете, это пишите в нем несколько статических методов.

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

Объектно-реляционное картирование - Вьетнам компьютерной науки

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

Answer 5

ОО помогает в управлении состоянием в императивной среде.

Чтобы взять два примера, которые вы приводите, во-первых, Db :: query, за этим я предполагаю, что какое-то соединение с базой данных является статическим методом, это означает, что везде в разрабатываемой вами программе это либо:

• Противоборствующие замки
• Имеет проблемы с многопоточностью
• Повторное подключение к базе данных для каждой транзакции

Тогда вы можете подумать - а что если я захочу подключиться к двум разным базам данных?

Имея Db в качестве объекта, вы даете себе больше контроля над тем, как система может развиваться.

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

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

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

Answer 6

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

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