Ну вот, еще одно подтверждение, что любая попытка вывести какие то признаки ООП кода сваливаются в банальную фалометрию, чьё кунг-фу сильнее. Вместо того, чтобы рассуждать по теме, нужно обязательно прикопаться к реализации вплоть до названий методов.
Причем я же сам обозначил, что код весьма условен и в нем важен принцип, а не реализация.
А как ты интересно классы сюда приплетешь? По классу на каждый метод?)))
Сеттеры причем то появились, их вообще не обсуждали и 100% найдутся люди, которые причисляют себя к тру ООПэшникам, но будут стоять за них горой. Не я, не надейся. По мне так сеттер, это просто один из инструментов. Где то неуместный, где то - что доктор прописал. Хотя раньше я тоже был ярым противником.
Но это все фигня и демагогия, как любит говорить
Ron. Попытка уйти от настоящих проблем обсуждаемой темы.
| Цитата (chee @ 8.07.2019 - 23:13) |
| Представлять пример кода и описать ситуацию, который любой(квалифицированный) программист решит через декоратор (смысл которого концентрированное делегирование). |
Так об чем и речь была, что любой, как ты говоришь, квалифицированный программист (кто ему подтверждал квалификацию интересно, если вы сами не можете придти к общему знаменателю
), или по сути тру-ООПэшник со своими тараканами, предпочтет
композицию вместо наследования. А значит наследование в современном ООП. это не столп и кит, а просто инструмент, который не может быть основополагающей фишкой, так же как разделение областей видимости к примеру, которыми так в свое время кичились ООПэшики.
И именно по тем причинам, что я
описал процитировал выше. На вот еще цитату:
| Цитата |
Композиция объектов влияет на дизайн системы и еще в одном аспекте. Отдавая предпочтение композиции объектов, а не наследованию классов, вы инкапсулируете каждый класс и даете ему возможность выполнять только свою задачу.
Классы и их иерархии остаются небольшими, и вероятность их разрастания до неуправляемых размеров невелика. С другой стороны, дизайн, основанный на композиции, будет содержать больше объектов (хотя число классов, возможно, уменьшится), и поведение системы начнет зависеть от их взаимодействия, тогда как при другом подходе оно было бы определено в одном классе.
Это подводит нас ко второму правилу объектно-ориентированного проектирования: предпочитайте композицию наследованию класса. |
Чтобы не было кривотолков, делегирование - один из частных случаев композиции.
Так что пример ты сам привел, мне и трудиться не нужно. Я уж было чуть не повелся и не начал писать портянку делегирования с перечнем методов и прочими изысками.
А все остальное у тебя "бла-бла-бла, моя писька толше":
| Цитата (chee @ 8.07.2019 - 23:13) |
| Резюмирую, по факту твое неприятие ООП это проблема в самом тебе. У тебя объекты это не данные и методы для работы с этими данными, а контейнеры с функциями и с ссылками на источники данных. |
Объекты для меня, это чисто данные. Без методов. Методы, это прерогатива классов, с которыми объекты ассоциированы.
Вот примерно так.
А что касается контейнеров с функциями, то это банальный stateless, работа с объектами без сохранения состояния, или другими словами службы и сервисы.
Очередной совет, почитай Эванса, он там тебе подробно расскажет, что это такое и почему не все можно вписать в концепцию обычных объектов.
Так что теперь моя очередь резюмировать. Если ты позволяешь себе такие рассуждения, которые идут вразрез с
вашими же общепринятыми практиками, значит ты учишься методом тыка и хватания верхушек, а не изучения предмета и его анализа. Потому что чтобы анализировать предмет, нужно сначала узнать, что о нем думают признанные в вашей же сфере мастера. Другими словами почитать книжки.
Valick, я же прав?
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.