чего нет в java что есть в c

Крадущийся тигр, затаившийся дракон

Java vs. C#… Что может быть лучше вечного спора? Нет, данная статья не посвящена очередному бенчмарку, и даже не является holy war, не стоит даже вопрос: «кто круче».

Для каждой задачи существует свой инструмент. Сравнивать C# и Ruby, например, не имеет смысла, т.к. их целевое предназначение совершенно разное, да и природа также. Однако именно C# и Java являются наиболее близкими по своей философии.

Очень часто коллеги, пишущие на Java, даже не подозревают о многих (. ) вещах, которые предоставляет (или, наоборот не предоставляет) C#.

Если Вам интересно посмотреть на C# и Java без субъективизма, а также узнать внутреннее устройство той или иной возможности, тогда вперед.

▌ Немного истории

Язык C# появился в 2001 году, а его разработка была начата еще в 1999 гг. Тогда он был весьма схож с Java 1.4. Однако современный C#, которого мы знаем, следует начинать рассматривать с версии 2.0 (что соответствует времени выхода Java 5).

Бытует мнение, что C# многое заимствует из Java. Однако я категорически не согласен с этим. По-моему мнению, C# во многом является C «с объектами», или же C++ «с человеческим лицом».

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

Сначала мы посмотрим на возможности самих JVM и CLR (Common Language Runtime), далее уже рассмотрим синтаксический сахар C#.

▌ Эпизод I: Bytecode

CIL (Common Intermediate Language, он же MSIL, он же просто IL) – является байт-кодом с полиморфными (обобщенными) инструкциями.

Так, если в Java используется отдельная инструкция для каждого типа операций с различными типами (например: fadd – сложение 2-х float, iadd – сложение 2-х integer), то в CIL для каждого вида операций существует лишь одна инструкция с полиморфными параметрами (например, существует только одна инструкция – add, производящая сложение и float, и integer). Вопрос решения генерации соответствующих x86-инструкций ложится на JIT.

Количество инструкций у обеих платформ примерно одинаковое. Сравнивая список команд байт-кода Java и CIL, видно, что 206 у Java, и 232 — CIL, однако не забываем, что у Java многие команды просто повторяют функционал друг друга.

▌ Эпизод III: Generics (parameterized types || parametric polymorphism)

Как известно, в Java используется механизм type erasure, т.е. поддержка generics обеспечивается лишь компилятором, но не рантаймом, и после компиляции информация о самом типе не будет доступна.

При этом вместо обобщенного типа T создается экземпляр объекта типа java.lang.Object.

Будет преобразован к виду:

Таким образом, вся политика безопасности типов разрушается моментально.

.NET, наоборот, имеет полную поддержку generics как compile-time, так и run-time.

▌ Эпизод IV: Types

Java является полностью ОО-языком. С этим можно поспорить. И вот почему: примитивные типы (integer, float и т.п.) не наследуются от java.lang.Object. Поэтому generics в Java не поддерживают primitive types.

А ведь в по-настоящему ОО-языке everything is object.

Это не единственное ограничение. Также невозможно создать собственные примитивные типы.

C# позволяет это делать. Имя этим структурам – struct.

Также generics в C# позволяют использовать value types (int, float и т.д.)

Если в Java необходимо писать так:

C# позволяет использование примитивных типов.

Итак, value type – аналог primitive type из Java. Однако наследуется от System.Object, живет не в куче, а в стеке (а теперь оговорка: расположение value type зависит от его жизненного цикла, например, при участии в замыкании автоматически происходит boxing).

Reference type – представляет собой то же самое, что и reference types в Java.

Очень похоже на C++ код, не так ли?

▌ Эпизод V: Возможности C#

Будет преобразовано к виду:

Делегаты являются аналогами указателей на методы в C/C++. Однако являются типобезопасными. Их главное предназначение – callback функции, а также работа с событиями.

Данный подход коренным образом отличается от проекта Da Vinci для Java, т.к. в последнем пытаются расширить саму VM.

Рассмотрим пример на C#:

Итак, что же мы видим? Если на C мы можем передать указатель на функцию с другими типами параметров (скажем float arg1, float arg2), то в C# — это невозможно. В C# делегаты проходят не только проверку сигнатуры и типов на этапе компиляции, но и в рантайме.

События необходимы для реализации событийно-ориентированного программирования. Конечно, можно обойтись и EventDispatcher’ом, или паттерном Publisher/Subscriber. Однако нативная поддержка со стороны языка дает весомые преимущества. Одним из которых является типобезопасность.

Анонимные методы существенно упрощают жизнь – структура класса остается чистой, т.е. не нужно создавать отдельные лишние методы в самом классе.

Изменим вышеприведенный пример с бинарными операциями с использованием анонимных методов:

Не правда ли более коротко и чисто?

Рассмотрим теперь лямбда-выражения.

Лямбда-выражение — это анонимная функция, которая содержит выражения и операторы, а также может использоваться для создания делегатов или дерева выражений.

А как же будет выглядеть пример с событиями? Очень просто:

Что ж, мы сократили код еще больше и уже это становится похожим на функциональный стиль (. ). Да, C# является также и функциональным языком, т.к. функции являются объектами первого класса.

Лямбда-выражения, а вместе с ними и деревья выражений были созданы вместе с LINQ (Language Integrated Query).

Все еще не знакомы с LINQ? Хотите увидеть как будет выглядеть знаменитый MapReduce на LINQ?

Или же использовать SQL-подобный синтаксис:

В этом примере мы видим и LINQ (GroupBy().Select().Where() и т.д.), и анонимные классы –

Хм…что же еще здесь используется? Ответ прост – мощная система вывода типов.

Главную роль здесь играет ключевое слово var. C++ 11 имеет аналогичную конструкцию auto.

Так без вывода типов нам пришлось бы писать так:

[Данный метод сгенерировал за нас компилятор]

Для описания всех остальных возможностей C#, настроек его компилятора и т.п. необходимо посвятить еще не одну статью.

А между тем, C# 5 – который уже доступен и скоро будет его официальный релиз, добавляет асинхронное программирование, появившееся также и в C++ 11!

▌ Заключение

C# и Java являются мощными языками, а также мощными платформами (.NET и Java). Как я уже писал в начале статьи — для каждой задачи существует свой инструмент.

C# — не является продолжением или копирующим Java. Даже когда он разрабатывался в Microsoft, его кодовое название было COOL (C-like Object Oriented Language). Сколько раз в данной статье приводилась аналогия с C/C++? Достаточное количество.

Надеюсь, что моя статья помогла решить (хотя бы немного) вопрос разности и языков, и платформ.

Источник

Что есть в Java, чего нет в C#? [закрыт]

Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы он был сосредоточен только на одной проблеме.

Так вот сам вопрос: а что есть в Java, чего нет в C#? Именно из синтаксиса, различных удобностей и синтаксического сахара.

5 ответов 5

В основном по фичам в данный момент C# идёт впереди Java, Java находится в позиции догоняющего. Однако есть несколько фич, которые есть в Java и нет в C# и которые при правильном использовании могут облегчить жизнь программисту.

1) Легковесные (анонимные) производные классы.

В C# надо было бы объявить производный класс явно. Аналогичная, но не равносильная фича C# — анонимные методы, то есть лямбды.

2) Нестатические внутренние классы. В C# внутренние классы лишь логически находятся «внутри» и не имеют доступа к instance-переменным. В Java внутренние классы более богаты.

3) enum ‘ы. В C# они такие же, как в C++, и являются по существу именованными константами целочисленного типа. В Java enum ‘ы есть константы объектного типа, гораздо более богатые семантически.

4) checked exceptions. Вы можете объявлять как часть сигнатуры метода исключения, которые бросаются этим методом. В C# такой возможности нету. (Хотя разработчики C# считают, что эта фича не нужна и даже вредна, тем не менее по факту это фича, которая есть в Java и нет в C#.)

6) SoftReference представляет собой «более сильную» версию WeakReference (которые тоже есть в Java): объекты, референсируемые ими, не удаляются, пока памяти хватает, даже если другие объекты уничтожаются в процессе сборки мусора.

7) У Java есть симпатичные помеченные блоки, которые позволяют выйти из любого количества циклов за раз ( break ) или пропустить итерацию во внешнем цикле ( continue ). Также break ; может выйти из любого блока, не только цикла (что делает его равносильным goto ).

С выходом новой версии Java 8 добавилось ещё одно расхождение:

9) У Java есть очень полезная фича: default interface implementation, с помощью которой можно устраивать подобие mixin’ов: написать код, который можно добавить к любому классу, с возможностью перегрузки.

У C# похожее поведение можно смоделировать при помощи extension-методов (которых в Java как раз нет) и маркерных интерфейсов, но вы не сможете полиморфно перегрузить метод в конкретном классе, только перекрыть. В результате если у вас есть указатель на базовый класс, вызов в случае C# приведёт к вызову метода для базового класса.

Вот теперь ведь никто мимо не пройдёт.

Да, linq нет, но для работы с коллекциями можно библиотечку подыскать вроде Google Guava, если в самом деле так нужно. Для работы с результатами запросов из бд тоже можно решить проблему. На мой взгляд, решения делать через синтаксис языка лучше, чем liq, который работает примерно так: парсим один синтаксис, получаем другой, другой исполняем.

Вкратце

C# сильнее как язык: в Java нет практически ничего, чего нет в C#. Как язык, Java отстал от времени и находится в роли догоняющего. Новые возможности натыкаются на несметное число проблем, унаследованных из-за обратной совместимости. Одна из критических проблем — type erasure.

Java сильнее как платформа: для C# нет такого количества библиотек, как для Java. Java гораздо популярнее в опен-сорсе. Разрабатывая более-менее популярные вещи, вы никогда не заметите разницу, но если закапываться в экзотику, то разница весьма ощутима.

Раньше C# был относительно закрытым проектом, теперь он со всех сторон открытый, однако поезд ушёл, поэтому разрыв в размере опенсорсного сообщества не сократится никогда. В свою очередь Java как язык тоже уже ничто не может спасти, ибо обратная совместимость — святая корова.

Если перед вами стоит выбор «C# или Java», то всё просто:

Про фичи

Достаточно поглядеть Comparison of C# and Java, чтобы понять пропасть между языками. Не верьте тем, кто говорит, что Джава сильна минимализмом — они врут (или просто привыкли писать огромные конструкции, когда достаточно одной строчки).

Приведённые в первом посте фичи — это или обман, или незнание, или манипуляция.

Полный список важных фич, которые отсутствуют в C#, но есть в Java:

В общем-то, всё. Если же перечислять то, что есть в C#, но нет в Java, то список получится непомерно длинным.

Разумеется, даже в условиях серьёзного отставания джавы джависты не хотят предавать платформу. Определённое распространение получили альтернативные языки на JVM, например, Kotlin и Scala. В чём-то они мощнее C#, но по популярности они сильно уступают обоим языкам, и у них свои проблемы. У Kotlin наиболее серьёзные шансы, потому что он получил официальную поддержку от Google на Android.

По популярности в энтерпрайзе языки примерно на одном уровне. Детали зависят от области разработки и страны проживания.

Если вы хотите получать удовольствие от программирования, выбирайте C#. Если для вас критичен более широкий выбор редких библиотек, то выбирайте Java, но по возможности переходите на Kotlin. Если же вы хотите покопаться во всём, то морально готовьтесь к тому, что вам ну никак не обойти ещё несколько языков типа JavaScript (весь веб до сих пор на нём, не имеет отношения к Java), Python (один из самых популярных языков для связки инструментария) и прочих.

Источник

Личный опыт: переход с низкоуровневой разработки на C к программированию на Java

Статья отражает личный опыт автора – заядлого программиста микроконтроллеров, которому после многолетнего опыта микроконтроллерной разработки на языке С (и немного на С++) довелось участвовать в крупном Java-проекте по разработке ПО для ТВ-приставок под управлением Android. В ходе этого проекта удалось собрать заметки об интересных различиях языков Java и C/C++, оценить разные подходы к написанию программ. Статья не претендует на роль справочника, в ней не рассматривается эффективность и производительность Java-программ. Это скорее сборник личных наблюдений. Если не указано иное, то речь идет о версии Java SE 7.

Различия в синтаксисе и управляющие конструкции

Если говорить кратко – различия минимальные, синтаксис очень похож. Блоки кода также формируются парой фигурных скобок <>. Правила составления идентификаторов – такие же, как и для языка C/С++. Список ключевых слов почти такой же, как в языке C/С++. Встроенные типы данных – подобны таковым в C/С++. Массивы – все также объявляются с помощью квадратных скобок.

Управляющие конструкции if-else, while, do-while, for, switch тоже почти полностью идентичные. Примечательно, что в Java остались знакомые C-программистам метки (те, которые используются с ключевым словом goto и применение которых категорически не рекомендуется). Однако из Java исключили возможность перехода на метку с помощью goto. Метки следует использовать только для выхода из вложенных циклов:

Для улучшения читаемости программ в Java добавлена интересная возможность разделять разряды длинных чисел символом подчеркивания:

Внешне программа на Java не сильно отличается от программы на знакомом C. Главное визуальное отличие – Java не допускает «свободно» расположенных в исходном файле функций, переменных, определений новых типов (структур), констант и прочего. Java – объектно-ориентированный язык, поэтому все программные сущности должны принадлежать какому-либо классу. Еще одно значительное отличие – отсутствие препроцессора. Об этих двух различиях подробнее рассказано ниже.

Объектный подход в языке C

Когда мы пишем на языке C большие программы, по сути нам приходится работать с объектами. Роль объекта здесь выполняет структура, которая описывает некую сущность «реального мира»:

Также в C есть методы обработки «объектов»-структур – функции. Однако функции по сути не объединены с данными. Да, их обычно помещают в один файл, но в «типовую» функцию каждый раз необходимо передавать указатель на обрабатываемый объект:

Пользоваться «объектом» можно только после выделения памяти для его хранения:

В программе на C обычно определяют функцию, которая отвечает за начальную инициализацию «объекта» перед первым его использованием:

Тогда жизненный цикл «объекта» в C обычно такой:

Теперь перечислим возможные ошибки времени выполнения, которые могут быть допущены программистом в жизненном цикле «объекта»:

Объектный подход Java

Сталкиваясь с ООП – объектно-ориентированным программированием, вы наверняка слышали об одном из китов ООП – инкапсуляции. В Java, в отличие от C, данные и методы их обработки объединены вместе и представляют собой «истинные» объекты. В терминах ООП это называют инкапсуляцией. Класс – это описание объекта, ближайший аналог класса в C – определение нового типа с помощью typedef struct. В терминах Java те функции, которые принадлежат классу, называют методами.

В основе идеологии языка Java лежит утверждение «все есть объект». Поэтому не удивительно, что Java запрещает создавать как методы (функции), так и поля данных (переменные) отдельно от класса. Даже привычный метод main(), с которого начинается выполнение программы, должен принадлежать одному из классов.

Описание класса в Java – это аналог объявления структуры в C. Описав класс, вы ничего не создаете в памяти. Объект данного класса появляется в момент своего создания оператором new. Создание объекта в Java – это аналог выделения памяти в языке C, но, в отличие от последнего, во время создания автоматически вызывается специальный метод – конструктор объекта. Конструктор берет на себя роль начальной инициализации объекта – аналог функции init(), рассмотренной ранее. Имя конструктора обязательно должно совпадать с именем класса. Конструктор не может возвращать значение.

Жизненный цикл объекта в программе на Java выглядит следующим образом:

Заметьте, что количество возможных ошибок в программе на Java значительно меньше, чем в программе на C. Да, по-прежнему можно забыть создать объект перед первым использованием (что впрочем приведет к легко отлаживаемому исключению NullPointerException), но то что касается остальных ошибок, присущих программам на C, ситуация коренным образом меняется:

Память и сборщик мусора

В Java сохранены знакомые C/C++-программисту понятия кучи и стека. При создании объекта оператором new память для хранения объекта заимствуется из кучи. Однако ссылка на объект (ссылка – аналог указателя), если созданный объект не входит в состав другого объекта, размещается в стеке. В куче хранятся «тела» объектов, а в стеке – локальные переменные: ссылки на объекты и примитивные типы. Если куча существует на протяжении выполнения программы и доступна для всех потоков программы, то стек относится к методу и существует только во время его выполнения, а также недоступен для других потоков программы.

В Java нет необходимости и даже более того – нельзя вручную освободить память, занимаемую объектом. Эту работу выполняет сборщик мусора в автоматическом режиме. Среда выполнения следит, можно ли из текущего места программы достигнуть каждого объекта в куче, переходя по ссылкам от объекта к объекту. Если нет – то такой объект признается «мусором» и становится кандидатом на удаление.

Важно отметить, что само удаление происходит не в момент, когда объект «перестал быть нужен» – решение об удалении принимает сборщик мусора, и удаление может откладываться сколько угодно, вплоть до момента окончания работы программы.

Разумеется, работа сборщика мусора требует накладных расходов процессорного времени. Но взамен он избавляет программиста от большой головной боли, связанной с необходимостью освобождать память после окончания использования «объектов». Фактически мы «берем» память, когда нам это нужно и пользуемся ей, не думая, что ее надо после себя освобождать.

Говоря о локальных переменных, следует вспомнить подход Java к их инициализации. Если в C/C++ неинициализированная локальная переменная содержит случайное значение, то компилятор Java попросту не позволит оставить ее неинициализированной:

Ссылки – замена указателям

В Java отсутствуют указатели, соответственно у Java-программиста нет возможности совершить одну из множества ошибок, возникающих при работе с указателями. Когда вы создаете объект, вы получаете ссылку на этот объект:

В языке C у программиста был выбор: как передавать, скажем, структуру в функцию. Можно было передавать по значению:

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

Безусловно отсутствие указателей как таковых уменьшает количество возможных ошибок, однако в языке остался аналог нулевого указателя – нулевая ссылка, обозначаемая ключевым словом null.

Нулевая ссылка – это головная боль Java-программиста, т.к. вынуждает перед использованием ссылки на объект либо проверить ее на null, либо обрабатывать исключения NullPointerException. Если этого не делать, то произойдет крах программы.

Итак, все объекты в Java передаются через ссылки. Примитивные же типы данных (int, long, char. ) – передаются по значению (подробнее о примитивах – ниже).

Особенности ссылок в Java

Доступ к любому объекту в программе осуществляется через ссылку – это однозначно положительно сказывается на производительности, но может преподнести сюрприз новичку:

Аргументы методов и возвращаемые значения – все передается через ссылку. Кроме преимуществ в этом кроется недостаток по сравнению с языками C/С++, где мы можем явно запретить функции менять значение, переданное через указатель с помощью квалификатора типа const:

То есть язык C позволяет отследить эту ошибку на этапе компиляции. В Java так же есть ключевое слово const, но оно зарезервировано для будущих версий и сейчас вообще не используется. Его роль в некоторой степени призвано выполнять ключевое слово final. Однако оно не позволяет защитить передаваемый в метод объект от изменений:

Все дело в том, что ключевое слово final в данном случае применяется к ссылке, а не к объекту, на который эта ссылка указывает. Если применить final к примитиву, то компилятор ведет себя так, как и ожидается:

Ссылки Java очень похожи на ссылки языка C++.

Примитивы Java

Каждый объект Java помимо полей данных содержит вспомогательную информацию. Если мы хотим оперировать, например, отдельными байтами и каждый байт представлен объектом, то в случае массива байт накладные расходы памяти могут многократно превысить полезный объем.
Чтобы Java оставалась достаточно эффективной и в случаях, описанных выше, в язык была добавлена поддержка примитивных типов – примитивов.

Все примитивы имеют свои аналоги в языке C. Однако стандарт C не определяет точный размер целочисленных типов, вместо этого фиксируется диапазон значений, которые может хранить данный тип. Зачастую программист хочет обеспечить одинаковую разрядность для разных машин, что приводит к появлению в программе типов наподобие uint32_t, хотя все библиотечные функции как раз таки требуют аргументов типа int.
Этот факт никак нельзя отнести к преимуществам языка.

Целочисленные примитивы в Java, в отличии от C, имеют фиксированную разрядность. Таким образом, можно не заботиться о реальной разрядности машины, на которой выполняется Java-программа, а также о порядке байт («сетевой» или «интеловский»). Этот факт помогает реализовать принцип «написано однажды – выполняется везде».

Кроме этого, в Java все целочисленные примитивы – знаковые (в языке отсутствует ключевое слово unsigned). Это исключает трудности при совместном использовании знаковых и беззнаковых переменных в одном выражении, присущие языку C.

В завершение, порядок байт в многобайтных примитивах в Java фиксированный (младший байт по младшему адресу, Little-endian, обратный порядок).

К недостаткам реализации операций с примитивами в Java можно отнести тот факт, что здесь, как и в программе на C/C++, может произойти переполнение разрядной сетки, причем никаких исключений при этом не возбуждается:

Итак, данные в Java представлены двумя видами сущностей: объектами и примитивами. Примитивы нарушают концепцию «все есть объект», но в некоторых ситуациях слишком эффективны, чтобы их не использовать.

Наследование

Наследование является еще одним китом ООП, о котором вы наверняка слышали. Если ответить кратко на вопрос «зачем наследование вообще нужно», то ответом будет «повторное использование кода».

Допустим, вы программируете на C, и у вас есть хорошо написанный и отлаженный «класс» – структура и функции для ее обработки. Далее возникает необходимость создать подобный «класс», но с расширенной функциональностью, причем базовый «класс» все еще остается нужен. В случае языка C для решения такой задачи у вас есть единственный путь – композиция. Речь идет о создании новой расширенной структуры-»класса», которая должна содержать указатель на базовый «класс»-структуру:

Java как объектно-ориентированный язык позволяет расширять функциональность имеющихся классов с помощью механизма наследования:

Необходимо отметить, что Java ни в коем разе не запрещает использовать композицию как способ расширения функциональности уже написанных классов. Более того, во многих ситуациях композиция оказывается предпочтительнее наследования.

Благодаря наследованию классы в Java выстраиваются в иерархическую структуру, каждый класс обязательно имеет одного и только одного «родителя» и может иметь сколько угодно «детей». В отличие от C++, класс в Java не может наследовать более чем от одного родителя (таким образом решается проблема «ромбовидного наследования»).

При наследовании производный класс получает в свое расположение все public и protected поля и методы своего базового класса, а также базового класса своего базового класса и так далее вверх по иерархии наследования.

На вершине иерархии наследования находится общий прародитель всех Java классов – класс Object, единственный, кто не имеет родителя.

Динамическая идентификация типа

Одним из ключевых моментов языка Java является поддержка динамической идентификации типов (RTTI). Если говорить простыми словами, то RTTI позволяет подставлять объект производного класс там, где требуется ссылка на базовый:

Имея ссылку во время выполнения программы, можно определить истинный тип объекта, на который данная ссылка ссылается – с помощью оператора instanceof:

Переопределение методов

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

В Java, как и в других языках ООП, переопределение (overriding) методов неразрывно связано с наследованием. Производный класс получает доступ к public- и protected-методам базового класса. Кроме того, что он может их вызывать, можно изменить поведение одного из методов базового класса, не меняя при этом его сигнатуру. Для этого достаточно определить в производном классе метод с точно такой же сигнатурой:

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

Полиморфизм

Как инкапсуляция и наследование, третий кит ООП – полиморфизм – также имеет в некотором роде аналог в процедурно-ориентированном языке C.

Допустим у нас есть несколько «классов»-структур, с которыми требуется выполнять однотипное действие, причем функция, выполняющая это действие, должна быть универсальной – должна «уметь» работать с любым «классом» в качестве аргумента. Возможное решение выглядит так:

Решение выглядит громоздко, но цель достигнута – универсальная функция commonFunc() принимает в качестве аргумента «объект» любого «класса». Обязательное условие – «класс»-структура в первом поле должна содержать идентификатор, по которому определяется действительный «класс» объекта. Такое решение возможно благодаря использованию аргумента с типом «void *». Однако такой функции можно передать указатель любого типа, например, «int *». Ошибок компиляции это не вызовет, но во время выполнения программа будет вести себя непредсказуемо.

Теперь рассмотрим, как полиморфизм выглядит в Java (впрочем, как и в любом другом языке ООП). Пусть у нас есть множество классов, которые должны однотипно обрабатываться некоторым методом. В отличие от решения для языка С, представленного выше, этот полиморфный метод ОБЯЗАН входить в состав всех классов данного множества, и все его версии ОБЯЗАНЫ иметь одинаковую сигнатуру.

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

То есть метод executor(), который может быть где угодно в программе, должен «уметь» работать с любым классом из множества (A, B или C). Надо каким-то образом «сказать» компилятору, что _set_of_class_ обозначает наше множество классов. Здесь и пригождается наследование – необходимо сделать все классы из множества производными некоторого базового класса, который будет содержать полиморфный метод:

И теперь ему можно передавать в качестве аргумента любой класс, который является наследником Base (благодаря динамической идентификации типа):

В зависимости от того, объект какого класса передан в качестве аргумента, будет вызван метод, принадлежащий этому классу.

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

Структура проекта на Java

В Java все файлы с исходным кодом имеют расширение *.java. Отсутствуют как заголовочные файлы *.h, так и прототипы функций или классов. Каждый файл с исходным кодом Java должен содержать хотя бы один класс. Имя класса принято записывать, начиная с заглавной буквы.

Чтобы обеспечить уникальность имен пакетов в пределах земного шара предлагается использовать «перевернутое» доменное имя компании. Однако это не является требованием и в локальном проекте можно использовать любые имена.

Рекомендуется также задавать имена пакетов в нижнем регистре. Так их можно легко отличить от имен классов.

Сокрытие реализации

Еще один аспект инкапсуляции – разделение интерфейса и реализации. Если интерфейс доступен для внешних частей программы (внешних по отношению к модулю или классу), то реализация скрыта. В литературе часто проводят аналогию с черным ящиком, когда снаружи «не видна» внутренняя реализация, но «видно» то, что подается на вход ящика и что он выдает на выходе.

В языке C сокрытие реализации выполняют внутри модуля, помечая функции, которые не должны быть видны извне, ключевым словом static. Прототипы функций, которые составляют интерфейс модуля, выносятся в заголовочный файл. Под модулем в языке C понимается пара: файл с исходным кодом с расширением *.c и заголовочный с расширением *.h.

В Java также есть ключевое слово static, но оно не влияет на «видимость» метода или поля извне. Для управления «видимостью» предназначены 3 модификатора доступа: private, protected, public.

Поля и методы класса, помеченные как private, доступны только внутри его самого. Поля и методы protected доступны также наследникам класса. Модификатор public означает, что помеченный элемент доступен извне класса, то есть является частью интерфейса. Также возможно отсутствие модификатора, в этом случае доступ к элементу класса ограничен пакетом, в котором данный класс находится.

Рекомендуют в процессе написания класса изначально помечать все поля класса как private и расширять права доступа по мере возникновения необходимости.

Перегрузка методов

Одной из раздражающих черт стандартной библиотеки C является наличие целого зоопарка функций, выполняющих по сути одно и тоже, но различающихся типом аргумента, например: fabs(), fabsf(), fabsl() – функции для получения абсолютного значения для double, float и long double типов соответственно.

Java (а также С++) поддерживает механизм перегрузки методов – внутри класса может быть несколько методов с полностью идентичным именем, но различающихся между собой типом и количеством аргументов. По количеству аргументов и их типу компилятор сам выберет нужную версию метода – очень удобно и улучшает читаемость программы.

В Java в отличии от C++ нельзя перегружать операторы. Исключение составляют операторы «+» и «+=», которые изначально перегружены для строк String.

Символы и строки в Java

В языке C приходится работать с нуль-терминальными строками, представленными указателями на первый символ:

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

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

В Java примитивный тип char (а также «обертка» Character, об «обертках» – ниже) представляют один символ согласно стандарту Unicode. Используется кодировка UTF-16, соответственно один символ занимает в памяти 2 байта, что позволяет закодировать практически все символы используемых в настоящее время языков.

Символы можно задавать по их Unicode:

Если Unicode символа превышает максимальный 216 для типа char, то такой символ должен быть представлен типом int. В строке же он будет занимать 2 символа по 16 бит, но опять-таки символы с кодом, превышающем 216, используются крайне редко.

Строки Java реализованы встроенным классом String и хранят 16-битные символы char. В классе String собрано все или почти все, что может потребоваться для работы со строками. Здесь не надо думать о том, что строка должна обязательно заканчиваться нулем, здесь невозможно незаметно «затереть» этот нулевой завершающий символ или обратиться к памяти за пределы строки. И вообще, работая со строками в Java, программист не задумывается о том, в каком виде строка хранится в памяти.

Как говорилось выше, Java не допускает перегрузки операторов (как в С++), однако класс String является исключением – только для него изначально перегружены операторы слияния строк «+» и «+=».

Примечательно, что строки в Java неизменны – будучи один раз созданы, они не допускают своего изменения. Когда мы пытаемся поменять строку, например, так:

Tо исходная строка на самом деле не меняется. Вместо этого создается измененная копия исходной строки, которая в свою очередь так же является неизменной:

Таким образом каждое изменение строки в реальности оборачивается созданием нового объекта (на самом деле в случаях слияния строк компилятор может оптимизировать код и использовать класс StringBuilder, о котором будет рассказано позже).

Бывает, что в программе необходимо часто изменять одну и ту же строку. В таких случаях в целях оптимизации быстродействия программы и потребления памяти можно предотвратить создание новых объектов-строк. Для этих целей следует использовать класс StringBuilder:

Отдельно стоит сказать о сравнении строк. Типичная ошибка начинающего Java-программиста, это сравнение строк с помощью оператора «==»:

Такой код формально не содержит ошибок на стадии компиляции или ошибок времени выполнения, но работает он иначе, чем это можно было бы ожидать. Так как все объекты и строки, в том числе в Java, представлены ссылками, то сравнение оператором «==» дает сравнение ссылок, а не значений объектов. То есть результат будет true только если 2 ссылки действительно ссылаются на одну и ту же строку. Если же строки – разные объекты в памяти, и необходимо сравнить их содержимое, то надо использовать метод equals():

Самое удивительное, что в некоторых случаях сравнение с помощью оператора «==» работает правильно:

Так происходит из-за того, что в действительности ссылки someString и anotherString указывают на один и тот же объект в памяти. Компилятор помещает одинаковые строковые литералы в пул строк – происходит так называемое интернирование. Тогда каждый раз, когда в программе появляется такой же строковый литерал, используется ссылка на строку из пула. Интернирование строк как раз-таки и возможно благодаря свойству неизменности строк.

Хотя сравнение содержимого строк допускается только методом equals(), в Java есть возможность корректно использовать строки в switch-case конструкциях (начиная с версии Java 7):

Любопытно, что любой объект Java можно преобразовать в строку. Соответствующий метод toString() определен в базовом для всех классов классе Object.

Подход к обработке ошибок

Программируя на C, вы могли встречать следующий подход к обработке ошибок. Каждая функция какой-либо библиотеки возвращает тип int. Если функция выполнена успешно, то этот результат равен 0. Если же результат отличен от нуля – это свидетельствует об ошибке. Чаще всего код ошибки передают через возвращаемое функцией значение. Так как функция может вернуть лишь одно значение, и оно уже занято кодом ошибки, то действительный результат функции приходится возвращать через аргумент в виде указателя, например, так:

Кстати, это один из случаев, когда в программе на C возникает необходимость в использовании указателя на указатель.

Иногда используют другой подход. Функция возвращает не код ошибки, а непосредственно результат своего выполнения, обычно в виде указателя. Ошибочная ситуация индицируется при этом нулевым указателем. Тогда библиотека обычно содержит отдельную функцию, которая возвращает код последней ошибки:

Так или иначе, при программировании на C код, выполняющий «полезную» работу, и код, отвечающий за обработку ошибок, перемежает друг друга, что явно не делает программу легко читаемой.

В Java при желании можно использовать подходы, описанные выше, однако здесь можно применить совершенно иной способ работы с ошибками – обработка исключений (впрочем, как и в C++). Преимущество обработки исключений состоит в том, что в этом случае «полезный» код и код, отвечающий за обработку ошибок и нештатных ситуаций, логически отделены друг от друга.

Достигается это с помощью конструкций try-catch: в секции try размещается «полезный» код, а в секции catch – код обработки ошибок.

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

Теперь вызов данного метода должен обязательно быть обрамлен в блок try-catch, или вызывающий метод также должен быть помечен, что он может вызывать это исключение.

Отсутствие препроцессора

Как бы ни был удобен знакомый C/C++-программистам препроцессор, в языке Java он отсутствует. Разработчики Java вероятно решили, что он используется только для обеспечения переносимости программ, а так как Java выполняется везде (почти) то и препроцессор в ней не нужен.

Компенсировать отсутствие препроцессора можно использованием статического поля-флага и проверять его значение в программе, где это необходимо.

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

Массив – это тоже объект

При работе с массивами на C, выход индекса за границы массива представляет собой очень коварную ошибку. Компилятор ни коем образом не сообщит о ней, а во время выполнения программа не будет остановлена с соответствующим сообщением:

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

В языке Java программист защищен от подобного рода труднодиагностируемых ошибок. При попытке выйти за границы массива возбуждается исключение ArrayIndexOutOfBoundsException. Если не был запрограммирован перехват исключения с помощью конструкции try-catch, программа аварийно завершается, а в стандартный поток ошибок отправляется соответствующее сообщение с указанием файла с исходным кодом и номера строки, где произошел выход за границы массива. То есть диагностика подобных ошибок становится тривиальным делом.

Такое поведение Java-программы стало возможным благодаря тому, что массив в Java представлен объектом. Массив Java не может менять размер, его размер жестко задается в момент выделения памяти. Во время выполнения же получить размер массива проще простого:

Если говорить о многомерных массивах, то по сравнению с языком C в Java открывается интересная возможность организовать «лестничные» массивы. Для случая двумерного массива размер каждой отдельной строки может отличаться от остальных:

Как и в C, элементы массива располагаются в памяти один за другим, поэтому доступ к массиву считается самым эффективным. Если же требуются выполнять операции вставки/удаления элементов, или создавать более сложные структуры данных, то необходимо использовать коллекции, такие как множество (Set), список (List), карта (Map).

За отсутствием указателей и невозможностью инкрементировать ссылки доступ к элементам массива возможен с помощью индексов.

Коллекции

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

В отличии от C, стандартная библиотека Java содержит богатый набор реализаций динамических структур данных или коллекций, выражаясь терминами Java. Все коллекции делятся на 3 больших класса: списки, множества и карты.

Списки – динамические массивы – позволяют добавлять/удалять элементы. Множества не обеспечивают порядка добавленных элементов, но гарантируют отсутствие дубликатов элементов. Карты или ассоциативные массивы оперируют парами «ключ – значение», причем значение ключа уникально – в карте не может быть 2 пары с одинаковыми ключами.

Для списков, множеств и карт существует множество реализаций, каждая из которых оптимизирована для определенной операции. Например, списки реализованы классами ArrayList и LinkedList, причем ArrayList обеспечивает лучшую производительность при доступе к произвольному элементу, а LinkedList – более эффективен при вставке/удалении элементов в середину списка.

В коллекциях могут храниться только полноценные Java-объекты (фактически – ссылки на объекты), поэтому создать непосредственно коллекцию примитивов (int, char, byte и др.) нельзя. В этом случае следует использовать соответствующие классы-«обертки»:

К счастью, программируя на Java, нет необходимости следить за точным совпадением примитивного типа и его «обертки». Если метод получает аргумент, например, типа Integer, то ему можно передавать тип int. И наоборот, где требуется тип int, смело можно использовать Integer. Это стало возможным благодаря наличию в Java встроенного механизма упаковки/распаковки примитивов.

Из неприятных моментов следует упомянуть, что стандартная библиотека Java содержит старые классы коллекций, которые были неудачно реализованы в первых версиях Java и которые не следует использовать в новых программах. Речь идет о классах Enumeration, Vector, Stack, Dictionary, Hashtable, Properties.

Обобщения

Коллекции обычно используют как обобщенные типы данных. Суть обобщений в этом случае заключается в том, что мы задаем основной тип коллекции, например, ArrayList, а в угловых скобках указываем тип-параметр, который в данном случае определяет тип хранимых в списке элементов:

Это позволяет компилятору отследить попытку добавления в такой список объекта иного типа, нежели указанный тип-параметр:

Очень важно, что во время выполнения программы тип-параметр стирается, и нет никакой разницы между, например, объектом класса и объектом класса Как следствие нет возможности узнать тип элементов коллекции во время выполнения программы:

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

Но такой подход не сработает, если список пуст.

В этом плане обобщения Java значительно уступают обобщениям C++. Обобщения Java фактически служат для «отсечения» части потенциальных ошибок на стадии компиляции.

Перебор всех элементов массива или коллекции

Программируя на С часто приходится перебирать все элементы массива:

Ошибиться здесь проще простого, достаточно указать неверный размер массива SIZE или поставить «

Источник