> данный момент больше вытекает в понятие абстракции
верю, но холивар идет по теме «должно ли все наружу»
> вполне могут открыть исходники
конечно, но когда человек правит код класса, с инстанциями которого он должен только работать — он (по условию задачи) осознает, что делает что-то не то
> откомпилированный сервис, и к исходникам доступа нет
да будет, сколько приложений взломанных, а они все откомпилены
> осознавать, что это дополнение, сахар, но не суть ООП
верю, но, имхо, лучше делать вещи удобные, чем не стабильные
> создавать несколько методов непосредственно в объекте, чем создавать свойства там же и методы один раз в прототипе
не в том дело, машину удобнее просто запустить с помощью go, чем где-то снаружи проверять каждый раз, а не едет ли она сейчас и устанавливать извне же параметры, соотв. началу движения
> this.x, а с другой типа спрятанный this.getX()
в примере есть maxSpeed, dSpeed, stopIterate и прочие параметры, у которых нету и не должно быть ни сеттеров, ни геттеров.
function Car() {
var dublicate = this; // this в таймере совсем не тот
var speed = 0; // и у пешехода есть только одна возможность изменить это свойство :)
var maxSpeed = 120; // это нужно снаружи?
var dSpeed = 10; // это нужно снаружи?
var going = false; // может быть полезно снаружи
var stoping = null; // может быть полезно снаружи
// var mileage = 0; // реализовывать не буду, но менять снаружи это явно не положено
this.go = function() {
// газ
if (stoping) onStop();
if (going) return;
going = true;
speed = 10;
};
this.stop = function() {
// тормозим
if (!going || stoping) return;
stoping = window.setInterval(stopIterate, 10);
};
this.faster = function() {
// быстрее
if (stoping) return;
if (speed + dSpeed <= maxSpeed) speed += 10;
};
this.slower = function() {
// сбавляем скорость
if (stoping) return;
if (speed - dSpeed > 0) {
speed -= 10;
} else {
speed = 0;
going = false;
}
};
function stopIterate() {
// зачем светофору этот метод?
dublicate.slower();
if (!going) onStop();
}
function onStop() {
// встали
window.clearInterval(stoping);
stoping = false;
going = false;
}
}
1. потому что я воспринял этот пассаж как набор прикольных слов. если Вас не затруднит по-русски пересказать как все это расшифровывается, плиз, не поленитесь, может и пойму чего
3. стоять на логике, на моделе поведения.
4. до какой степени? когда страница весит 861 KB uncompressed ну какой смысл стараться ужать 10, да и 50, кило скрипта? если скрипт инициализируется 100ms, пусть даже 500ms — что в этом страшного? эта страница у меня и дома, и на работе грузилась в разы дольше.
конечно, я не призываю плевать на пользователей. их надо любять, но себя тоже надо любить. а еще любить надо людей, которым наши творения надо будет переделывать — это тоже наши пользователи, просто из другой категории.
DOM есть у браузера, это результат парсинга text/html, хотя этим можно и принебречь
DOM => JS, вроде как, оно и есть?
но у меня мысль другая: JS, будь он в 10 раз быстрее и выйди к нему хоть десятая спека, был бы экзотическим языком, если бы на нем нельзя было делать выпадающие менюшки
4+5 экономия и выглаженность это всегда хорошо, но фанатеть, имхо, даже по ним не стоит. лучше по принципу Парето, 20/80, ибо 20% прироста скорости за счет увеличения срока в 4 раза оправданы в редких случаях (таже анимация).
1. не хочу комментировать
1.1. очень даже интересный, а особенно его грамотное применение, на эту тему очень много очень занимательных книжек есть :)
1.2. разбиение функционала на простые, понятные операции. откуда число 7 я не помню, может и 7, но точно не 77.
2. только понимают его очень мало людей. судя по x+getX+setX очень-очень мало людей :(
3. посмотрите, сколько людей строят всю «архитектуру» JS с помощью $() в jQuery, это понятно 10%
3.1. яспень, если надо в поле слово «поиск» убирать при фокусе, ООП не сдалось
3.2. логика веб-приложения не обязана находиться целиком на сервере
4. диктует чем? видео-баннерами, мегабитным анлимом, монстрами вроде extJS?
5. хотя высказывание и несколько резкое, но я выше уже писал, habrahabr.ru/blogs/javascript/65680/#comment_1842426
суть не в том, что значение x можно получить только через getX, а в том, что его не надо получать, и вообще не надо знать, что оно есть. есть методы do1 и do2, а что внутри — без разницы (пока работает).
> «должно быть так и не иначе»
чтобы утверждать «должно быть так и не иначе» надо поминать, что есть «так», и что есть «иначе». и я не утверждаю, что я досконально знаю и то, и другое досконально — я тупо пытаюсь по-хорошему разобраться в ООП, можете смеяться. ООП предоставляет больше возможностей, чем прототипирование, и, используя JS, я стараюсь (без фанатизма) следовать принципам ООП, а не «скриптования». если бы это идеология языка такого не допускала, язык бы и не предоставлял таких возможностей. и, раз уж стараюсь придерживаться ООП, я не отвергаю ООП в пользу JS-специфики. в отличие от 90% скриптеров, которые про ООП только говорят, и говорят только то, что они его знают.
> да я могу ответить компетентно
расскажите мне, пожалуйста, по какой причине все, нужные и не нужные, методы всех объектов должны «торчать наружу»?
Вы написали статью, в которой «предложили объективно рассмотреть достоинства и недостатки такого подхода». положительных моментов инкапсуляции Вы нашли только два: один обещаю в этой статье более не приводить, и то, что она «ограничивает доступ к свойствам», который потом оказался не нужным из-за того, что Вы не смогли решить «проблемы».
видимо, это все объективные достоинства. однако Вы потратили много времени, показывая недостатки заслуженной концепции:
— Это не так сложно (договориться), как может показаться. — я спросил: «а зачем договариваться, когда можно нормально написать?» — Вы проигнорировали;
— деньги в банкомате закончились — имхо, epic fail, и Вы снова проигнорировали следующий коммент, зато назвали меня троллем;
— Если не хотите, чтобы какой-то объект вызывал validateWith другого объекта — так не вызывайте — неужели программисты, поколение за поколением, ошибаются, а Вы срываете маски? тот же Ваш PHP не всегда знал, что такое объекты, однако, они в нем почему-то появились, а потом зачем-то появилось и ключевое слово private.
и тут же бездоказательные «я не против». толку с того, что они черным по белому? Вы занимаетесь именно тем, что противопоставляете себя злым дядям.
«опять же, должна не в плане, что должна и точка. должна в плане удобнее» — в комменте рядом написал.
> который будет представлять собой скорость, с двумя методами getKMH и getMPH, и буду прав
а разве нет?
верю, но холивар идет по теме «должно ли все наружу»
> вполне могут открыть исходники
конечно, но когда человек правит код класса, с инстанциями которого он должен только работать — он (по условию задачи) осознает, что делает что-то не то
> откомпилированный сервис, и к исходникам доступа нет
да будет, сколько приложений взломанных, а они все откомпилены
> осознавать, что это дополнение, сахар, но не суть ООП
верю, но, имхо, лучше делать вещи удобные, чем не стабильные
ну, есть некоторые проблемы
> вряд ли удобно в отношении организации под-над-структур (наследование)
да, есть проблемы
не в том дело, машину удобнее просто запустить с помощью go, чем где-то снаружи проверять каждый раз, а не едет ли она сейчас и устанавливать извне же параметры, соотв. началу движения
> this.x, а с другой типа спрятанный this.getX()
в примере есть maxSpeed, dSpeed, stopIterate и прочие параметры, у которых нету и не должно быть ни сеттеров, ни геттеров.
function Car() { var dublicate = this; // this в таймере совсем не тот var speed = 0; // и у пешехода есть только одна возможность изменить это свойство :) var maxSpeed = 120; // это нужно снаружи? var dSpeed = 10; // это нужно снаружи? var going = false; // может быть полезно снаружи var stoping = null; // может быть полезно снаружи // var mileage = 0; // реализовывать не буду, но менять снаружи это явно не положено this.go = function() { // газ if (stoping) onStop(); if (going) return; going = true; speed = 10; }; this.stop = function() { // тормозим if (!going || stoping) return; stoping = window.setInterval(stopIterate, 10); }; this.faster = function() { // быстрее if (stoping) return; if (speed + dSpeed <= maxSpeed) speed += 10; }; this.slower = function() { // сбавляем скорость if (stoping) return; if (speed - dSpeed > 0) { speed -= 10; } else { speed = 0; going = false; } }; function stopIterate() { // зачем светофору этот метод? dublicate.slower(); if (!going) onStop(); } function onStop() { // встали window.clearInterval(stoping); stoping = false; going = false; } }3. стоять на логике, на моделе поведения.
4. до какой степени? когда страница весит 861 KB uncompressed ну какой смысл стараться ужать 10, да и 50, кило скрипта? если скрипт инициализируется 100ms, пусть даже 500ms — что в этом страшного? эта страница у меня и дома, и на работе грузилась в разы дольше.
конечно, я не призываю плевать на пользователей. их надо любять, но себя тоже надо любить. а еще любить надо людей, которым наши творения надо будет переделывать — это тоже наши пользователи, просто из другой категории.
DOM => JS, вроде как, оно и есть?
но у меня мысль другая: JS, будь он в 10 раз быстрее и выйди к нему хоть десятая спека, был бы экзотическим языком, если бы на нем нельзя было делать выпадающие менюшки
взаимосвязь между объектами должна строиться не на том, что у obj есть x, а основываясь на целях существования obj.
1. не хочу комментировать
1.1. очень даже интересный, а особенно его грамотное применение, на эту тему очень много очень занимательных книжек есть :)
1.2. разбиение функционала на простые, понятные операции. откуда число 7 я не помню, может и 7, но точно не 77.
2. только понимают его очень мало людей. судя по x+getX+setX очень-очень мало людей :(
3. посмотрите, сколько людей строят всю «архитектуру» JS с помощью $() в jQuery, это понятно 10%
3.1. яспень, если надо в поле слово «поиск» убирать при фокусе, ООП не сдалось
3.2. логика веб-приложения не обязана находиться целиком на сервере
4. диктует чем? видео-баннерами, мегабитным анлимом, монстрами вроде extJS?
5. хотя высказывание и несколько резкое, но я выше уже писал, habrahabr.ru/blogs/javascript/65680/#comment_1842426
да, все надо применять с умом
замечательно
> «должно быть так и не иначе»
чтобы утверждать «должно быть так и не иначе» надо поминать, что есть «так», и что есть «иначе». и я не утверждаю, что я досконально знаю и то, и другое досконально — я тупо пытаюсь по-хорошему разобраться в ООП, можете смеяться. ООП предоставляет больше возможностей, чем прототипирование, и, используя JS, я стараюсь (без фанатизма) следовать принципам ООП, а не «скриптования». если бы это идеология языка такого не допускала, язык бы и не предоставлял таких возможностей. и, раз уж стараюсь придерживаться ООП, я не отвергаю ООП в пользу JS-специфики. в отличие от 90% скриптеров, которые про ООП только говорят, и говорят только то, что они его знают.
> да я могу ответить компетентно
расскажите мне, пожалуйста, по какой причине все, нужные и не нужные, методы всех объектов должны «торчать наружу»?
видимо, это все объективные достоинства. однако Вы потратили много времени, показывая недостатки заслуженной концепции:
— Это не так сложно (договориться), как может показаться. — я спросил: «а зачем договариваться, когда можно нормально написать?» — Вы проигнорировали;
— деньги в банкомате закончились — имхо, epic fail, и Вы снова проигнорировали следующий коммент, зато назвали меня троллем;
— Если не хотите, чтобы какой-то объект вызывал validateWith другого объекта — так не вызывайте — неужели программисты, поколение за поколением, ошибаются, а Вы срываете маски? тот же Ваш PHP не всегда знал, что такое объекты, однако, они в нем почему-то появились, а потом зачем-то появилось и ключевое слово private.
и тут же бездоказательные «я не против». толку с того, что они черным по белому? Вы занимаетесь именно тем, что противопоставляете себя злым дядям.