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

← →
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]

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

> > 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: интересно, запятая перед вторым и нужна?
"Я взял нож и ведро и пошел за грибами". Похоже, что нет.

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

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

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

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

в качестве call back

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

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

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

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