Тоже не так однозначно. У нас(в примере) прямоугольник. Он ОБЯЗАН иметь 4 угла. И createPoligon(point1,point2,point3,point4) как-то гарантирует, что при его создании у нас они будут.
Полностью согласен и не вижу предмета спора.
Я ведь писал, что именованные параметры НЕ требуются использовать, когда:
1) Параметров немного, и их предназначение очевидно.
Например: Math.pow (2, 5)
2) Каждый из параметров не является уникальным, и не имеет собственного предназначения.
Например: Math.summ (3, 7, 18, -2, 11, 2.3)
Ваш пример с прямоугольником как раз подпадает под оба этих случая.
Однако, в случае такой вот каши, отсутствие именованных параметров уже некрасиво:
В классической терминологии ООП «свойством» называют интерфейс для доступа к данным объекта.
При использовании которого вызываются методы, но вызываются они «прозрачно» для разработчика.
Например, при вызове array.length--, не только уменьшится значение поля length, но и «прозрачно» вызовется метод, который удалит последний элемент массива.
То, что есть в Javascript, в классической терминологии ООП принято называть «публичным полем».
Однако, в терминологии Javascript эти публичные почему-то поля называются «свойствами». Вот цитата из официальной спецификации Ecma-262:
An Object is an unordered collection of properties.
Да, к сожалению часто бывает так. В не уместившейся здесь заключительной части я написал:
Ну и не стоит забывать, что отсутствие в коде приведенных «уродских приемов» — лишь идеальная ситуация, к которой надо стремиться, но приходится жертвовать в определенных ситуациях (например, в целях производительности).
Я предлагаю вместо obj.getProperty() и obj.setProperty(value); использовать свойства.
Не открытые поля, а именно свойства.
Т.к. при обращении к данным будет вызываться метод, но происходить это будет прозрачно для программиста:
class Person
{
private long _money;
public long money
{
get
{
/*
!!!!!!!!!!!!!
Метод для получения данных
*/
return (_money);
}
set
{
/*
!!!!!!!!!!!!!
Метод для записи данных
*/
_money = value;
}
}
}
/*
Вызов методов происходит прозрачно
*/
Person psnBillGates = new Person ();
lngOldRiches = psnBillGates.money; //Чтение
psnBillGates.money = lngNewRiches; //Запись
psnBillGates.money += 1000000000; //Инкрементация
В сноске, которая, к сожалению, не уместилась из-за ограничений на объем статьи, я написал:
Вообще, надо стараться избегать длинных функций и методов. Одно из правил рефакторинга: «если текст метода не умещается на экране без прокрутки — это уже повод разбить его на несколько более коротких методов».
Однако, это далеко не всегда удается, например при генерации отчетов или при реализации сложных вычисления.
Полностью согласен и не вижу предмета спора.
Я ведь писал, что именованные параметры НЕ требуются использовать, когда:
1) Параметров немного, и их предназначение очевидно.
Например:
Math.pow (2, 5)2) Каждый из параметров не является уникальным, и не имеет собственного предназначения.
Например:
Math.summ (3, 7, 18, -2, 11, 2.3)Ваш пример с прямоугольником как раз подпадает под оба этих случая.
Однако, в случае такой вот каши, отсутствие именованных параметров уже некрасиво:
RotationInterpolator rotator = new RotationInterpolator (
new Alpha (-1, Alpha.DECREASING_ENABLE, 0, 0, 8000, 0, 0, 0, 0, 0),
xformGroup, axis, 0.0f, (float)Math.PI*2.0f);
В классической терминологии ООП «свойством» называют интерфейс для доступа к данным объекта.
При использовании которого вызываются методы, но вызываются они «прозрачно» для разработчика.
Например, при вызове
array.length--, не только уменьшится значение поляlength, но и «прозрачно» вызовется метод, который удалит последний элемент массива.То, что есть в Javascript, в классической терминологии ООП принято называть «публичным полем».
Однако, в терминологии Javascript эти публичные почему-то поля называются «свойствами». Вот цитата из официальной спецификации Ecma-262:
Так что, здесь Вы правы.
См. например в Wikipedia
См. например в Wikipedia
Совершенно согласен.
Все надо применять по назначению. Бездумно использовать локальные функции — еще хуже, чем не использовать их совсем.
Но плохо, если язык не дает нам использовать локальные функции в том случае, когда они действительно требуются.
Т.е. красиво писать:
Person psnBillGates = new Person ();lngOldRiches = psnBillGates.money; //Чтение
psnBillGates.money = lngNewRiches; //Запись
psnBillGates.money += 1000000000; //Инкрементация
А методы доступа к данным вызываются сами, «прозрачно» для разработчика.
См. этот мой комментарий.
Кстати, насчет 1-го пункта («Объявление всех переменных в начале программы») Макконелл еще более радикален чем я. Он пишет
function main (){
//...
function sub1 ()
{
/*
Вот это локальная функция sub1, объявленная в теле функции main
*/
}
function sub2 ()
{
}
}
Т.е. в C#, Delphi, Pethon, Ruby мы можем писать:
Person psnBillGates = new Person ();lngOldRiches = psnBillGates.money; //Чтение
psnBillGates.money = lngNewRiches; //Запись
psnBillGates.money += 1000000000; //Инкрементация
А методы доступа к данным вызываются сами, «прозрачно» для разработчика.
Они используются почти во всех ООП языках: C#, Delphi, Pethon, Ruby…
Поддержки свойств нет только в C++, Java и, к сожалению, в Javascript.
Только в этих языках приходится либо:
использовать открытые поля — что совсем плохо;
либо явно вызывать методы доступа к данным:
obj.getProperty ()иobj.setProperty ().obj.getProperty()иobj.setProperty(value);использовать свойства.Не открытые поля, а именно свойства.
Т.к. при обращении к данным будет вызываться метод, но происходить это будет прозрачно для программиста:
class Person
{
private long _money;
public long money
{
get
{
/*
!!!!!!!!!!!!!
Метод для получения данных
*/
return (_money);
}
set
{
/*
!!!!!!!!!!!!!
Метод для записи данных
*/
_money = value;
}
}
}
/*
Вызов методов происходит прозрачно
*/
Person psnBillGates = new Person ();
lngOldRiches = psnBillGates.money; //Чтение
psnBillGates.money = lngNewRiches; //Запись
psnBillGates.money += 1000000000; //Инкрементация
Да, Вы правы.
В сноске, которая, к сожалению, не уместилась из-за ограничений на объем статьи, я написал:
Я написал в техподдержку, после решения проблемы статья будет выложена в полном виде.
Прошу прощения за доставленные неудобства (возникшие по независящей от меня причине).
А это отмечали в позапрошлом (2007) году.
Т.к. в марте 2006 года Хабра еще не было, то получается, что ни один день числа «Пи» мы не пропустили :-)
Хабрахабр любит тебя
%username%%Math.PI% :)Это не особенность числа «Пи», т.к. относится к любому иррациональному числу.
Даже блог создали по этому случаю: «Число Пи».