lvovin
Newbie | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
rew
Цитата:
Цитата:
Обязательное описание исключений - за такое бейсбольной битой по пальцам
обязательная обработка исключений присутствует только там где может возникнуть исключительная ситуация, такая как например нет доступа к файлу или прервалась связь. если не обработать исключение в таких ситуациях, это может привести к непредсказуемым последствиям. так что сделано это как раз с благими намерениями. сказать чесно по началу меня это тоже немного раздражало, но современные редакторы позволяют автоматически втавлять try-catch там где это нужно, так что уже не парит
|
Описание исключений в заголовке метода нарушает принцип локальности. Это пожалуй один из важнейших принципов ООП. Изменение в одном месте не должно затрагивать всю систему, а должно ограничиваться некоторыми локальными изменениями.
Представь, у тебя есть вызов в главном модуле, который идет через кучу диспетчеров и заканчивается глубоко внизу в методе, который делает реальную работу с базой/сокет/чем-угодно. Если ты введешь новое исключение в реальном методе и будешь его обрабатывать на семом верху, то тебе придется изменить объявление всех промежуточных методов.
Получается, знание, которое должно принадлежать только двум методам, расползается очень широко.
В новых jdk даже заплатку для этого какую-то придумали, вроде можно еще самому делать перекаст в RuntimeException.
Плюс если делается удаленный вызов, и сигнатуры исключений на разных сторонах отличаются (а они могут), что будет происходить?
Цитата:
Цитата:
просто никакая поддержка классов коллекций
чего именно не хватило то? по моему там реализованы все классические виды коллекций.
|
Какие-то коллекции там присутствуют, но насколько удобно с ними работать?
Можно привести несколько простых задач и не увидеть нормального решения.
Например - на основе коллекции построить коллекцию *того же типа* (ArrayList -> ArrayList, LinkedList -> LinkedList, etc), где отобраны только элементы удовлетворяющие заданному критерию (например, значение больше некоторой константы). И чтобы код работал для любых типов лежащих в коллекции, особенно интересуют строки, числа, даты.
Сравнить полученный код с этим:
aCollection select: [:each | each > someConstant]
Цитата:
Цитата:
статическая типизация, требующая постоянного приведения типов (жуткое зло) и т.д.
всмысле нет автоматического кастинга? опять же сделано с благими намерениями, что бы програмист не забывал с чем имеет дело когда приводит один тип к другому, и тот который пишет, и тот который потом захочет посмотреть или использовать код.
вообще если в си принято писать как можно короче (не дай бог написать лишнего символа), то в java как раз наоборот приветсвуется развернутый, но более понятный код. кроме того не нужно путать си++ с жавой, кроме синтаксиса там действительно очень мало общего
|
Всмысле существующая система типов изначально концептуально поломана (а именно manifest static typing).
Явное приведение типов, неявное приведение типов, наличие нетипизированного null (само по себе большая дыра), примитивные типы данных, нерасширяемость типов, и т.д. и т.п.
--
Владимир.
http://www.smalltalk.ru
|
