Действительно ли направляющими является черный квадрат?
Когда вы объявляете ссылочную переменную (т. е. объект), вы действительно создаете указатель на объект. Рассмотрим следующий код, в котором вы объявляете переменную примитивного типа int:
int x;
x = 10;
В этом примере переменная x является int, и Java инициализирует ее для 0. Когда вы назначаете его 10 во второй строке, ваше значение 10 записывается в ячейку памяти, на которую указывает x.
Но когда вы пытаетесь объявить ссылочный тип, произойдет что-то другое. Возьмите следующий код:
Integer num;
num = new Integer(10);
Первая строка объявляет переменную с именем num, но она не содержит примитивного значения. Вместо этого он содержит указатель (потому что тип Integer является ссылочным типом). Поскольку вы еще не указали, что указать на Java, он устанавливает значение null, что означает «Я ничего не указываю».
Во второй строке ключевое слово new используется для создания экземпляра (или создания ) объекту типа Integer и переменной указателя num присваивается этот объект. Теперь вы можете ссылаться на объект, используя оператор разыменования . (точка).
Exception, о котором вы просили, возникает, когда вы объявляете переменную, но не создавали объект. Если вы попытаетесь разыменовать num. Перед созданием объекта вы получите NullPointerException. В самых тривиальных случаях компилятор поймает проблему и сообщит вам, что «num не может быть инициализирован», но иногда вы пишете код, который непосредственно не создает объект.
Например, вы можете имеют следующий метод:
public void doSomething(SomeObject obj) {
//do something to obj
}
В этом случае вы не создаете объект obj, скорее предполагая, что он был создан до вызова метода doSomething. К сожалению, этот метод можно вызвать следующим образом:
doSomething(null);
В этом случае obj имеет значение null. Если метод предназначен для того, чтобы что-то сделать для переданного объекта, целесообразно бросить NullPointerException, потому что это ошибка программиста, и программисту понадобится эта информация для целей отладки.
Альтернативно, там могут быть случаи, когда цель метода заключается не только в том, чтобы работать с переданным в объекте, и поэтому нулевой параметр может быть приемлемым. В этом случае вам нужно будет проверить нулевой параметр и вести себя по-другому. Вы также должны объяснить это в документации. Например, doSomething может быть записано как:
/**
* @param obj An optional foo for ____. May be null, in which case
* the result will be ____.
*/
public void doSomething(SomeObject obj) {
if(obj != null) {
//do something
} else {
//do something else
}
}
Наконец, Как определить исключение & amp; причина использования Трассировки стека
9 ответов
Проблема с конвенцией по конфигурации состоит в том, что необходимо знать конвенцию. По крайней мере, с конфигурационным файлом у Вас есть что-то для чтения при начале работы... После того как Вы знаете конвенцию, она идет намного быстрее, но у Вас есть утес изучения для утверждения с тем временем.
Я нашел направляющие очень легкими работать с. Вы могли бы хотеть взять Гибкая веб-разработка с направляющими . Это была большая справка ко мне в изучении "Направляющих путь". Я использовал его больше в качестве ссылки, чем учебное руководство, но это обходит Вас посредством создания приложения и объясняет, что продолжается. FWIW, я взял направляющие более быстро, чем ASP.NET (который я все еще изучаю) и знаю, что направляющие имеют справку очень в изучении ASP.NET MVC.
Как с чем-либо, я думаю, что дьявол находится в деталях. Да, чрезвычайно легко успешно начать сайт и создавать помехи частям вместе для создания чего-то, что работает, но придумать хорошо разработанную и устойчивую систему требует более глубокого дизайна и мысли. Очень легко начать принимать плохие решения OO, как нарушение закона Demeter, потому что вещи настолько быстры для соединения. Направляющие это легки. Большие направляющие не.
Я верю, "знают, что Ваши конвенции" не являются проблемой. Я знаю, что, если я делаю X затем, у меня есть работа Y. Но что X делает?? Направляющие походят на черный квадрат мне, и иронически когда Он говорит о "конвенции по конфигурации" целый процесс создания приложения для направляющих, больше похож на конфигурацию, чем программирование.
у меня было это странное исключение только что при следовании примеру Jruby на направляющих (Ola Bini)....
CreateProductCategories не пропускает постоянный ProductType!
Это произошло, потому что версии направляющих отличались, но точка..., все прекрасно, пока Вы не подсовываете золотой путь, и черный квадрат больше не помогает Вам, и ЗАТЕМ Вы понимаете, что понятия не имеете, что Вы делали все время и начинаете просить о справке на форумах / список рассылки (и затем Вы узнаете, что большинство людей не знает то, что они делали или почему, просто что это работало).
Так или иначе, хорошо знать, что я не являюсь сумасшедшим, и некоторые люди столкнулись с этим видом проблем. Благодаря всем.
пз: английский язык не является моим естественным языком поэтому при нахождении грамматических ошибок отредактируйте их.
Pablo Вы могли бы хотеть изучить Django, который разрабатывается группой, которая приняла решение сфокусироваться на обеспечении документации высшего качества как приоритет.
направляющие Черный квадрат?
направляющие действительно имеют некоторый 'волшебный код', где Вы просто пишете то, что учебное руководство говорит, чтобы записать и наполнить волшебно работы, однако это нисколько не черный квадрат.
-
По определению 'черный квадрат' - что-то, что Вы не можете посмотреть внутри. Поэтому у Вас не может быть проекта открытого исходного кода 'черного квадрата'. Вот являются направляющие 2,1 стабильными исходными кодами , смотрите
-
, Если чтение исходного кода не является Вашей вещью, большинство этих 'волшебных функций' хорошо зарегистрировано и объяснено на многих веб-сайтах и блогах (и если они не, можно всегда спрашивать здесь, и я на 100% уверен, что Вы доберетесь, хороший ответ)
-
Помнят, что, если Вы все еще на учебном этапе, любое учебное руководство будет иметь много из 'просто вставленного эта строка кода', потому что они пытаются добраться понятия через, не копают во внутренние работы всего. Любая платформа на планете, не только направляющие, имеет 'волшебство' в их учебных руководствах
Я думаю, что это - вопрос перспективы. С широкой точки зрения сообщество направляющих поддержало платформу как что-то, что настолько легко. Но истина, это не. На самом деле, чем больше я работаю с направляющими, тем меньшим количеством фаната я становлюсь. Я не думаю, что это - отказ направляющих, но я думаю, что много людей получило впечатление, что запись направляющие являются приложением, так или иначе сродни помахиванию волшебной палочкой (и я сам потягивал ту kool-помощь).
направляющие действительно выполняют много обещаний, хотя, поскольку это обеспечивает большую функциональность, которая требует малого ни к какой конфигурации. Вещи, такие как ORM, отношения модели и проверка тривиальны, чтобы настроить, и оставить намного больше времени для вещей такой прикладной логикой подстройки и фокусировкой на дизайне. Код направляющих также действительно, действительно легок осуществить рефакторинг. Направляющие абсолютно позволяют Вам стать много сделанными с небольшим кодом.
то, Где я расстроен, - когда я хочу идти в глуши. Я мог бы хотеть достигнуть 'очень определенной функциональности X', но я не могу узнать, где запустить. Я нахожу, чем глубже я вхожу в платформу, тем более редкой информация становится. Части API находятся горестно под - зарегистрированы. Это вынуждает меня полагаться на сторонние плагины, некоторые из которых не имеют никакой документации, и не хорошо сохраняются. Я в значительной степени застреваю с сообщением в блоге, говорящим мне для копирования этого кода или того кода в мое приложение, и вещи будут просто работать (к счастью, они обычно делают).
Некоторые мои проблемы могли бы быть моим связанным с общей неопытностью (все еще делающий переход от разработчика программисту), но я часто чувствую, что, в то время как направляющие обеспечивает превосходные инструменты для создания веб-сайтов, это не делает, по крайней мере, на поверхности, обеспечьте большие инструменты для создания других инструментов. Это имеет потенциал, но действительно необходимо вырыть глубоко.
Я согласен с Брайаном М.
Происходит так много черной магии и жутких вещей, тысячи строк кода, повсюду мета-мета-программирование.
Но чтобы быть Справедливый Rails научил меня так же, как разработка, основанная на спецификациях, REST и хорошее понимание Ruby.
Прямо сейчас я нахожусь в точке, где 20% времени проходит гладко, а остальные 80% я трачу на борьбу с соглашениями Rails. Я чувствую себя намного более продуктивным, когда пишу чистый Ruby.
В какой-то момент Merb показался мне вариантом, следующим проектом, который я собирался с Rack / Sinatra и CouchDB.
У меня есть небольшие знания о том, как работают внутренние компоненты рельсов, и я очень надеюсь, что работа, которую Кац проделывает для рельсов 3.0, сделает их более легкими для понимания, и особенно много более документировано. AFAIK, он создавал некоторые четко определенные интерфейсы между «модулями / уровнями», например, все ORM имеют общие интерфейсы, поэтому вы сможете не только заменить ORM, но и легко понять интерфейс, который связывается с рельсами и ORM.
Вопреки общепринятому мнению, я считаю, что rails - очень сложный фреймворк, гораздо больше, чем чистый php. Ретрансляция на фреймворке, который вы не понимаете, имеет некоторые последствия, а изучить внутреннее устройство рельсов непросто даже для опытного рубиста.
С другой стороны, экосистема рельсов движется очень быстро, и это добавляет еще один уровень сложности. За последний месяц я добавил по крайней мере 3-4 драгоценных камня, а за месяц до того, как я полностью изменил свой рабочий процесс, добавив огурцы в свой процесс. но, думаю, это цена, которую я плачу за то, что работаю в ИТ-индустрии.