[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Магия и инкапсуляция
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
glock18
Цитата (twin @ 9.10.2013 - 05:56)
Вот человек написал честно. И не дилетант какой-нибудь.


Этот человек не понимает, что есть инкапсуляция. Пардон, почитать было любопытно, но критика человека, видимо, не очень-то понимающего о чем он говорит, в лучшем случае вызывает улыбку
twin
Сказал А, говори Б. Что по твоему есть инкапсуляция? Объясни, а то ты как то странно смотришься с вызванной улыбкой и отсутствием аргументов...

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

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

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

user posted image
glock18
Цитата (twin @ 9.10.2013 - 08:49)
Сказал А, говори Б. Что по твоему есть инкапсуляция? Объясни, а то ты как то странно смотришься с вызванной улыбкой и отсутствием аргументов...

Что значит "по-моему"? Фраза, что сеттеры и геттеры нарушают инкапсуляцию просто противоречит сАмому обычному его определению:
http://ru.wikipedia.org/wiki/%D0%98%D0%BD%...BD%D0%B8%D0%B5)
twin
Я встречал людей, которые вполне серьёзно считают, что обращаться к свойствам классов можно только через сеттеры и геттеры и никак иначе. Причем именно через вот такую конструкцию:

class Example
{

public function __set($name, $value)
{
$this->$name = $value;
}

public function __get($name)
{
return $this->$name;
}
}
Сейчас сколь угодно долго можно рассуждать на тему закономерности такого демарша, но язык дает возможность обратиться даже к приватному свойству извне класса, а значит на лицо нарушение принципа:
Цитата
Инкапсуляция — механизм языка программирования, ограничивающий доступ к составляющим объект компонентам (методам и свойствам), делает их приватными, то есть доступными только внутри объекта. Важно понимать, что к инкапсулированной переменной можно обратиться при написании реализации класса, но при его использовании обращение к ней невозможно.
Я не вижу поводов улыбаться...

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

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

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

user posted image
kaww
да, язык позволяет "нарушать", но выбор остается в итоге за разработчиком, как он реализует эти методы.
Цитата (twin @ 9.10.2013 - 09:58)
Я встречал людей, которые вполне серьёзно считают, что обращаться к свойствам классов можно только через сеттеры и геттеры и никак иначе.

глупость какая, эта магия (и не только __get() и __set()) в терминологии пхп называется перегрузкой, и к тому же работает довольно медленно (хотя, хз , сам не проверял , люди говорят )))
twin
Цитата (kaww @ 9.10.2013 - 10:15)
да, язык позволяет "нарушать", но выбор остается в итоге за разработчиком, как он реализует эти методы.

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

Инкапсуляцию можно реализовать и без ООП, а в ООП это не закон. Так какое отношение она к нему имеет? Вполне закономерный вопрос. Так же можно объявить прерогативой ООП любой другой принцип, допустим расширяемость. (Некоторые особо рьяные индивиды так и пытаются сделать). Объявим, что расширяемость, это постулат ООП, ведь это реально и не важно что возможно везде. И все, другие парадигмы вроде как и не причем.

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

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

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

user posted image
Guest
Желудок человека является сеттером к приватному свойству сердце с параметром валидол. То же инкапсуляция.
Это явный пример не поспоришь.
Смысл в том что строгих правил нет нигде иначе бы всё было таким как Вы и представляете однообразным.
Не принципиально что есть доступ к приватным свойствам, принципиально то что на этап ошибки в сеттере можно вызвать рвоту и не дать запустить яд.
glock18
Цитата (twin @ 9.10.2013 - 09:58)
Я встречал людей, которые вполне серьёзно считают, что обращаться к свойствам классов можно только через сеттеры и геттеры и никак иначе. Причем именно через вот такую конструкцию:

class Example
{

public function __set($name, $value)
{
$this->$name = $value;
}

public function __get($name)
{
return $this->$name;
}
}
Сейчас сколь угодно долго можно рассуждать на тему закономерности такого демарша, но язык дает возможность обратиться даже к приватному свойству извне класса, а значит на лицо нарушение принципа:
Цитата
Инкапсуляция — механизм языка программирования, ограничивающий доступ к составляющим объект компонентам (методам и свойствам), делает их приватными, то есть доступными только внутри объекта. Важно понимать, что к инкапсулированной переменной можно обратиться при написании реализации класса, но при его использовании обращение к ней невозможно.
Я не вижу поводов улыбаться...

__get и __set не дают прямого доступа к членам класса, а это по сути те методы, через которые инкапсуляция производится. Очень жаль, что не видишь поводов для улыбки. Первый раз это улыбку вызывает, а потом уже и не смешно вовсе. Возникает ощущение, что это ты и писал ту статью на хабре.
sergeiss
Что касается функций-сеттеров... У них есть еще одно назначение, которое не все используют, по-моему. И не все про него думают. Которое мне лучше знакомо по С++, нежели по ПХП. В первую очередь потому, что с ООП в ПХП я мало общался ранее smile.gif

Так вот. Это назначение - реализация событий, связанных с установкой определенного параметра. Например, выставляем "флаг" Opened, как вдруг "магически" вызывается метод Open. За счет того, что в функции-сеттере вызываем этот метод. Банально, просто? Может быть.

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

Попытка реализовать подобную фичу на основе линейного программирования приведет все равно к построению структуры, близкой к ООП. Что вполне закономерно smile.gif Вот только зачем изобретать велосипед?

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
Guest
Цитата (sergeiss)
Банально, просто?

угу, это же обычный сеттер, через __set на php, так что какое еще одно никому неизвестное назначение... smile.gif
sergeiss
Цитата (Guest @ 9.10.2013 - 15:08)
так что какое еще одно никому неизвестное назначение...

Вообще-то, я говорил про организацию событий в ООП. Когда один объект извещает другой об изменении своего состояния и о том, как это делается. А ты про что?

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
twin
Цитата (glock18 @ 9.10.2013 - 10:56)
__get и __set не дают прямого доступа к членам класса, а это по сути те методы, через которые инкапсуляция производится.



Вот именно, что в той реализации дают. И именно прямой. Мне совершенно не видно, каким образом это реализовано в классе, у меня же только интерфейс. А он как раз и позволяет:

class Example
{
private $var = 'Я - приватное свойство!';

public function __get($name)
{
return $this->$name;
}
}


$obj = new Example();
// Откуда мне знать, что свойство приватно?
echo $obj->var;

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

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

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

Вот MiksIr сказал, что наследование, это не прикручивание кошке хвоста. И он по своему прав, и я уверен, что может сослаться на какие-то пруфы и авторитетов. Однако парадигма позволяет приделать кошке два хвоста и он не имеет права заявлять, что эхто неверно и нарушение архитектуры. Потому что это нарушает его архитектуру и его представление об ООП.

Ровно как и не уместна твоя улыбка по поводу инкапсуляции.

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

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

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

user posted image
glock18
Цитата (twin @ 9.10.2013 - 11:47)
Цитата (glock18 @ 9.10.2013 - 10:56)
__get и __set не дают прямого доступа к членам класса, а это по сути те методы, через которые инкапсуляция производится.



Вот именно, что в той реализации дают. И именно прямой. Мне совершенно не видно, каким образом это реализовано в классе, у меня же только интерфейс. А он как раз и позволяет:

class Example
{
private $var = 'Я - приватное свойство!';

public function __get($name)
{
return $this->$name;
}
}


$obj = new Example();
// Откуда мне знать, что свойство приватно?
echo $obj->var;

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

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

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

Вот MiksIr сказал, что наследование, это не прикручивание кошке хвоста. И он по своему прав, и я уверен, что может сослаться на какие-то пруфы и авторитетов. Однако парадигма позволяет приделать кошке два хвоста и он не имеет права заявлять, что эхто неверно и нарушение архитектуры. Потому что это нарушает его архитектуру и его представление об ООП.

Ровно как и не уместна твоя улыбка по поводу инкапсуляции.

Ну, что я могу сказать - как всегда приплыли туда же, приходится объяснять ерунду всякую. Что с того, что реализация метода такова? Это метод, и извне класса совершенно неизвестно что и как он делает - известно только, что будет возвращено имя или что там нужно. То что он возвращает значение переменной вовсе не является нарушением инкапсуляции. Нарушением было бы обращение к переменной из вне класса напрямую.

И уже не раз поднималась тема того, как кто там что делает, и правильное ли этот ООП. То что ее многие не понимают просто, и лепят черте что, нарушая все принципы, это не делает сам подход каким-то неправильным. Согласен, что потенциально он способен породить монстра в неумелых руках. Тем не менее, то же касается и любого другого подхода, думаю.

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

Вообще пока ты ассоциацию эту адекватным аналогом из программирования не представишь, ее даже обдумывать смысла нет. У потомков могут быть свои уникальные методы/свойства, и это вполне даже допускает "наличие двух хвостов", если смотреть на вопрос с этой стороны (еще один хвост = еще одно свойство). Ошибкой не является. Будь то хвост просто какой-то скаляр или объект.

Что касается "его" архитектуры и "его" представления об ООП. ООП - это концепция, использовать ее можно правильно и неправильно. Есть best practices, а есть bad practices. Аналогично, другие подходы имеют то же самое, и нельзя четко на любой жизненный случай сразу описать что и как надо.

В общем-то, спор бессмысленный как всегда. Это все равно, что пытаться убедить имама в существовании христа
Быстрый ответ:

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