знаешь в хейди скл когда делаешь хранимку, можно указать - хранимка не содержит скл инструкций, только читает, и вариант модифицирует данные.

вот сдесь ситуация похожая.

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

ЗЫ
ты прав, статический метод и не статический, это по сути просто функция, по адресу в памяти, и хранится одна для класса, а не для каждого обьекта. НО!!! у каждой подпрограммы своя область видимости, и туда, внутрь надо передать указатель на память, где хранится глобальное состояние!
но для статичных методов, это состояние класса (набор значений статичных полей класса), а для не статичных - состояние обьекта. Разница в их вызове. а синтаксически, сразу понятно для чего этот метод - для работы с данными экземпляра, или класса.

летатель космоса,

ну множественное наследование, это уже не наследование ооп.

1)например простой логический эксперемент. допустим мы как джедаи SOLID создали два класса, - каждый отвечает за одну задачу. вопрос, за сколько задач будет отвечать потом обоих?


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

это как если бы мы имели 2 модуля с набором функций(аля две библиотеки) и получали третью путём синтеза нобора функций из обоих.

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

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

SOLID полети к чёртям, а следом и идея ООП(П = проэктирования)

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

Изопропиллетатель космосаХм. Тогда смысл наследования я изначально понял не верно...
почему же сразу "неверно"? есть разные взгляды и подходы

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

Например.

1) Клас А родитель Б
2)А и Б родители С - вопрос, у с должен быть метод А оригинальный, или перекрытый из Б?
3) А Б С родители Е - а когда конструктор вызываеться у Е, сколько раз конструктор А должен вызватся??? один - не спешите... классы Б С в своем конструкторе могут содержать код который меняет поведение конструктора предка А, много раз - тоже не спешите...конструктор может добавлять в множество елементы.
4) Есть А и Б, мы от них создали потомки(каждый потомок обоих) Е и ЕЕ, ЕЕЕ , ЕЕЕЕ
вроде они потомки, тоесть должны быть полиморфны, но ведь если они полиморфны, тогда не понятно почему не сделать было класс АБ - зачем разбиение? а раз всётаки разбиение есть на два отдельных, а математически можно доказать, что либо нет смысла разбиения класса - это разрыв одного целого на двое а потом склеили, либо не все потомки пары А Б будут полиморфны....

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

инными словами, в класическом понимании ооп, и ооп подхода - нет полиморфизма для потомков стопроцентного - нет ооп 100%

Изопропил,

я незнал как назвать вплане - подход, или идея, или методика, или направление, или концепция... :) не силён в лингвистике :)

интерфейсы - тоже зло? (а ведь это всего навсего чистые абстрактные базовые классы)

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

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

можешь программировать без интерфейсов, не потеряешь ничего вплане кода, потеряешь время - вплане большего числа ошибок, когда из 10 классов которые должны уметь делать действие1, действие2, действие3, окажется что парочка из них этого делать не умеет, или область видимости нета.

ЗЫ
кстате вопрос на пхп собеседованиях про чем отличаются абстрактный класс и интерфейс, это глупость. палец и пиписька тоже чем-то похожи, чем то отличаются, но никто ведь не будет спрашивать - что общего и в чом отличие... в подобных случаях, задают вопрос - провести паралель между А и Б, если а и б впринципи разные вещи, но хочеться спросить сразу про обе, и чтоб с нюансами под какимто углом зрения. это как что общего и в чём различие TCP и UDP пакета - вопрос уместен, ибо ито ито строиться поверх ТСP/IP пакета - это как два потомка одного родителя, и сопрос уместен, что у них общее, а где различаються.
и провести паралель между redis и rabbitmq вплане реализаци очереди. бесмысленно спросить что общего и разного у них. у них все разное - но в контексте определённого использования можно провести паралель.