Объектный код
 

Как научится правильно писать гибкий объектно ориентированный код?
Обычно я делаю как-то так

function construct(l) {
 var obj = {
  a : 5,
  b : function() {
   
  },
  c : l
 }
 return obj;
}

Или даже так

function construct(l) {
 var obj = {}
 obj.a = 5;
 obj.b = function() {
 
 }
 obj.l = l;
 return obj;
}

Но хочется чего то более сложного.
Как создают объекты профессионалы?

Профессионалы не гонятся за понтами и сложностью, а пишут код, который решает поставленные задачи.

я не знаю как профессианалы пишут но продолжаю так

function const2(){
var obj=new construct(55);
obj.c=6;
obj.d=function(){this.f=this.a+this.c}
return obj;
};
var f=new const2();alert('f='+f);f.d();alert(f.f);

Как их сделаешь короткими если они по алгоритму длинные

в твоем же коде Hash.set разве не сеттер?
я бы добавил ещё, за сокращением количества ненужных телодвижений в скриптах.
Декомпозиция. разбиваешь задачу на подзадачи и решаешь. так может получиться фасад.

Ээээ, ммм, а зачем верхняя часть.
Вы написали фи-ю, а потом вспомнили,что всё это делается одной строкой, но первый вариант удалить забыли. Да?

Спасибо-посмотрю-

на меня огромное впечатление произвела книга Крокфорда. может, и вам понравится.

она уже едет ко мне, я вчера заказал :) Вместе с доставкой под дверь 100грн.

как много букв тратится на Toggle.prototype

Maxmaxmахimus,
А не лучше ли прототип объектом присвоить.

/**
 * Переключатель.
 * Имеет 2 состояния.
 * Если включен, то возвращает хранимое значение,
 * если выключен, то возвращает undefined.
 * По умолчанию включен
 *
 * @param value - значение
 * @constructor
 */
function Toggle ( value ) {
    this._state = true;
    this._value = value;
}
Toggle.prototype = {
 on : function() {
    this._state = true;
 },
 off : function () {
    this._state = false;
 },
 toggle : function () {
    this._state = !this._state;
 },
 state : function () {
    return this._state;
 },
 value : function ( value ) {
 
    if (  arguments.length < 0 ) {
        this._value = value;
    }
    else if ( this._state ) {
        return this._value;
    }
 }
}

Я пишу код понятный для меня. Как мне удобно. Какой смысл писать весь код в сточку, а потом когда он работать не будет, копаться в соей писанине в поиске ошибок?

поясни и первое, и второе.

что тут не так ?

function a(b){ 
  this.b = b; this.scream(); 
}

a.prototype = { 
  scream: function(){
    alert(this.b + ", World!")
  } 
};

new a("Hello");

код из твоего примера:

Hash.prototype.keys = function () {
	var elements = this._elements,
		keys = [];

	for ( var key in elements ) if ( elements.hasOwnProperty( key ) ) {
		keys.push( key );
	}

	return /*массив ключей*/;
};

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

А что быстрее, хранить имена всех свойств в массиве и когда нужно делать перебор циклом for, или юзать for-in

Hash.prototype.keys возвращает массив. не нужно делать перебор.

for по массиву быстрее, чем for-in по объекту.

если ты на серъёзе собираешься оставить эту строчку, то IE7, IE8, Opera будут срать кирпичами при каждом вызове keys.


Ы. тут ситуация такая же, как и у свойства length у массивов в старых браузерах (напомню, он не кешировался)

return cached_keys;
// vs
for(i in elements) keys.push(i);
return keys;

ты так думаешь? "просто вернуть" и "перебрать".
у тебя все операции с элементами сделаны через высокоуровневые методы. при добавлении элемента просто увеличиваешь цифру количества элементов на один.
при добавлении добавляешь в кэш. при удалении - удаляешь. это все операции с изменением кеша.

PS. а давай протестируем Hash на больших данных? что голословить...

Ещё такой вопрос: что считаете правильнее, использовать замыкания или _доверится _соглашению _программистов?

тут надо всё взвесить. лучшего варианта нет.

• устойчивость кода к воздействиям извне
  замыкания

  если код не дает возможности изменить её, то её не изменить, т.е. устойчивость высокая.

  соглашение

  можно изменить, как и любое свойство (конечно, если не запретить изменение\конфигурировани� � свойства в дескрипторе)

• простота использования
  замыкания

  
  новичкам бывает трудно понять замыкания. после осознавания сути они становятся обычным приёмом
  

  соглашение

  
  легче, чем замыкание. тут присутствует сходство с обычным ООП.
  

• сжимаемость кода
  замыкания

  отлично сжимаются, как обычные локальные переменные

  соглашение

  
  после сжатия в GCC в advanced mode могут возникнуть проблемы, если такие приватные свойства будут переименовываться минификатором.
  если сохранять имена - то может страдает качество сжатия кода.
  

я, вероятно, не всё учел. пишите, может быть, добавлю в ФАК .

что скажите на этот счет? (от поста по ссылке, до конца темы)

Функция inherit для эмуляции Object.create(proto)

Хороший вопрос.. Определить бы :)

ну процитируй что ли, или разжуй. почему ты говоришь "я написал, что <...>. чем ты читаешь?" вместо того, чтобы пояснить? все равно собеседник тебя не поймет, если ты его пошлешь читать пост заново.

я лучше болт забью, чем буду вникать в твои посты, путающие смысл.
тюю... точно. я забыл.