sax_ol, давай уже на "ты", а то с моей стороны получается не вежливо
короче говоря, когда я вызываю конструктор, то я предполагаю, что:
1) объект создан удачно;
2) объект создан с ошибкой;
3) объект не создан по какой-либо причине;
генерация исключения в конструкторе влечет к возврату Nothing, т.е. если ошибка не обрабатывается самим же конструктором, то 2 и 3 случаи приводят к одному результату - 3-му случаю!
чес гря, я уже давно с Delphi не работал и не помню как там было, но специфика LS такова, что наиболее удобными ситуациями являются варианты 1 и 3!
Кроме того, конструкция
Код:
dim a as object
set a = new object()
if not(a is nothing) then
' do something
end if
удобнее и проще чем
Код:
dim a as object
set a = new object()
if a.successfullyCreated() then
' do something
end if
так как мне не обязательно знать инструкцию пользования классом (из твоего утверждения
), т.е. знать как именно в конкретном случае называется successfullyCreated() и что он возвращает...
возьму на себя ответственность и предположу, что определенные правила поведения объектов - те правила, которые принял для себя программист, который определил класс этого объекта...
кроме того, я могу ошибаться, но ООП не предписывает, что объект не может быть создан, ООП определяет, что все может быть описано с помощью объектов, а также устанавливает правила поведения родительских и дочерних объектов, и дает рекомендации к реализации классов (те же методы доступа и сокрытия полей), хотя не обязует делать именно так!
если у меня есть поле, которое в соотв с требованиями должно изменяться прямо, то тогда какой смысл навязывать методы доступа?
это лишь приведет к увеличению затрат времени написания, и отработки кода...
кроме того, если бы объект всегда должен был создаваться, тогда не имеет смысла куча конструкций во множестве языков программирования, которые позволяют определить содержит ли переменная экземпляр предписанного ей класса!
на счет ресурсов, не только файлы на диске являются ресурсами, поэтому проблемы захвата и освобождения ресурсов всегда актуальны, просто большинство современных языков предлагают свои широкие и могучие возможности по очистке мусора, но программисты проф. уровня всегда будут следить самостоятельно за выделением ресурсов, т.к. обычно они решают задачи посложнее чем содержать пару чисел да строк в памяти...
ну и к документации
да, самая интересная вещь в нашей жизни... мы очень редко ее используем, чаще всего только тогда, когда подсказать нам некому, а метод тыка не срабатывает
хороший разработчик тем и отличается от остальных, что сначала проведет самостоятельный анализ предлагаемых ему к использованию средств, будь то чей-то объект или системка, и как бы то нам не думалось, а начинать анализ лучше всего именно с прилагаемой документации, другое дело, что очень редко мы ее получаем, тогда приходится копаться в коде, сидеть в дебагере и т.п.
исходя из соображений экономии времени и сил предположу, что наш спор не выедет ни в какое логическое завершение, т.к. мы обсуждаем правила написания, которые формулируем для себя сами, лично, либо которые устанавливаются нам теми, кто ставит задачу...
я, например, если потребуется использую и генерацию исключений, и вызов методов проверки удачного создания объектов и другое, все зависит от того, что нам нужно получить...
