мда. джава позволяет при желании отстрелить себе ногу.
собсно интересно, почему вообще должен создаваться объект у которого конструктор кинул Exception? как насчет того, что мы не знаем, в каком состоянии создаваемый объект. ИМХО самым корректным решением было бы «staticInstance is null», ибо время жизни объекта должно начинаться после завершения работы конструктора.
з.ы. первая мысль которая приходит в голову при таком коде — segfault
в списке книг я бы еще упомянул книгу Троелсена «C# и платформа .NET. Библиотека программиста » www.piter.com/book.phtml?978531800750 и Рихтера CLR via C#. Программирование на платформе Microsoft .NET Framework 2.0 на языке C#. Последняя полезна для общего развития.
И как пожелание, расскажите еще про NUnit и NAnt, первый это фреймворк для тестов, а второй — система сборки проектов.
Да, вам еще повезло, иногда приходится работать без этих библиотек(например есть n версий ворда и надо уметь работать со всеми без перекомпиляции). иначе код начинает выглядеть примерно так public ExcelHelper() {
oExcel = Activator.CreateInstance( Type.GetTypeFromProgID( "Excel.Application" ) );
oWorkbooks = oExcel.GetType().InvokeMember( "Workbooks", BindingFlags.GetProperty, null, oExcel, null );
oWorkbook = oWorkbooks.GetType().InvokeMember( "Add", BindingFlags.InvokeMethod, null, oWorkbooks, null, new System.Globalization.CultureInfo(1033) );
oWorksheets =
oWorkbook.GetType().InvokeMember( "Worksheets", BindingFlags.GetProperty, null, oWorkbook, null );
oWorksheet =
oWorksheets.GetType().InvokeMember(
"Item", BindingFlags.GetProperty, null, oWorksheets, new object[] {1} );
}
зато если грамотно написать, такие грабли умеют работать с офисами от 2000(на более ранних не проверял) до 2007 без перекомпиляции.
насчет кода — в общем, возможно стоило бы заменить наследование делегированием, хотя может и нет, вопрос спорный, зависит от проекта.
насчет object oTrue = true; — это необходимость, поскольку в сигнатуре методов обычно указано что-то типа m1( ref object obj1).
для избавления от такого кода из одного проекта в другой кочуют хелперы, которые всю эту жуть хоть как-то оборачивают в что-то вменяемое, чего и вам советую.
а так — отличная штука
З.Ы. если кто сможет присоветовать нормального sip оператора с нормальным качеством звонков по югу России, буду благодарен :)
Хотя качество связи у skype-out в сравнении например с sipnet лучше.
собсно интересно, почему вообще должен создаваться объект у которого конструктор кинул Exception? как насчет того, что мы не знаем, в каком состоянии создаваемый объект. ИМХО самым корректным решением было бы «staticInstance is null», ибо время жизни объекта должно начинаться после завершения работы конструктора.
з.ы. первая мысль которая приходит в голову при таком коде — segfault
И как пожелание, расскажите еще про NUnit и NAnt, первый это фреймворк для тестов, а второй — система сборки проектов.
public ExcelHelper() {
oExcel = Activator.CreateInstance( Type.GetTypeFromProgID( "Excel.Application" ) );
oWorkbooks = oExcel.GetType().InvokeMember( "Workbooks", BindingFlags.GetProperty, null, oExcel, null );
oWorkbook = oWorkbooks.GetType().InvokeMember( "Add", BindingFlags.InvokeMethod, null, oWorkbooks, null, new System.Globalization.CultureInfo(1033) );
oWorksheets =
oWorkbook.GetType().InvokeMember( "Worksheets", BindingFlags.GetProperty, null, oWorkbook, null );
oWorksheet =
oWorksheets.GetType().InvokeMember(
"Item", BindingFlags.GetProperty, null, oWorksheets, new object[] {1} );
}
зато если грамотно написать, такие грабли умеют работать с офисами от 2000(на более ранних не проверял) до 2007 без перекомпиляции.
насчет кода — в общем, возможно стоило бы заменить наследование делегированием, хотя может и нет, вопрос спорный, зависит от проекта.
насчет object oTrue = true; — это необходимость, поскольку в сигнатуре методов обычно указано что-то типа m1( ref object obj1).
для избавления от такого кода из одного проекта в другой кочуют хелперы, которые всю эту жуть хоть как-то оборачивают в что-то вменяемое, чего и вам советую.
2 — демон крутится отдельно от сайта, что в общем-то хорошо.
CSV->CVS
во-вторых, я за такой код отрывал бы что-нть жизненно важное. (на php и js не пишу, но подозреваю, что это плохой пример для подражания)
Да, я понимаю, что смешаные типы в массиве это забавно, но надо понимать, что это влечет проблемы и их лучше избегать изначально.
насчет голосования и языков — «разруха она в головах», писать надо так, чтобы такого поведения не возникало.
А жаль, в некоторых случаях winword на сервере можно было бы убрать :(