[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Магия и инкапсуляция
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
glock18
Не удержался таки...
user posted image
glock18
Цитата (twin @ 15.10.2013 - 10:07)
я думл что дошло. Нет, не дошло. Продолжаем упираться. Причем упираться так жестко, что не заметил, что упираться больше не во что. Просто стоит на месте, бъет копытом и трясет рогами.


Вообще говоря, такие "нюансы" есть не только в ООП. Постольку поскольку, мы говорим о том, что язык не должен давать средства для нарушения чего-то там, то нужно запретить и exec, system, так же как http-протокол вместе со всеми его методами, включая GET и POST, ведь они же позволяют написать:


exec ($_GET['imanidiot']);

что является форменным безобразием
twin
Цитата (glock18 @ 15.10.2013 - 10:35)
Цитата (twin @ 15.10.2013 - 10:07)
я думл что дошло. Нет, не дошло. Продолжаем упираться. Причем упираться так жестко, что не заметил, что упираться больше не во что. Просто стоит на месте, бъет копытом и трясет рогами.


Вообще говоря, такие "нюансы" есть не только в ООП. Постольку поскольку, мы говорим о том, что язык не должен давать средства для нарушения чего-то там, то нужно запретить и exec, system, так же как http-протокол вместе со всеми его методами, включая GET и POST, ведь они же позволяют написать:


exec ($_GET['imanidiot']);

что является форменным безобразием

Да естественно. Почему я и согласился с положением вещей. Моей ошибкой было то, что я проецировал инкапсуляцию на язык. Я думал это задокументированный принцип, потому что приверженцы ООП его ставят во главу угла своей парадигмы. И считают это обязательным условием разработки.

А оказалось это совершенно не так. Соблюдать этот принцип - воля разработчика. И правильно сделали разрабы PHP, что не уперлись в это рогом. Что во главу угла ставят интересы разработчика, а не костную парадигму.

А дальше уже дела десятые. Каждый подгоняет под свое видение. Вот у MiksIr оно свое, у меня свое. Он считает, что магия не нарушает, я считаю, что нарушает. Со своей колокольни каждый прав.

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

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

А нюансов действительно полно. Было бы крйне скучно заниматься программированием, если бы все было разложено по полочкам, стандартам и парадигмам. Слава Богу это не так.

Иначе такие вот "учителя" свели бы его к тупому копипасту.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
glock18
Цитата (MiksIr @ 15.10.2013 - 10:43)
> Постольку поскольку, мы говорим о том, что язык не должен давать средства для нарушения чего-то там

Да это twin-а переклинило.
Его обычно поведение - когда он во что-то не врубается, или когда он понял, что не тянет разговор по теме - он выдумывает другую и бегает потрясая ей.

Вот как тут - мы говорим конкретно о магии, как механизме языка априори нарушающим инкапсуляцию. А он перекинулся на язык в общем и целом и что-то там "понял". Да и хрен бы с ним =)


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

Спорили уже с ним тут бесчисленное количество раз, ООП держит уверенное первое место среди таких топиков. Любопытно, как все таки он умудряется любой аргумент противника повернуть в свою пользу или пропустить мимо.
twin
Давайте не будем переходить на обсуждение моей личности. Я прекрасно знаю, что MiksIr лишен чуства такта и спокойно к этому отношусь. Меня совершенно не задевают его оценки моей компетентности, я спокойно отношу это к молодости и издержкам воспитания.

Если есть что сказать по существу, пожалуйста.

А дабы небыло кривотолков, резюмирую свою позицию на данный момент.

1. Инкапсуляция, как общее понятие, вещь весьма условная. Это не стандарт, не закон, не панацея. Это просто один из принципов разработки программного обеспечения, используемый в основном как часть ООП парадигмы.

2. Инкапсуляция, в отличие от наследования, не задокументирована в описании языка программирования (что меня и ввело в блуд изначально). В документации описаны области видимости и уровни доступов. Это механизмы, а не принцип.

3. Инкапсуляция должна использовать эти механизмы, но сами мехнизмы к ней не имеют отношения. Это похоже на перегонный куб. Его можно использовать для производства ядреного первача, а можно для дистилированной воды. Называть перегонный куб самогонным аппаратом глупо.

4. Сами принципы инкапсуляции, задекларированные MiksIr, не вызывают никаких кривотолков. Я полностью согласен, что принцип инкапсуляции делает невозможным изменение защищенных свойств. Это и не оспаривалось.

5. Однако википедия дает немного другое определение инкапсуляции. И это важно:
Цитата
Важно понимать, что к инкапсулированной переменной можно обратиться при написании реализации класса, но при его использовании обращение к ней невозможно.
Да, изменить приватное свойство нельзя. Никак. Я и тут ни разу не противоречил. Но разговор шел именно об обращении. Откуда и появилась в теме магия.

Магический метод запускается именно при обращении к свойству. В момент попытки его изменения или получения его значения. Это задекларировано в документации PHP

Цитата
Метод __set() будет выполнен при записи данных в недоступные свойства.
Метод __get() будет выполнен при чтении данных из недоступных свойств.


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

Хорошо, пусть так, с этим я тоже не спорю. Но это не вяжется с самим принципом инкапсуляции, если рассматривать его применительно к самому PHP, как к программе. Ведь вот же, цитируем MiksIr
Цитата
Инкапсуляция со стороны пользователя класса может быть нарушена только тогда, когда пользователь класса воспользовался данными или кодом класса в обход путей, предусмотренных разработчиком класса.
Если заменить слово "класс" на "php.exe", то получим скомпелированную программу, предоставляющую нам задокументированный интерфейс. А значит все рассуждения про виртуальность и макросы входят в противоречие с этим постулатом:
Цитата
Не смешивайте разработчика класса и пользователя. У пользователя есть документированный интерфейс. У него есть интерфейс $obj->some. А как это сделано внутри класса - some публичное или магическое - знать ему не нужно совершенно.
Потому что я, как пользователь языка, совершенно не должен знать, что сделано внутри класса (читай: php.exe). У меня есть задокументированный интерфейс, где черным по белому:
Цитата
Методы перегрузки вызываются при взаимодействии с теми свойствами или методами, которые не были объявлены или не видны в текущей области видимости.
Ни слова про то, что это не те свойства. Ни словечка.

Вот это и было не логично. Это и повергало меня в ступор. С одной стороны, мы имеем обращение к закрытому свойству и реакцию на это обращение. С другой стороны, я должен почему то знать, что это фигня написана в доке, на самом деле мы обращаемся не туда. Откуда знаем? Да рефлексию php.exe сделали. Чай не сложно - сорцы открыты.

Этот когнитивный диссонанс и мучал меня. Не принципы инкапсуляции, а именно то, что они нарушаются. Там или там - не важно.

А на самом деле не нарушается ничего. Потому что нарушать нечего, как оказалось. Разработчики PHP очень поверхностно к этому отнеслись, и правильно сделали. Удобство важнее каких то незадокументированных принципов. И языки дают возможность нарушить инкапсуляцию. С чем MiksIr согласился. Я просто не понимаю, что еще не так то? Вроде бы пришли к общему знаменателю по данному вопросу, чего рогами трясти?

На мой взгляд это прямое нарушение (идет обращение к закрытому свойству с реакцией на это обращение вместо ошибки):

class a
{
private b;

public function __get($var)
{
return 'Всё в порядке, двай дальше, плевать на PHPDOC';
}

}


$o = new a();
echo $o->b;

Потому что я предпочитаю пользовться документацией. В ней написано - попытка чтения закрытого свойства, что должно по принципу инкапсуляции пресекаться на корню:
Цитата
но при его использовании обращение к ней невозможно.

А MiksIr считает, что никакого нарушения нет, так как мы получаем значение не приватного свойства, а внутриклассового. Ну у него свое видение, он оперирует не документацией, а своими знаниями устройства механизмов. Другими словами - пользуется рефлексией.

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

Что касается того, что MiksIr считает только свою точку зрения верной, его право. Мне на это глубоко плевать. Как плевать на его потуги оскорбить меня и потешить свое самолюбие. Меня этим не пронять. Я его точку зрения понял и принял. Она моей не противоречит. А что он там себе возомнил - тьфу и растереть.

Мне истина дороже.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.