переход с дельфи на сишарп

← →
antonn © (2011-08-11 22:11) [0]

Чего можно почитать для "чайников" для быстрого и безболезненного перехода с дельфи на Сишарп (дотнет2.0 необходиим, 3 и выше как получится)? чтобы было с аналогиями "в дельфи вот так, а в шарпе почти тоже самое вот так", и на русском.

← →
Игорь Шевченко © (2011-08-11 22:44) [1]

Троелсена можно почитать.

http://www.rsdn.ru/res/book/net/troelsen2.xml
http://www.rsdn.ru/forum/dotnet/2138764.flat.aspx#2138764

← →
DVM © (2011-08-11 22:48) [2]

> antonn ©

> чтобы было с аналогиями "в дельфи вот так, а в шарпе почти
> тоже самое вот так"

ты и сам увидишь что многое похоже.

Эндрю Троелсона можешь почитать. Это основы.
У Петзольда еще есть пара книг одна по WinForms другая по WPF.
Но книги книгами, там фреймворк мама не горюй с миллионом классов, на его освоение больше всего времени уйдет.

← →
antonn © (2011-08-11 22:53) [3]

спасибо, сегодня открыл студию, вроде знакомо местами, но после автокомплита увидал длиннющий список всяких классов/типов у которых еще такие же списки, и как-то желание изучения методом тыка отпало :)

да еще эти дженерики, не разбирался с дельфовскими (дельфи7 потому как), и сейчас жалею, время придется потратить, а так наверное бы пригодилось

← →
Игорь Шевченко © (2011-08-11 23:03) [4]

Как бы и то и то обертки вокруг программирования в Windows, только буквы разные, поэтому не так страшен черт. Я читал двухтомник Петцольда по .Net 1, для самого начала вполне неплохая книга, читал Рихтера (по .Net 1.1 вроде), читал Троелсена и еще какую-то книгу по толщине сравнимую с Троелсеном, но другого цвета и других авторов (много их там). Вроде как у Троелсена и Рихтера более или менее складно написано.

← →
Медвежонок Пятачок © (2011-08-11 23:08) [5]

после автокомплита увидал длиннющий список всяких классов/типов у которых еще такие же списки

так это же наоборт рулез форева.
вместо рытья документации в поисках значений нужных флагов/констант ты получаешь готовый список членов класса на блюдечке.

там же в дотнете "любая запятая" - член класса. дотнет оопнее даже чем ява.

← →
Плохиш © (2011-08-11 23:12) [6]

> да еще эти дженерики, не разбирался с дельфовскими

Модно-умных слов поменьше пугаться надо, оставь их дебилкам, пусть хвалятся.

← →
antonn © (2011-08-12 00:18) [7]

> Модно-умных слов поменьше пугаться надо, оставь их дебилкам,
> пусть хвалятся.

Мне показали сегодня как их можно применять (в дотнете), получается меньше слов и вроде как местами удобнее :) Смысл в том что придется и чужой код смотреть, потому разобраться придется. А так я и на Д7 писал себе все что нужно, но это для себя и от себя

← →
Eraser © (2011-08-12 01:03) [8]

> [7] antonn © (12.08.11 00:18)

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

← →
Германн © (2011-08-12 01:25) [9]

> antonn © (12.08.11 00:18) [7]

> Смысл в том что придется и чужой код смотреть, потому разобраться
> придется.

А что делать? Назвался груздем - полезай.
Прими мои соболезнования и вперед с песнями.

← →
KSergey © (2011-08-12 09:36) [10]

> Игорь Шевченко © (11.08.11 22:44) [1]

По первой ссылке - "файл не найден" :(

← →
Компромисс (2011-08-12 11:10) [11]

дотнет оопнее даже чем ява.

Извиняюсь за кажущуюся попытку начать holy war, но это не попытка. Просто действительно интересно, как можно быть оопнее, чем java. Запрещены классы не в пакетах?

← →
Медвежонок Пятачок © (2011-08-12 11:20) [12]

очень просто как.
в яве есть глобальные переменные? есть.
в дотнете нету.
я же говорю, что буквально "любая запятая" - член класса.

← →
Компромисс (2011-08-12 11:40) [13]

в яве есть глобальные переменные? есть.

Нет, глобальных переменных в java нет. В java любой код (и объявление static/instance переменной в том числе) должно быть внутри класса.

Получается, дотнет не оопнее? Или есть еще что-то?

← →
Компромисс (2011-08-12 11:41) [14]

я же говорю, что буквально "любая запятая" - член класса.

Это верно и для java, кстати.

← →
Kerk © (2011-08-12 11:45) [15]

Вы так спорите об оппности, будто это что-то хорошее :)

← →
Медвежонок Пятачок © (2011-08-12 11:47) [16]

Это верно и для java, кстати.

неверно.

← →
Компромисс (2011-08-12 11:54) [17]

Медвежонок Пятачок © (12.08.11 11:47) [16]

> неверно.

Без примера в это трудно поверить.

Kerk © (12.08.11 11:45) [15]

> Вы так спорите об оппности, будто это что-то хорошее :)

Меня заинтересовало, как можно теоретически улучшить оопность явы. Этот мой интерес уж точно неплох :)

← →
Игорь Шевченко © (2011-08-12 12:05) [18]

KSergey © (12.08.11 09:36) [10]

Чудные дела. Вчера был найден, сегодня не найден.

← →
palva © (2011-08-12 12:24) [19]

> Чудные дела. Вчера был найден, сегодня не найден.

Вот здесь есть. Только медленно отдает. 65 Mb
http://gen.lib.rus.ec/book/index.php?md5=2B2F831AAFFE9FF43BD0816DF5A97C1E

← →
DiamondShark © (2011-08-12 12:45) [20]

> как можно теоретически улучшить оопность явы.

Вестимо, применив оопэнларджер. Тогда оопность растёт и можно помериться оопностью.

Навскидку, что у сишарпа оопнее явы:

1. Проперти, в том числе виртуальные и статические.
2. Делегаты.

← →
Компромисс (2011-08-12 12:51) [21]

DiamondShark © (12.08.11 12:45) [20]

> 1. Проперти, в том числе виртуальные и статические.

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

> 2. Делегаты.

Это указатели на методы с указанной сигнатурой? В java вместо них используются интерфейсы с одним методом, что является более оопным. Делегаты не являются оопными. Возможно, я ошибаюсь, с делегатами не особо знаком.

← →
Kerk © (2011-08-12 12:56) [22]

> Компромисс (12.08.11 12:51) [21]
> Есть мнение (и не только мое), что клиент должен знать,
> обращается он к полю или методу. Например, чтобы закэшировать
> результат вызова метода в локальнойц переменной.

А есть мнение, что класс должен инкапсулировать детали реализации :)

← →
Kerk © (2011-08-12 13:00) [23]

Причем ничто не мешает использовать функции в некоторых случаях, даже имея проперти.

← →
Компромисс (2011-08-12 13:01) [24]

А есть мнение, что класс должен инкапсулировать детали реализации :)

Это не детали реализации. Есть "изменяемые свойства" (методы) и "неизменяемые свойства" (поля).
То есть многократное обращение в полю (как на запись, так и на чтение) гарантированно не имеет смысла, а к методу - может иметь смысл (имеет или нет определяется реализацией). То есть отличие семантическое.

← →
Kerk © (2011-08-12 13:03) [25]

Плюс еще момент. Сегодня у тебя есть поле, а через неделю понадобилось добавить set-функцию. И все, вешайся.

← →
Компромисс (2011-08-12 13:06) [26]

Причем ничто не мешает использовать функции в некоторых случаях, даже имея проперти.

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

← →
Компромисс (2011-08-12 13:07) [27]

> Плюс еще момент. Сегодня у тебя есть поле, а через неделю
> понадобилось добавить set-функцию. И все, вешайся.

То есть имеем упрощение разработки за счет ухудшения качества кода (клиент может использовать ненужные локальные переменные для кэширования, либо, наоборот, не использовать нужные)

← →
Kerk © (2011-08-12 13:10) [28]

> Компромисс (12.08.11 13:07) [27]

Нет, мы имеем скрытие от клиента деталей реализации. Один из столпов ООП.

← →
oxffff © (2011-08-12 13:12) [29]

> > 2. Делегаты.
>
>
> Это указатели на методы с указанной сигнатурой?

Это не указатели. Это объекты с указателями.

← →
65535 (2011-08-12 13:14) [30]

Read
http://www.scribd.com/doc/6256795/Comparison-Between-CLR-and-JVM

← →
Компромисс (2011-08-12 13:17) [31]

> Нет, мы имеем скрытие от клиента деталей реализации. Один
> из столпов ООП.

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

← →
Компромисс (2011-08-12 13:23) [32]

oxffff © (12.08.11 13:12) [29]
65535 (12.08.11 13:14) [30]

Я не смог найти отличие от передачи в функцию интерфейса. Кроме того, что делегат может ссылаться на static метод. Вот это плюс дотнету. Хотя никто не мешает на яве использовать шаблон делегат, который будет как раз вызывать статик метод. То есть delegate можно рассматривать как прямую поддержку шаблона делегат на уровне языка.

← →
Компромисс (2011-08-12 13:25) [33]

То есть delegate можно рассматривать как прямую поддержку шаблона делегат на уровне языка.

И если тут я прав, то становится очевидным один из способов повышения оопности явы: надо делать зарезервированными слова delegate, proxy, factory и т.д., и понемногу начинать их использовать на уровне языка.

← →
Компромисс (2011-08-12 13:28) [34]

> надо делать зарезервированными слова delegate, proxy, factory
> и т.д., и понемногу начинать их использовать на уровне языка.
>

Offtop: интересно, запятая перед вторым и нужна?
"Я взял нож и ведро и пошел за грибами". Похоже, что нет.

← →
oxffff © (2011-08-12 13:30) [35]

> Компромисс (12.08.11 13:23) [32]

Неудобства(некоторые сложности) интерфейсов Java описаны
Google в помощь.

← →
65535 (2011-08-12 13:31) [36]

> интерфейсов Java описаны

в качестве call back

← →
Игорь Шевченко © (2011-08-12 13:36) [37]

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

:)

← →
Компромисс (2011-08-12 13:38) [38]

Неудобства(некоторые сложности) интерфейсов Java описаны
Google в помощь.

Можно пнуть меня в нужном направлении?

Нашел несколько disadvantages на разных сайта, но все они от кривых рук.
1.Interface has much less restriction than class in the view of inheritance, so someone may abuse interface (i.e. making too much interface and implementing them).
Sometimes, people place static members into an interface and inherit from it looking for avoiding prefixing static members with class names.
2.Java interfaces are slower and more limited than other ones.
3.Interface should be used multiple number of times else there is hardly any use of having them.

← →
Компромисс (2011-08-12 13:41) [39]

65535 (12.08.11 13:31) [36]

Если delegate являются closure, то согласен.

← →
Inovet © (2011-08-12 13:43) [40]

> [34] Компромисс (12.08.11 13:28)
> интересно, запятая перед вторым и нужна?

Нет перечисление "нож и ведро" и "взял и пошёл" разные члены предложения. Забыл я как они называются или не знал.

← →
Компромисс (2011-08-12 13:47) [41]

Игорь Шевченко © (12.08.11 13:36) [37]
Спасибо, но я это читал в прошлый раз, когда Вы запостили :)

Судя по
http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java#Delegates_.2F_method_references
делегат из дотнета можно представить в яве как wrapper pattern.

← →
Компромисс (2011-08-12 13:48) [42]

Нашел

A Java Programmer Looks at C# Delegates
http://onjava.com/pub/a/onjava/2003/05/21/delegates.html

← →
Компромисс (2011-08-12 13:49) [43]

← →
Компромисс (2011-08-12 13:53) [44]

When an instance of a delegate is constructed, the actions the compiler takes are similar to the Java equivalent of building a wrapper class. This wrapper class exposes the interface defined by the declaration of the delegate, implementing the interface by calling the method that was passed to the delegate constructor.

http://onjava.com/pub/a/onjava/2003/05/21/delegates.html

ЧТД. Поддержка шаблонов проектирования на уровне компилятора.

← →
65535 (2011-08-12 14:25) [45]

> Компромисс (12.08.11 13:41) [39]
> 65535 (12.08.11 13:31) [36]
>
> Если delegate являются closure, то согласен.

Делегаты не являются замыканиями. Делегат это объект ссылки(ссылок) на instance методы(которые могут являться замыканиями) или static методы.

← →
Компромисс (2011-08-12 14:33) [46]

65535 (12.08.11 14:25) [45]

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

← →
65535 (2011-08-12 14:33) [47]

> Компромисс (12.08.11 13:38) [38]
> Неудобства(некоторые сложности) интерфейсов Java описаны
> Google в помощь.
>
> Можно пнуть меня в нужном направлении?

http://www.informit.com/articles/article.aspx?p=332881

One key difference between delegates and interfaces is that you can create a delegate to any method with the right prototype.

In other words, callback code that takes delegate parameters can be a bit easier to use than callback code that takes interface parameters. You can create a delegate to any (reference or value type) object which has a method of the right signature. If you want to get an interface reference to an object which does have a method of the right signature but which doesn"t explicitly support the right interface, you do have to create a subclass (like the Implementor class) which implements the interface with inherited methods.

← →
65535 (2011-08-12 14:38) [48]

> 65535 (12.08.11 14:33) [47]

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

← →
Компромисс (2011-08-12 14:50) [49]

65535 (12.08.11 14:33) [47]
65535 (12.08.11 14:38) [48]

Я уже понял, спасибо.

ЗЫ. Java-девелоперы с самого начала продумывают архитектуру, а дотнетчики сперва разные методы в разных классах пишут, а потом понимают, что это должен был быть один и тот же интерфейс. Шутка ) От языка это вряд ли зависит. Я помню, как я вынужден был объяснять ява-коллегам, почему у меня несколько классов имплементировали довольно много интерфейсов, каждый из которых состоял ровно из одного метода.

← →
antonn (work) (2011-08-12 21:04) [50]

ужас, мне предстоит изучить что-то чтобы понять о чем вы разговариваете... :/

Удалено модератором

Довольно интересный ресурс о C# - это блог разработчика этого языка Эрика Липперта.
http://blogs.msdn.com/b/ruericlippert/

переход с дельфи на сишарп Найти похожие ветки