Для чего нужны классы?
1,00
р.
Не понимаю, для чего нужны классы в PHP?
Допустим, есть function.php, в нём много много функций, выполняющих разные действия, функции частично содержат общие переменные и в некоторых случаях части их кодов совпадают.
Если все эти функции превратить в методы и засунуть в один класс, что изменится в лучшую сторону или по другому - для чего нужны классы?
Ответ
(Резюме: классы нужны, чтобы абстрагироваться от сложности задания.)
Вы серьёзно не знаете, для чего нужны классы? Хм. Ну ладно.
Давайте подумаем: что такое программирование? Программирование -- это производство. Я имею в виду не учебные задания в стиле «введите строку и посчитайте в ней количество пробелов». Я имею в виду реально большие проекты. В них не так уж часто встречаются особо умные куски кода, зато функциональности много, она не обязательно логично устроена (особенно часто такое бывает, если вы конструируете интерфейс пользователя), и, что немаловажно, проект поддерживают не гении, вроде всех на этом сайте, а обычные программисты.
Это значит, что большая часть времени жизни кода уйдёт на его поддержку, а не начальную разработку.
Гении (и начинающие программисты тоже, как ни странно) не любят доводить что-то до совершенства. Они напишут прототип в виде одной офигенно сложной функции, и voila! — задание выполнено. В функции есть тысяча хитростей и зависимостей, которые гению просто держать в голове. Но завтра гений заболеет, уйдёт в запой или вообще уволится — и внезапно код должны поддерживать самые обыкновенные обыкновенные программисты, из мяса и костей.
А обыкновенному программисту нелегко работать с длинной сложной функцией, при одном взгляде на неё начинает болеть голова. Он не может держать в голове сразу миллионы понятий и зависимостей! И тут внезапно на помощь приходят классы. Классы позволяют уменьшить сложность. Когда программист разрабатывает класс, он, конечно, думает обо всём классе и держит в голове сразу весь класс. Но когда он разрабатывает другие классы, он думает больше не в терминах «я вызову функцию X, и она установит переменную Y», а в терминах классов: «я беру возраст пользователя», «я рисую эту картинку». Теперь голова болит гораздо меньше: вместо того, чтобы думать о всех функциях в проекте одновременно, программист думает только о немногих публичных функциях немногих публичных интерфейсов. Таким образом, в его коде меньше зависимостей: он не должен думать (вернее должен не думать!) о конкретной реализации возраста пользователя, или там отрисовки картинки, он может про это забыть. Его код становится проще, этот код легче понимать, тестировать и поддерживать.
Кроме того, он больше не должен думать что-то типа «я добавляю пользователя в список модераторов, для этого мне надо обновить вот этот массив, вот ту хэш-таблицу, поставить флаг для обновления базы данных и не забыть ещё увеличить счётчик версий». Он просто говорит: «таблица модераторов, добавь-ка в себя вот этого пользователя!» То есть теперь можно думать не в терминах внутренних структур данных, а в терминах семантики: программист пишет прямо то, что он хочет выразить. Несмотря на то, что в языке не было раньше конструкций для выражения его мыслей. Мы видим, что программист на самом деле расширяет язык под свою предметную область, и может легко и адекватно выражать своё намерение. Такой код не только легче писать, но и легче поддерживать.
При этом эффективность кода может падать по сравнению кодом, учитывающим особенности реализации других классов, но мы сознательно идём на эту жертву: наша цель — чтобы код стал проще, яснее, чтобы он говорил сам за себя!
Обратите внимание, что этот подход — развитие процедурного подхода: там мы складывали код в процедуры, чтобы абстрагироваться от кода одной процедуры во время разработки другой (и код, который опирается на конкретику реализации, обычно считается плохим, потому что он не уменьшает количество абстракций, которые нужно держать в голове). Так и при объектном-ориентированном подходе уменьшается, в свою очередь, количество функций, которые надо держать в голове.
Кроме того, ООП даёт другие плюшки, в виде наследования и полиморфизма, которые, однако, кажутся мне концептуально менее важными. Хотя и очень приятными в использовании.
Таким образом, для маленького проекта, для которого вы можете держать все функции в голове, можно отказаться от использования классов. Но для достаточного большого, серьёзного проекта без помощи классов для уменьшения сложности не обойтись.
PS: Для разработчиков на C: в самом деле, можно уменьшать сложность и по-другому, например, не выносить нерелевантный код в заголовочные файлы. Классы в языках, которые их поддерживают, предоставляют явное средство управления сложностью, в отличие от неявного, осуществляемого в C.
Допустим, есть function.php, в нём много много функций, выполняющих разные действия, функции частично содержат общие переменные и в некоторых случаях части их кодов совпадают.
Если все эти функции превратить в методы и засунуть в один класс, что изменится в лучшую сторону или по другому - для чего нужны классы?
Ответ
(Резюме: классы нужны, чтобы абстрагироваться от сложности задания.)
Вы серьёзно не знаете, для чего нужны классы? Хм. Ну ладно.
Давайте подумаем: что такое программирование? Программирование -- это производство. Я имею в виду не учебные задания в стиле «введите строку и посчитайте в ней количество пробелов». Я имею в виду реально большие проекты. В них не так уж часто встречаются особо умные куски кода, зато функциональности много, она не обязательно логично устроена (особенно часто такое бывает, если вы конструируете интерфейс пользователя), и, что немаловажно, проект поддерживают не гении, вроде всех на этом сайте, а обычные программисты.
Это значит, что большая часть времени жизни кода уйдёт на его поддержку, а не начальную разработку.
Гении (и начинающие программисты тоже, как ни странно) не любят доводить что-то до совершенства. Они напишут прототип в виде одной офигенно сложной функции, и voila! — задание выполнено. В функции есть тысяча хитростей и зависимостей, которые гению просто держать в голове. Но завтра гений заболеет, уйдёт в запой или вообще уволится — и внезапно код должны поддерживать самые обыкновенные обыкновенные программисты, из мяса и костей.
А обыкновенному программисту нелегко работать с длинной сложной функцией, при одном взгляде на неё начинает болеть голова. Он не может держать в голове сразу миллионы понятий и зависимостей! И тут внезапно на помощь приходят классы. Классы позволяют уменьшить сложность. Когда программист разрабатывает класс, он, конечно, думает обо всём классе и держит в голове сразу весь класс. Но когда он разрабатывает другие классы, он думает больше не в терминах «я вызову функцию X, и она установит переменную Y», а в терминах классов: «я беру возраст пользователя», «я рисую эту картинку». Теперь голова болит гораздо меньше: вместо того, чтобы думать о всех функциях в проекте одновременно, программист думает только о немногих публичных функциях немногих публичных интерфейсов. Таким образом, в его коде меньше зависимостей: он не должен думать (вернее должен не думать!) о конкретной реализации возраста пользователя, или там отрисовки картинки, он может про это забыть. Его код становится проще, этот код легче понимать, тестировать и поддерживать.
Кроме того, он больше не должен думать что-то типа «я добавляю пользователя в список модераторов, для этого мне надо обновить вот этот массив, вот ту хэш-таблицу, поставить флаг для обновления базы данных и не забыть ещё увеличить счётчик версий». Он просто говорит: «таблица модераторов, добавь-ка в себя вот этого пользователя!» То есть теперь можно думать не в терминах внутренних структур данных, а в терминах семантики: программист пишет прямо то, что он хочет выразить. Несмотря на то, что в языке не было раньше конструкций для выражения его мыслей. Мы видим, что программист на самом деле расширяет язык под свою предметную область, и может легко и адекватно выражать своё намерение. Такой код не только легче писать, но и легче поддерживать.
При этом эффективность кода может падать по сравнению кодом, учитывающим особенности реализации других классов, но мы сознательно идём на эту жертву: наша цель — чтобы код стал проще, яснее, чтобы он говорил сам за себя!
Обратите внимание, что этот подход — развитие процедурного подхода: там мы складывали код в процедуры, чтобы абстрагироваться от кода одной процедуры во время разработки другой (и код, который опирается на конкретику реализации, обычно считается плохим, потому что он не уменьшает количество абстракций, которые нужно держать в голове). Так и при объектном-ориентированном подходе уменьшается, в свою очередь, количество функций, которые надо держать в голове.
Кроме того, ООП даёт другие плюшки, в виде наследования и полиморфизма, которые, однако, кажутся мне концептуально менее важными. Хотя и очень приятными в использовании.
Таким образом, для маленького проекта, для которого вы можете держать все функции в голове, можно отказаться от использования классов. Но для достаточного большого, серьёзного проекта без помощи классов для уменьшения сложности не обойтись.
PS: Для разработчиков на C: в самом деле, можно уменьшать сложность и по-другому, например, не выносить нерелевантный код в заголовочные файлы. Классы в языках, которые их поддерживают, предоставляют явное средство управления сложностью, в отличие от неявного, осуществляемого в C.
