Классы, методы и параметры

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

Когда речь идет о ООП, С++ не стоит вспоминать, лучше уж java.
(Добавление)
Абстрактные классы в php тоже называются абстрактными классами, интерфейс - это другое и несет другие цели

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

C++ rullez

-----
http://www[dot]i2p2[dot]de/index_ru[dot]html

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


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

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

-----
http://www[dot]i2p2[dot]de/index_ru[dot]html

у функции может быть множество аргументов ... 5, 10, 20 - много ... это не удобно, ибо путаемс + порядок надо помнить

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

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

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

Slavenin нам по наследству досталась старенькая админка.
Так вот в ней какраз такой принцип передачи параметров...
Я постоянно путаюсь - какие там параметры какой объект (или ф-ция) получил(а), а какой объект (или ф-ция) какие отдал(а)..
Куча рекурсивных вызовов.
Пока всю цепочку передачи проследишь - свихнешься.

-----
Шта? Репозиторий?

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

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

-----
http://www[dot]i2p2[dot]de/index_ru[dot]html

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

-----
Шта? Репозиторий?

Мы явно друг друга не поняли Ладно, закроем эту тему. если нравится и все круто - используйте, что тут еще скажешь

хорошо, можно и закрыть

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

-----
http://www[dot]i2p2[dot]de/index_ru[dot]html

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