Правила создания конструктора, подскажжжите

[_Bers]

Сообщение от still_alive

Не особо верится. Сможешь найти мне в стандарте хоть одно упоминание о member function как о method?

Было бы странно искать в официальном документе слэнговые выражения.

Сообщение от still_alive

Не понял почему.

Ты кидаешься в крайность. Писать негибко - плохо. Писать слишком гибко - тоже плохо. Опытный программист знает, где гибкость стоит усложнений, а где нет. В данном случае ничего не усложняется, а гибкость значительно возрастает.

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

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


Попытайтесь проследить за моей мыслью:

"Если нам нужна гибкость - мы пишем год так, что бы он был гибким" - это настолько очевидно, что не оставляет места для критической оценки.
Раз нужно - значит нужно делать. Здесь нет никакого выбора действий.

"Если нам не нужна гибкость, то... что мы делаем" ?

Вы почему то думаете:

Сообщение от still_alive

Писать негибко - плохо.

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

Если вам не нужна гибкость, вы все равно будете писать гибко, потому что писать негибко - это плохо.

Часы программиста стоят дорого. На что вы тратите деньги компании?
Зачем вы предлагаете тратить время на то, что никому не нужно?

Сообщение от still_alive

В данном случае ничего не усложняется, а гибкость значительно возрастает.

Если гибкость не нужна - не нужно тратить на неё время (деньги компании).

Что касается простоты: самый простой, самый идеальный код - тот, который не был написан.

[Dimka-novitsek]

Спасибо огромное!!!!!

Отличается конструктор в public и в private ?? Можно ли в оном конструкторе инициализировать оба этих типа переменных сразу? Можно ли их перегрузить-один в public один в private?

[Igor95]

public, private - спецификторы доступа. Они образуют правила областей видимости для идентификаторов-членов класса. public - идентификатор, объявленный в этой области видимости, видим вне класса. private - идентификатор, объявленный в этой области видимости, видим только внутри класса.
Есть еще один спецификатор доступа - protected. Действует точно также как private, за исключенем того, что идентификаторы, объявленные в protected-области видимости базового класса, БУДУТ ВИДИМЫ ТОЛЬКО ВНУТРИ производного (от этого базового) класса.

Отсюда, перегрузить конструктор можно в private области, только вот использовать такой перегруженный конструктор для создания объекта в клиентском коде не сможем... т.к он видим только внутри класса.

[Dimka-novitsek]

Спасибо!!!

[_Bers]

Сообщение от Igor95

А если этот код будет поддерживаться другим программистом, который, по не внимательности, изменит eMAXIMUM так, что calculator вообще по-другому себя вести будет?

У вас искаженное представление об инкапсуляции.

Во-первых, инкапсуляция существует на уровне "пользователь - инструмент". Позволяет использовать инструмент, не зная подробностей его реализации.

Программист, который лезет в чужой код и изменяет его - это уже не пользователь. Это разработчик. И он должен знать и понимать, что именно он делает. Поэтому, ни о какой инкапсуляции речи уже не идет.

Во-вторых, именованная константа eMAXIMUM для того и существует, что бы абстрагироваться от конкретного значения константы, и отталкиваться только от её имени.

Поэтому, можно как угодно менять её значение. eMAXIMUM всегда будет просто eMAXIMUM.

Пример:

http://codepad.org/VAAopKvb

#include<iostream>
 
using namespace std;
 
struct Calculator
{
    enum eSAFETY{ eMAXIMUM, eMINIMUM };
 
    void Work()const
    {
        cout << ((mSafety==eMAXIMUM)? "max_level": "min_level")<<endl;
    }
 
    eSAFETY mSafety;
};
 
 
int main()
{
   Calculator obj;
   obj.mSafety = Calculator::eMAXIMUM;
   obj.Work();

   //попытка подсунуть что-то некорректное
   //obj.mSafety = 10;

   //error: invalid conversion from 'int' to 'Calculator::eSAFETY'

   return 0;
}

Подсунуть что-то левое "ничайно" уже не получится.

Вы конечно можете написать что-то вроде:

 obj.mSafety = static_cast<Calculator::eSAFETY>(10);

Но это откровенный саботаж, и "ничайно" так написать не получится.
Делать же защиту от откровенных вредителей и последних дибилов не имеет смысла: все равно сломают. Зря только время будет потрачено.

Вот и получается, что сеттер в этой ситуации просто избыточен.



Теперь рассмотрим другой вариант:

Предположим, у нас есть виджет, который может содержать в себе другие виджеты.
И при изменении свойства "безопасность", родитель должен пробежать по всем своим деткам, и всех их уведомить: "новый режим работы!"

Что бы детки были в курсе, и смогли поменять свои собственные режимы, и оповестить уже своих собственных деток о этом изменении.

В этой ситуации нужен сеттер. Просто потому, что это единственный простой способ организовать такую логику.

[Igor95]

Да, о таких способах использования я не подумал. Прошу прощения, был не прав. Спасибо за внятное разъяснение

[Dimka-novitsek]

Очень приятно читать такое развитие темы!

[still_alive]

Сообщение от _Bers

Было бы странно искать в официальном документе слэнговые выражения.

Ну метод - это вполне себе официальный термин ООП. Просто когда речь идет конкретно о С++, как по мне, так правильнее говорить функция-член.

Сообщение от _Bers

вам не нужна гибкость, вы все равно будете писать гибко, потому что писать негибко - это плохо.

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

Сообщение от _Bers

Если гибкость не нужна - не нужно тратить на неё время (деньги компании).

Если не нужна - само собой. Однако в данном конкретном случае я считаю, что нужна.