Я уже согласился, что неправильно выразил свою мысль. Я просто хотел сказать, что наследование для меня лично не является ключевым фактором ООП. Хотя бы по причине того, что чаще используется агрегация - именно включение одного объекта в состав другого.
Например, есть класс описывающий таблицу бд. Для класса описывающего бд было бы неуместно наследовать свойства и методы класса описывающего таблицу.
Просто видимо мне встречаются чаще задачи такого рода а не с млекопитающими. И суть наследования я понимаю) Но всеже мне не кажется это ключевым фактором. Это всего лишь способ упростить создание другого объекта. Это хорошо, и даже очень полезно, но суть то не в этом.
А вообще я вэб-программер на php. Так что множественное наследование и прочие радости мне неведомы)
А насчет мира, могу сказать только то, что чаще удобнее без наследования. Например очень редконадо чтобы у стола было свойство "диаметр" унаследованное от ножки. Удобнее чтобы у стола был потомок "ножка" а у нее "диаметр"...
А разве там поддерживались методы?) И кстати зачатки ООП в паскале есть. Просто реализовано через известное место. И когда в 6м классе я ходил в кружок по нему, я не понимал смысла ООП вообще)
Используя объекты, вы ведь не оперируете наследованием? И его используете лишь для упрощения создания нового класса. Ведь так? Это просто позволяет использовать какую-то заготовку для создания нового класса.
Ведь суть стола не в том что он унаследовал свойства ножек и столешницы? Не знаю насколько это удачный пример) Как-бы это лучше выразить... Вам ведь все равно сделан стол из цельного куска древесины (или напрямую из атомов)) т.е. с нуля или сделаны сначала из дерева бруски, из брусков - ножки и т.д. Суть в том что перед вами готовая вещь. С набором свойств. И на них не влияет то что у дерева тоже есть плотность например как и у стола.
Я описал все это упрощенно) Хотя часто использую публичные переменные. И для высоты скорее всего использовал тоже публичную. Видимо пока не встречался с подобными проблемами.
А наследование - это конечно очень полезно, но мне всеже, кажется, что суть не в этом. Я склонен считать, что это скорее инструмент.
Еще приятно когда за высоту например объекта отвечает переменная obj1.height, obj2.height, а не height_of_obj1. Не прада ли?
А вот наследование мне не кжется сутью объектов. Это всеже скорее упрощение их создания и все.
Лично для себя я вижу несколько плюсов ООП:
1. Наглядное представление и структурирование кода.
2. Не возникает проблем с пространством имен. Например, если у вас есть две функции: одна создает файл, другая базу данных, они могут иметь одно и тоже название create($name) и вызыватся соответственно files->create('abc') и db->create('abc'). Опять же если вам надо например проводить операции с двумя серверами баз данных то нужно заводить больше переменных. То есть например Name1, Name2, Table1, Tanle2... А так создается всего два объекта db1 и db2 а все переменные типа name и table определены в них и не возникает путаницы.
3. Код получается более краткий. Например, есть задача добавить одну строку в таблицу и удалить другую (например не с двумя, а со 100). Как это выглядит в процедурном исполнении:
addStringToTable('table_name',$string);
deleteStringFromTable('table_name',$string);
Аналог в ооп не использует везде 'table_name':
db->table='table_name';
db->add_string($string);
db->delete_string($string);
Этот пример просто показывает наглядность кода.
4. Автоматическое подключение файла с классом.
5. Лично мне приятней работать с классами. Их как мне кажется легче использовать повторно. Поэтому, конечно если мне 2+2 нужно посчитать - я делаю функцию, а если нужно с ФС работать то класс. Если это пригодится потом то лучше класс)
Извините)
Я уже согласился, что неправильно выразил свою мысль. Я просто хотел сказать, что наследование для меня лично не является ключевым фактором ООП. Хотя бы по причине того, что чаще используется агрегация - именно включение одного объекта в состав другого.
Например, есть класс описывающий таблицу бд. Для класса описывающего бд было бы неуместно наследовать свойства и методы класса описывающего таблицу.
Просто видимо мне встречаются чаще задачи такого рода а не с млекопитающими. И суть наследования я понимаю) Но всеже мне не кажется это ключевым фактором. Это всего лишь способ упростить создание другого объекта. Это хорошо, и даже очень полезно, но суть то не в этом.
Про область видимости я с самого начала написал)
А вообще я вэб-программер на php. Так что множественное наследование и прочие радости мне неведомы)
А насчет мира, могу сказать только то, что чаще удобнее без наследования. Например очень редконадо чтобы у стола было свойство "диаметр" унаследованное от ножки. Удобнее чтобы у стола был потомок "ножка" а у нее "диаметр"...
Используя объекты, вы ведь не оперируете наследованием? И его используете лишь для упрощения создания нового класса. Ведь так? Это просто позволяет использовать какую-то заготовку для создания нового класса.
Ведь суть стола не в том что он унаследовал свойства ножек и столешницы? Не знаю насколько это удачный пример) Как-бы это лучше выразить... Вам ведь все равно сделан стол из цельного куска древесины (или напрямую из атомов)) т.е. с нуля или сделаны сначала из дерева бруски, из брусков - ножки и т.д. Суть в том что перед вами готовая вещь. С набором свойств. И на них не влияет то что у дерева тоже есть плотность например как и у стола.
Я описал все это упрощенно) Хотя часто использую публичные переменные. И для высоты скорее всего использовал тоже публичную. Видимо пока не встречался с подобными проблемами.
А наследование - это конечно очень полезно, но мне всеже, кажется, что суть не в этом. Я склонен считать, что это скорее инструмент.
db->add_string($string); - а здесь?)
Да банально какая строка короче?)
А вот наследование мне не кжется сутью объектов. Это всеже скорее упрощение их создания и все.
1. Наглядное представление и структурирование кода.
2. Не возникает проблем с пространством имен. Например, если у вас есть две функции: одна создает файл, другая базу данных, они могут иметь одно и тоже название create($name) и вызыватся соответственно files->create('abc') и db->create('abc'). Опять же если вам надо например проводить операции с двумя серверами баз данных то нужно заводить больше переменных. То есть например Name1, Name2, Table1, Tanle2... А так создается всего два объекта db1 и db2 а все переменные типа name и table определены в них и не возникает путаницы.
3. Код получается более краткий. Например, есть задача добавить одну строку в таблицу и удалить другую (например не с двумя, а со 100). Как это выглядит в процедурном исполнении:
addStringToTable('table_name',$string);
deleteStringFromTable('table_name',$string);
Аналог в ооп не использует везде 'table_name':
db->table='table_name';
db->add_string($string);
db->delete_string($string);
Этот пример просто показывает наглядность кода.
4. Автоматическое подключение файла с классом.
5. Лично мне приятней работать с классами. Их как мне кажется легче использовать повторно. Поэтому, конечно если мне 2+2 нужно посчитать - я делаю функцию, а если нужно с ФС работать то класс. Если это пригодится потом то лучше класс)