Re[5]: Функциональное программирование в Nemerle
От: Кэр  
Дата: 31.05.07 11:54
Оценка:
Здравствуйте, VladD2, Вы писали:

Кэр>>В том-то и дело, что не равно. Метод может вернуть существующую копию объекта, конструктор всегда даст новый объект. Это уже дает совершенно разное отношение к этому коду.


VD>И в чем разница?

VD>И как ты справляешся с ситуацией когда у тебя есть фабричный метод? Ведь в этом случае по внешнему его виду нельзя скзать создаст ли он экземпляр или вызвратит уже имеющийся.

Дело в другом: когда мне объект падает от конструктора — я знаю, что это brand new объект. У меня не будет проблем с синхронизацией при его использовании. Мне не нужно будет думать — а вдруг его свойства уже как-то криво проинициализированны и мне нужно сначала исполнить шаманский танец перед его использованием.
Чаще всего Если это не так — значит это бага класса.
Поясню на примере — если мне приходит SqlCommand из какого-то метода, значит лезем в метод и смотрим, что за объект, что с ним уже сделали и пр. Если объект получен из конструктора — сразу работаем дальше.

VD>К тому же, если это так уж актуально, то всегда можно подвести мышку в IDE и посмореть, что это такое...


Да поддержка IDE — великая вещь. Но если из самого кода можно понять, что тут написано и быстро сделать вывода, причем стоимость создания такого кода невелика — то нужно писать как можно более понятный код. Ведь за мышкой покаааа потянееешься...

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


VD>Лучше сосредоточить свое внимание на логике программы. Тогда, если что просто не случится. Или если вдруг случится, то ты все равно будешь иметь больший контроль над программой, так как не возишся с мелочевкой, а владеешь сутью программы.


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

Кэр>> В одношаговых логических цепочках — это все равно, если что внимательно посмотрели на контекст, спохватились, начали думать в другом направлении. В более длинных цепочках подобные умолчания будут только тормозить решение проблемы.

VD>Это в тебе говорят привычки и догмы. Точнее ты пыташся выдумать проблемы там где их нет, чтобы обосновать привычный тебе внешний вид кода.
Отнюдь. Вот это ни разу не привычный мне внешний вид кода.
def calc() : bool
{}

Просто этот код гораздо более информативный, чем этот:
def calc()
{}

Причем данная инфмормативность для автора кода чаще всего ничего не стоит.

Кэр>>И вообще если уж говорить про принципиальные отличия: внутри обычного метода можно использовать вызовы виртуальных методов, внутри конструктора нельзя — так что думать о них как о близнецах-братьях очень не рекомендуется.


VD>1. Ты глубого заблуждаешся. В дотнете без проблем можно вызвать виртуальные методы из констроторов и финалайзеров.


Как ты думаешь, что произойдет, если создать экземпляр Derived класса?
public abstract class Base
    {
        public Base()
        {
            Log("Instance created");
        }

        public abstract void Log(string message);
    }

    public class Derived : Base
    {
        public Derived()
        {
             _logMessages = new StringBuilder();
        }

        private StringBuilder _logMessages;

        public override void Log(string message)
        {
            _logMessages.Append(message);
            Console.WriteLine(message);
        }
    }



VD>2. А это уже никого не трогает. Точнее трогает того кто создает этот метод/конструктор. Ты работаешь с черным ящиком. Собственно это и есть инкапсуляция.


С этим не спорю. Я говорил о том, что в целом нельзя относится к конструктору и к методу, как к одному и тому же.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.