Сообщений в теме: 117

[Zulkar]

Вот! Знающих людей в КЗ немного, но все же они есть!

И все же, разница между abstract class и interface есть. У абстрактного класса возможностей больше, чем у интерфейса. Он может содержать и неабстрактные функции, а также данные (как закрытые, так и открытые). Зато интерфейсы гибче - позволяют обеспечить полиморфизм даже для классов, вообще не связанных между собой никаким общим "предком".

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

[Zulkar]

Проприетарщина.

Это да... Но поскольку .NET работает только под виндой - моно пока что отстой полнейший, и кроме пайнта ничего не переносится, то получается что писать под никсами на .NET (читай шарпе) нельзя, а винда настолько проприетарна, что уже тут ничего не поделаешь.

[Я Легенда]

ээээээээ.... подскажите плс - я вообще человек тёмный - запретили после чего? т.е. оно где было разрешено до чтобы его запретили? (я в мир пришел когда уже был дотнет, а про былое бабушка сказки перед сном рассказывала )

А, ну теперь понятно, почему у Вас такие ответы получаются. Бабушкины сказки - вот, оказывается, в чем истинная причина! Вам пора бы уже знать что-нибудь более серьезное. Например, MSDN Library. Или еще лучше, стандарт ECMA-334 C# Language Specification 4 th edition (возможно, есть уже и более новая редакция). Ответ на Ваш вопрос: множественное наследование в .NET запрещено совсем не "после чего", а "в отличие от чего". В отличие от С++, при создании .NET с самого начала было принято правило: каждый тип может наследовать только одному родительскому типу, и в конечном счете любой тип наследует типу Object из пространства имен System. Тип System.Object поэтому является корневым для всех остальных типов.

АААА...
А скажите вот - С++ - это в смысле сам язык позволял множественное наследование или какая-то конкретная реализация его или как вообще? Просто мне бабушка про это никогда не рассказывала - что бывает множественное наследование в С++. Да и в никаких реализациях не упоминалось. САм то я не кодер - код программный не пишу на С++ и т.д.

["0x0000"]

есть стандарт С++, ну вобщем это описание языка, по которому потом делают компиляторы типа Visual C++ и GCC ;((

[Zulkar]

АААА...
А скажите вот - С++ - это в смысле сам язык позволял множественное наследование или какая-то конкретная реализация его или как вообще?

Сам язык.
Бьерн Страуструп. Язык программирования С++. глава 6.5. Ссылку на ANSI не дам, ибо нету у меня

Просто мне бабушка про это никогда не рассказывала - что бывает множественное наследование в С++. Да и в никаких реализациях не упоминалось.

Упоминалось Ищите "multiple inheritance" в MSDN-ах

[-Zen2004-]

Ладно вижу тут много людей начили филосовский вопрос....
Тогада спрошу у всех кто все таки с .Нетом работает
Вообшем есть БД на sql сервере имеется две таблицы справочник товара: поля (id,Name,NDS) и таблица тело документа где вбивается весь товар (id, NameId,Kolichestvo,Chena,Summa). Вот в теле документа поле NameId свзано Forigen Key с таблицой товаров по уникальному ключу и это есть правельно с точки реализации БД.
Теперь внимание
вот передо мной документ в нем DataGridViev я говорю создать строку и шелкаю на ячейке где должно быть наименование у меня открывается форма со списком товара я выбираю товар и таблица возврасчает мне id товара и Name товара по идее чтобы обнобить бд я должен в ячейку записать id все красиво с точки реализации бд есть документ в катором есть уникальные ссылки на товар .
Но вопрос в следуюшем ведь в ячейке менеджеру нужно видеть не id товара а название.
Продумывал 2 варианта сделать колонку Name в документе невидимой и добавить колонку наименование которая будет отображать название товара
2-й вариант как только выбрал товар сразу записывать в БД id а в ячейке просто выводить название но ето тоже не есть хорошо. Так вот интерестно как такое делается стандартно
примером может послужить таже 1с, когда в документе выбиваешь товар ведь БД хранит id а отображается наименование товара.

[Kork]

Тогада спрошу у всех кто все таки с .Нетом работает

Тут люди о высоком начали говорить, а вы "в грязных ботинках", в такую беседу...

[Visual1]

Тут люди о высоком начали говорить, а вы "в грязных ботинках", в такую беседу...

О каком таком "высоком"? Топикстартер длительное время вообще не появлялся и не отвечал на вопросы. Никто и не знал, чего ему на самом деле надо. И поэтому обсуждались другие вопросы - кстати, ничего "высокого", вопросы довольно простые. И еще по ходу кое-кому пришлось восполнять пробелы образования чьей-то бабушки.

[v04bvs]

Проприетарщина.

Это да... Но поскольку .NET работает только под виндой - моно пока что отстой полнейший, и кроме пайнта ничего не переносится, то получается что писать под никсами на .NET (читай шарпе) нельзя, а винда настолько проприетарна, что уже тут ничего не поделаешь.

С опозданием где-то на месяц, вышла новая версия кросс-платформенного фреймворка Mono - 2.0 - свободной реализации Microsoft.NET. Список изменений достаточно обширный:

* Полностью реализованы ADO.NET 2.0, ASP.NET 2.0, Windows.Forms 2.0.
* C# 3.0, полная поддержка LINQ-выражений. Компилятор теперь доступен под двойной лицензией - GPL2 и MIT/X11.

С mono не всё так плохо, но проблема в том, что он вряд ли будет заменой. Другое дело, что можно его использовать в качестве основной платформы, а MS .NET как бесплатную альтернативную пускалку приложений на Mono. Но это непопулярный путь, поэтому .NET в основном остаётся проприетарным.

[Zulkar]

С mono не всё так плохо, но проблема в том, что он вряд ли будет заменой. Другое дело, что можно его использовать в качестве основной платформы, а MS .NET как бесплатную альтернативную пускалку приложений на Mono. Но это непопулярный путь, поэтому .NET в основном остаётся проприетарным.

Что лично вам мешает сделать это? Да и траблы с совместимостью все равно будут.
Вот, про DataGridView - он реализован в моно не полностью,

Mono 2.0 contains a much better implementation of DataGridView

То есть будут переносимы не все приложения (читай - практически ни одно приложение, использующее DataGridView не будет переносимо. А поскольку это довольно часто используемая вешь, значит пока моно нафик никому не надо. Гном может вытащить его, но гном щас такой гадостью стал, злые языки говорят, что во многом благодаря моно.

Я лично не вижу ниши для Моно. На виндах вместо него есть .NET и С++, на линуксе - плюсы и джава довольно хорошо справляются.

PS: WinForms мне не понравился, по сравнению с Qt - неудобен.

[-Zen2004-]

парни никто не спорит хорош язык или плох у каждого есть свои +++ и ---
Если на то пошло в Раб. нуждах язык нужен для чего?
Для клиентских машин которые работают с БД

Сервер делает всю работу задача клиента вносить и получать информацию
Сервер понятно Oracle, MS sql,postrgree mysql и т.д. в зависимости от задачи предприятия

Клиент
Строгий интуитивный Интерфейс
Быстрая дороботка модификация клиента.
Обновление на клиентских машинах программы
Чему тут .Net может не удовлетворять ?
неплохой вариант я думаю темболее для людей которые не собираются спрыгивать с винды есть еще одно приемущество что следующая винда будет без WIN API праграммисты смогут использовать тока .Net fraemwork
так что парни никому не навязаваю не говорю что это круто но предпологаю что язык перспективный с большим будующим.

[-Zen2004-]

А что какчается линукса пока на нем не будет обширного кол-ва игр и бизнес приложений, драйверов врядли его будут его использовать в крупных масштабах
как сервер бд, провайдер, в кргу программистов которые любят низкоуровневое програмирование да он идеален но таких меньшество....
Вот недавно пытался Бухгалтершу с MS oficca на OpenOffice переучить думаю кто с этим сталкивался поймет....

[Zulkar]

неплохой вариант я думаю темболее для людей которые не собираются спрыгивать с винды есть еще одно приемущество что следующая винда будет без WIN API праграммисты смогут использовать тока .Net

То есть вы хотите сказать, что все приложения будут сидеть в управляемой песочнице? Не думаю, что это будет возможно, пока процессоры не будут исполнять .NET нативно.
Насчет быстродействия - игры будут нативными еще долго. XNA не дает того контроля над кодом, который можно получить только средне и низкоуровневыми языками (С/С++ и ассемблер).

Про бухгалтершу - как шеф скажет, так и будет. Можно пересадить насильно. Офисное быдло, простите, мало разбирается в программах. И им глубоко параллельно, в каком браузере лазить по одноклассникам. Отмазки типа того что тут кнопочка слева, а я хочу справа, идут лесом. Часто достаточно поставить иконку ворда и сказать что это новый ворд такой, а старый все, не пашет. Или предложить за свой счет купить MSO.

По поводу линукса - большая часть "бизнес-приложений" которые я видел, написано вот такими бухами, которые решили что они программисты. Ключевые черты такого кода - крякнутые платные компоненты, и >200 строк кода на каждую кнопку. Про классы и model-view-controller никто из них не знает.
Как говорится, основная проблема Delphi - это программисты на delphi. Вместо дельфи можно подставить любой язык с низким уровнем вхождения.

Линукс будет более популярен, когда у нас более плотно возьмутся за борьбу с пиратством. Вон тема была- "помогите выбрать легкий антивирь". Надо лазить по интернету и писать документы, а комп старый и антивирь нужен легкий, денег на новый комп нету. Линукс - отпадает, ибо там люди "не разбираются в компах". Если бы этим люди не могли поставить бесплатно пиратку, а должны были купить винду+офис+антивирь+дофига большая куча софта, то они бы сильнее задумались над выбором ОС.

[Visual1]

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

"Чисто виртуальные" функции (под этим названием они известны в С++), это то же самое, что абстрактные функции в С#. Поэтому вывод, что "в этом случае множественное наследование выгоднее", не очевиден. Но если потребность в чем-то вроде множественного наследования есть, то опять же, интерфейсы в .NET вполне с этим справляются - наследуемых интерфейсов у класса может быть сколько угодно. К тому же, никто не запрещал использовать эти возможности в сочетании. Например, можно определить интерфейс и создать базовый класс (в том числе и абстрактный), который реализует этот интерфейс.

[Я Легенда]

Бабуля сказала что такая байда называется LookUp - подстановка. Т.е. в списке отображается вся или часть информации, а поля с кодами просто не выводятся на экран - но вставка в базу идет именно из них. Короче говорит в MS Access такое все встроенное и по быстрому - у них все секретарши это юзали.

Еще бабуля говорит чтобы я на кодеров забил и голову себе не пудрил. Мол дедуля мой древнегреческий покойный сию великую фразу говорил "Мысль есть материя и потому первична, реализация вторична. Концепции это главное".

Еще бабуля говорит что классы это атрибут объектно-ориентированного подхода, а интерфейсы это атрибут компонентно-ориентированного подхода. Мол вот в неуправляемом коде для взаимодействия компонент интерфейсы да COM модель использовались, а ужо внутри одного компонента объектно-ориентированный подход. Но с приходом .Net Framework типа как все изменилось и границы стерлись - ибо взаимодействие компонент проще организовать т.к. фреймворк им вроде как предоставляет всю среду выполнения то. И мол скорее всего просто сам фреймворк разбит так по компонентам, что многие вещи выставлены через интерфейсы - вообщем особенности физической реализации что стали возможны благодаря использованию фреймворка, да и вообще мол это компонентно-ориентированный подход такой. Ну вобщем бабуле виднее - она ж мож еще мертвого страуса видала када молода то была. Сам то я не кодер - так шо будем пока поверить бабуле - а там надо будет до истины самому покопать.

[Zulkar]

"Чисто виртуальные" функции (под этим названием они известны в С++), это то же самое, что абстрактные функции в С#. Поэтому вывод, что "в этом случае множественное наследование выгоднее", не очевиден.
Но если потребность в чем-то вроде множественного наследования есть, то опять же, интерфейсы в .NET вполне с этим справляются - наследуемых интерфейсов у класса может быть сколько угодно. К тому же, никто не запрещал использовать эти возможности в сочетании. Например, можно определить интерфейс и создать базовый класс (в том числе и абстрактный), который реализует этот интерфейс.

Я имел в виду, когда мы скрещиваем не совсем скрещиваемые вещи, например маркер-интерфейс Serializable в Java.

Минус в том, что приходится писать код несколько раз. Пример - есть Класс CLoadable и CDrawable. Наследуясь от их потомков, мы с помощью 3-х строчек получаем класс, который может себя загружать и рисовать, если в обоих родителях есть необходимый функционал. Реализуя ILoadable и IDrawable, мы вынуждены писать код снова, при наличии CLoadable и CDrawable, либо использовать включение и писать обертки. Вы можете сказать конечно, что это надо архитектора бить такого, и я даже возможно с вами соглашусь, но вот если я использую стороннюю SuperMegaLoadLib и SuperMegaDrawLib - то выбора у меня особого нет. А писать самому я все эти либы по понятным причинам не смогу.

Одновременно конечно, мы получаем и геморрой, если у обоих классов CLoadable и CDrawable есть функция SuperMegaDrawFunction(). Тогда ее реализовывать надо по любому. Но это ведь в обоих случаях есть...

Сообщение отредактировал Zulkar: 17.10.2008, 18:41:38

[Visual1]

Согласен, конечно, интерфейсы - не всегда лучшее решение. Но есть случаи, когда никакой другой возможности просто не существует, и ничего не остается, как использовать интерфейсы. Например, в .NET все значимые типы наследуют типу System.ValueType. Поэтому никакие значимые типы не могут наследовать произвольному базовому классу. Казалось бы, а зачем вообще значимым типам нужны интерфейсы? Кому может придти в голову такая дурь, прикручивать интерфейс к какому-нибудь int? Однако в .NET устроено так, что широко используемая struct - это значимый тип (в отличие от C++). Дальше уже есть над чем подумать - то ли оставлять struct (для которой интерфейсы - единственное решение), то ли переделать ее в class.

Сообщение отредактировал Visual1: 17.10.2008, 22:45:30

[Я Легенда]

Ну вот! Ведь така тема интересная была! Пащему абсуждать перестали?
Шо вы думаете по поводу высказываний моей бабули?
Мож она мини обманываит...

[Нурлан Каздаев]

Где можно взять/купить дистрибутив .NET с MSDN. Сколько должно быть дисков? 3,5,7 - слышал разные мнения на этот счет.

["0x0000"]

nur51-если что,можно юзать msdn.com. Разницы вроде как нет. вышел пре релиз жотнет 4 и визуал студио 210
http://www.microsoft...;DisplayLang=en