Нужны ли вообще геттеры сеттеры в классах?

>Ну объясни мне, что незаменимого в методах вроде:

полиморфизм незаменим никакими костылями

Ну объясни мне, что незаменимого в методах вроде:

int getField() { return _field; } 
 
void setField(int v) { _field = v; } 

элементарно, Ватсон, что будет если _fiеld поменяется на _custom_field?

> полиморфизм незаменим никакими костылями

Еще один с заклинаниями. Сколько ж тут священников карго-культа...

Нет, я еще и в смысле «Hello, world!\n» - нефиг каждой структуре лепить [сг]еттеры.

инкапсуляция

> элементарно, Ватсон, что будет если _fiеld поменяется на _custom_field?

Ахренеть. Ты хочешь сказать - поменяется имя поля? От этого защищают *еттеры?

Еще один с заклинаниями. Сколько ж тут священников карго-культа...

ты выразись конкретнее что тебя не устраивает

PS вайнить без причины - признак маньячины

> элементарно, Ватсон, что будет если _fiеld поменяется на _custom_field?

Ахренеть. Ты хочешь сказать - поменяется имя поля? От этого защищают *еттеры?

прикинь - да :) код привести?

>> Нет, я еще и в смысле «Hello, world!\n» - нефиг каждой структуре лепить [сг]еттеры.

инкапсуляция

Если для тебя [sg]etField - это инкапсуляция, то спорить с тобой просто нет смысла.

>> Ахренеть. Ты хочешь сказать - поменяется имя поля? От этого защищают *еттеры?

прикинь - да :) код привести?

Да. Хочу посмотреть, как люди сознательно запутывают программы.

> ты выразись конкретнее что тебя не устраивает

Я уже сказал - меня не устраивают туманные фразы, которые произносятся без понимания идей, которые за ними стоят.

Если для тебя [sg]etField - это инкапсуляция

уважаемый, надо не передёргивать, а мозгом думать - думайте

> Оно нужно только тогда, когда установка значения поля сопровождается действием - валидацией значения, установкой других полей или еще чем-то.

об чем и речь.

Ну объясни мне, что незаменимого в методах вроде:

см. выше.

> ты выразись конкретнее что тебя не устраивает

Я уже сказал - меня не устраивают туманные фразы, которые произносятся без понимания идей, которые за ними стоят.

пруф отсутствия понимание есть?

>>а зачем на каждую переменную писать? можно их кучками же юзать. setDimensions(height,width,depth,weight); например.
всеми руками за!
имха, само по себе множество сеттеров и геттеров ничего не несет. группировать поля по смыслу и передавать в такой сеттер как параметр промежуточную структуру, либо map, либо что еще. и расширяется отличненько и код выглядит приятно.

> уважаемый, надо не передёргивать

А что тут передергивать?

нефиг каждой структуре лепить [сг]еттеры.

инкапсуляция

всё же понятно.

а мозгом думать - думайте

Я ничем другим думать и не умею. Но точно знаю, что процесс размышления некоторые заменяют процессом запоминания.

велкам, вот элементарный пример, смотри

class Foo {
public:
	int _field;
};

class Bar {
public:
	int _field;
};

int main(void) {
	Foo foo;
	Bar bar;

	foo._field = 10;
	bar._field = foo._field;

	return 0;
}

теперь если мы поменяем _field у foo то в скольких местах нам придётся менять код?

смотрим дальше

class Foo {
private:
	int _field;
public:
	int get_field() const {
		return _field;
	}

	void set_field(int new_field) {
		_field = new_field;
	}
};

class Bar {
public:
	int _field;

	void set_field(int new_field) {
		_field = new_field;
	}
};

код менять вообще не придётся

???

PROFIT!

Я ничем другим думать и не умею.

4.2

тогда перестаньте изображать толстое трололо и думайте вдумчиво

всмысле

class Foo {
private:
	int _field;
public:
	int get_field() const {
		return _field;
	}

	void set_field(int new_field) {
		_field = new_field;
	}
};

class Bar {
public:
	int _field;

	void set_field(int new_field) {
		_field = new_field;
	}
};

int main(void) {
	Foo foo;
	Bar bar;

	foo.set_field(10);
	bar.set_field(foo.get_field());

	return 0;
}

> теперь если мы поменяем _field у foo то в скольких местах нам придётся менять код?

Поменяем на _field на что? На m_field?

код менять вообще не придётся

???

PROFIT!

Блин, и эти люди называют троллем _меня_ %) Что на месте "???", в чем PROFIT? А то генерировать ничего не делающий код любой может.

бггг :) давай так, в чём разница между первым и вторым случаем, на твой взгляд

тут не профит - тут надо руки отрывать за одинаковые названия полей ;) а вообще детский сад тут развели, геттеры нужны - т.к. позволяют на чтение/запись в случае надобности добавлять проверки/преобразования и т.п., если поле однозначно не потребует такого - то смысла лепить к нему геттер особого нет, но и ничего страшного не будет, если сделать - компилятор заинлайнит его и все будет опять же хорошо, так что спор ни о чем, давайте еще поспорим про TAB vs SPACE - тоже очень важная тем ;)

> давай так, в чём разница между первым и вторым случаем, на твой взгляд

На мой взгляд, ее просто нет. А на твой взгляд, в чем она? Кроме формы записи обращения к полю.

> теперь если мы поменяем _field у foo то в скольких местах нам придётся менять код?

Поменяем на _field на что? На m_field?

для данной задачи несущественно на что, это просто пример, Вы ж не думаете что в production будет такой же простой случай? :)

давайте еще поспорим про TAB vs SPACE - тоже очень важная тем ;)

Для для любителей душить Python.

Не, объект свеча я отдельно оставил, но таки сделал нормальный длинный конструктор. // оказывается кутейный парсер строк штука великолепнейшая.

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

ут не профит - тут надо руки отрывать за одинаковые названия полей ;)

да, а почему? как должны между собой коррелировать поля классов?

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

эхм, смотрим внимательно

int get_field() const {
    return _field;
}

ничего не чувствуете, не?

> да, а почему? как должны между собой коррелировать поля классов?

надо ложится спать - показалось, что там наследование

ничего не чувствуете, не?

а что я должен чувствовать?

>компилятор заинлайнит его и все будет опять же хорошо

Во! Это пожалуй главное было. Таки еще был вопрос относительно производительности сеттер/геттер vs конфу/кодинг.

>>> теперь если мы поменяем _field у foo то в скольких местах нам придётся менять код?

Поменяем на _field на что? На m_field?

для данной задачи несущественно на что, это просто пример

Ну так какой смысл приводить пример, который ничего не объясняет? То, что *еттеры должны защищать от переименования полей, я уже понял.

ничего не чувствуете, не?

Ты пишешь на убогом языке у которого нет properties.

На мой взгляд, ее просто нет. А на твой взгляд, в чем она? Кроме формы записи обращения к полю.

маленький нюанс с модификатором const не в счёт, да?

а если у вас там будет не int, а unsigned char* - тоже не будет никакой разницы?

>ничего не чувствуете, не?

Ты пишешь на убогом языке у которого нет properties.

4.2 смотри тут

>> На мой взгляд, ее просто нет. А на твой взгляд, в чем она? Кроме формы записи обращения к полю.

маленький нюанс с модификатором const не в счёт, да?

При наличии set_field? Не в счет.

> 4.2 смотри тут

там только присваивание, а обращения к методам уже не сделать - например такое не пройдет:

string lname = obj.Name.Lower();

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

он поясняет базовые вещи, начинать надо с них :)

То, что *еттеры должны защищать от переименования полей, я уже понял.

а разве этого мало?

к тому же геттеры защищают от модификации возвращаемое значение

и это только начало, далее идут проверки и прочее

а?

int i = 5,j;
PropTest test;
test.Count = i;    //-- call the set method --
j= test.Count;     //-- call the get method --

> а?

я тебе специально написал кусок кода, он слишком сложный?

> маленький нюанс с модификатором const не в счёт, да?

При наличии set_field? Не в счет.

бггг, Вы прикидываетесь, да? или правда не в курсе зачем const после функции пишется?

>> Ну так какой смысл приводить пример, который ничего не объясняет?

он поясняет базовые вещи

Доо.

То, что *еттеры должны защищать от переименования полей, я уже понял.

а разве этого мало?

Да. ИМХО, за функцию setField, которая только присваивает значение some_other_field, нужно бить по рукам.

и это только начало, далее идут проверки и прочее

Ну наконец-то. Тогда вернемся к http://www.linux.org.ru/jump-message.jsp?msgid=4708731&cid=4709021 и ты ответишь на заданный там вопрос.

//-- call the set method — , //-- call the get method —

или я что Вас не вполне понял?

Это называется костили, в реальном мире.

property по сути маскируется под обычное поле класса, в С++ замаскировать полностью не получится, т.к. к такому импровизированному property не получится применить оператор ".", только "->"

Как упомянули тут, для рефакторинга и инкапсуляции. Так же, я в геттерах выполняю операции часто над переменными. Дабы не городить лишние функции.

Это называется костили, в реальном мире.

а где их нет, в реальном то мире? :)

>>> маленький нюанс с модификатором const не в счёт, да?

При наличии set_field? Не в счет.

бггг, Вы прикидываетесь, да?

Блин, да перестань ты бугагакать, делать умный вид и писать в тиреч-стиле. Я могу прочитать поле и записать в него всё, что угодно. От чего меня защищает твой const в get_field?

или правда не в курсе зачем const после функции пишется?

Если что, я начинал кодить на Си++ еще в Turbo C++, так что не трудись «пояснять базовые вещи» :)

property по сути маскируется под обычное поле класса, в С++ замаскировать полностью не получится, т.к. к такому импровизированному property не получится применить оператор ".", только "->"

да, у данного метода есть определённые ограничения, и?

> да, у данного метода есть определённые ограничения, и?

и это то, что я написал в самом начале ;)

Блин, да перестань ты бугагакать, делать умный вид и писать в тиреч-стиле. Я могу прочитать поле и записать в него всё, что угодно. От чего меня защищает твой const в get_field?

если ты и правда:

начинал кодить на Си++ еще в Turbo C++

то должен бы и сам знать ответ на вопрос :)

> да, у данного метода есть определённые ограничения, и?

и это то, что я написал в самом начале ;)

а! ну тогда согласен