-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
_RVK_
Новичок
fixxxer я и говорю. заплатки... 
Поразмысль ширше и представь как раздуются твои _get и _set страшными свичами со временем. я не завидую
-~{}~ 28.03.05 17:15:
Поразмысль ширше и представь как раздуются твои _get и _set страшными свичами со временем. я не завидую -~{}~ 28.03.05 17:15:
Я этого не говорил. Я говорю что от и до спроектировать не получиться. для того и существует итерационный метод разработки ПО. Почитай, не пожалеешь.
Vasya
Guest
Ок. Допустим, мы описываем карту. Там есть точки с координатами, которые могут принимать вещественные значения. Точек этих может быть много, десятки тысяч. Вот класс:
PHP:
class Point {
var $x,$y;
function Point($x,$y) {
$this->x = $x;
$this->y = $y;
}
}Vasya
Guest
Это следствие отсутствия жОсткой типизации в языке. Не стоит вводить её вручную без крайней необходимости.
Вещественные числа. Всё в порядке.
lovchy
nacido para cifrar
Tonn
Ну и что это за пример такой? То, что PHP -- слабо типизированный язык ещё не значит, что надо в геттеры/сеттеры вставлять проверку типов. Тот же код в C++. x и y -- unsigned int. И?
По поводу того, что надо всегда использовать. В теории. Пусть в теории. Где определён этот постулат? Где написано, что public не имеет права на жизнь? И почему он вообще существует в таком случае? Просьба не ссылаться на авторов конкретных подходов к ОО-дизайну. Есть множество концептов и методик -- то, что они использовать public не хотят совсем не значит, что использовать его нельзя вовсе.
И ещё, _RVK_, твой пример великолепно wrap'ится на C# и любом другом языке, который на уровне _языка_ поддерживает свойства. Причём до того, как ты начал хакать свою же структуру и тебе понадобилось таки это wrap'ить вполне возможно использование public-аттрибутов, если нет необходимости в обратном.
_RVK_, если ты делаешь столь категоричное заявление, будь добр -- объясни его ты. А потом мы его, возможно, опровергнем и отаргументируем своё. С другой стороны, мы можем и согласиться.
Ну и что это за пример такой? То, что PHP -- слабо типизированный язык ещё не значит, что надо в геттеры/сеттеры вставлять проверку типов. Тот же код в C++. x и y -- unsigned int. И?
По поводу того, что надо всегда использовать. В теории. Пусть в теории. Где определён этот постулат? Где написано, что public не имеет права на жизнь? И почему он вообще существует в таком случае? Просьба не ссылаться на авторов конкретных подходов к ОО-дизайну. Есть множество концептов и методик -- то, что они использовать public не хотят совсем не значит, что использовать его нельзя вовсе.
Большинство свойств, если уж на то пошло, всегда public. Иначе в них мало смысла. На первом курсе совсем не учат тому, что аттрибуты != свойства?
И ещё, _RVK_, твой пример великолепно wrap'ится на C# и любом другом языке, который на уровне _языка_ поддерживает свойства. Причём до того, как ты начал хакать свою же структуру и тебе понадобилось таки это wrap'ить вполне возможно использование public-аттрибутов, если нет необходимости в обратном.
_RVK_, если ты делаешь столь категоричное заявление, будь добр -- объясни его ты. А потом мы его, возможно, опровергнем и отаргументируем своё. С другой стороны, мы можем и согласиться.
_RVK_
Новичок
А это что? Те же яйца только в профиль....
Это баг! У тебя. Нужно проверять типы...
...Но, подумав, программист решает что контроль типов, не самая насущная проблема в его системе, и решает отложить её на следущую итерацию. Заказчик торопит с первой версией, нужно выпускать релиз. И никаких проблем с добавлением контроля типов в новой версии не будет, потому что у программиста $x,$y - private, и пользовательская оболочка, написанная другой фирмой будет прекрасно работать с новым ядром, так как API не изменилось.
_RVK_
Новичок
Нигде. Я такого не говорил. Что бы не путаться в терминалогии скажу. Я говорю "свойство" подразумевая переменную класса. Я так привык, потому что долго писал на Delphi. Говоря "метод" я имею ввиду функцию класса. С терминами разобрались пойдем дальше...
то же самое и в Delphi(если я тебя правильно понял), о чем я, кстати, упомянул. Здесь речь о пхп, у котрого нет такой полезной фичи (кроме __get, __set __call которые все же немножко другое)
lovchy
nacido para cifrar
> Я так привык, потому что долго писал на Delphi
И что? В OPascal другое ООП? С другими терминами? Свойство есть свойство, аттрибут есть аттрибут. В Delphi всё то же самое. Давай лучше перейдём на использование общепринятых терминов.
> то же самое и в Delphi(если я тебя правильно понял)
Да, в Delphi такая поддержка есть. Правильно понял.
> Здесь речь о пхп, у котрого нет такой полезной фичи
Пусть так, давайте говорить о конкретной реализации в конкретном языке, а не об ООП в целом (хотя вопрос вообще о языке не говорил, если не ошибаюсь и в ответах тоже про PHP ничего не было). В PHP нет механизма свойств. Верно. Значит -- геттеры и сеттеры, как свойства, необходимы. Специфический механизм перегрузки и итеративная природа позволяют сделать удобным и ненавязчивым их использование стандартным способом: через обращение к аттрибутам. Значит ли это, что public не нужен? Не вижу связи.
И что? В OPascal другое ООП? С другими терминами? Свойство есть свойство, аттрибут есть аттрибут. В Delphi всё то же самое. Давай лучше перейдём на использование общепринятых терминов.
> то же самое и в Delphi(если я тебя правильно понял)
Да, в Delphi такая поддержка есть. Правильно понял.
> Здесь речь о пхп, у котрого нет такой полезной фичи
Пусть так, давайте говорить о конкретной реализации в конкретном языке, а не об ООП в целом (хотя вопрос вообще о языке не говорил, если не ошибаюсь и в ответах тоже про PHP ничего не было). В PHP нет механизма свойств. Верно. Значит -- геттеры и сеттеры, как свойства, необходимы. Специфический механизм перегрузки и итеративная природа позволяют сделать удобным и ненавязчивым их использование стандартным способом: через обращение к аттрибутам. Значит ли это, что public не нужен? Не вижу связи.
Так уж и нигде?
Возможно я просто неправильно понял, положим. Разъясни что ты имел в виду и аргументируй свой подход, пожалуйста.
Vasya
Guest
Нет, это не баг. Это именно отсутствие строгой типизации. И данная точка будет иметь валидные координаты (0,0). А вот если вы будете тотально проверять типы в слабо типизированном языке... то это, пожалуй, будет баг
_RVK_
Новичок
Кстати, никого не наводит на мысль для чего в пхп добавлены такие веци как __call, Поддержка разыменования объектов, которые возвращаются методами, уровни доступа, константы класса... Не для того ли что бы упростить правильное программирование?
Рвньше можно было отмазаться что лень писать так:
И было проще:
Но теперь такой отмазки не существует.
-~{}~ 28.03.05 18:59:
"Константы и переменные, составляющие представление класса, известны под разными именами. В Smalltalk их называют переменные экземпляра, в Object Pascal - поля, в C++ - члены класса, а в CLOS - слоты. Мы часто будем использовать эти термины как синонимы" (с) Гради Буч.
Рвньше можно было отмазаться что лень писать так:
PHP:
$obj1 = $obj2->getObj1();
$obj3 = $obj1->getObj3();
....
$objn->exec();
PHP:
$obj2->child['obj1']->child['obj3']->....->child['objn']->exec();-~{}~ 28.03.05 18:59:
как переводится слово property?
"Константы и переменные, составляющие представление класса, известны под разными именами. В Smalltalk их называют переменные экземпляра, в Object Pascal - поля, в C++ - члены класса, а в CLOS - слоты. Мы часто будем использовать эти термины как синонимы" (с) Гради Буч.
Именно потому и не понял. Я говорил лишь о свойствах но не о методах
