Каково различие между “сценарием” и “приложением”?
Когда вы объявляете ссылочную переменную (т. е. объект), вы действительно создаете указатель на объект. Рассмотрим следующий код, в котором вы объявляете переменную примитивного типа 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; причина использования Трассировки стека
17 ответов
Традиционно программа компилируется, и сценарий интерпретируется, но это больше не действительно важно. Можно генерировать скомпилированную версию большинства сценариев, если Вы действительно хотите, и другие 'скомпилированные' языки как Java на самом деле интерпретируются (на уровне кода байта.)
А более современное определение могло бы быть то, что программа предназначается, чтобы использоваться клиентом (возможно, внутренний) и таким образом должна включать документацию и поддержку, в то время как сценарий, прежде всего, предназначается для использования автора.
сеть является интересным встречным примером. Все мы любим искать вещи с поисковой системой Google. Объем кода, который входит в создание 'базы данных', на которую это ссылается, используется только ее авторами и специалистами по обслуживанию. Это делает его сценарием?
Я сказал бы, что сценарий обычно набор команд или инструкций, записанных в простом тексте , которые являются выполнены хост-приложением (браузер, интерпретатор команд или оболочка...).
Это не означает, что не мощно или не скомпилированное в некотором роде, когда это на самом деле выполняется. Но сценарий ничего не может сделать отдельно, это - просто текст.
По своей природе это может быть фрагмент только, будучи должен быть объединенным для создания программы или приложения, но расширенные и полностью разработанные сценарии или набор сценариев можно считать программами или приложениями, когда выполняется хостом, точно так же, как набор исходных файлов может стать приложением, однажды скомпилированным.
На самом деле различие между сценарием (или язык сценариев) и приложением - то, что сценарий не требует, чтобы он был скомпилирован на машинный язык.. Вы выполняете источник сценария с интерпретатором.. Приложение компилирует источник в машинный код так, чтобы можно было выполнить его как автономное приложение.
Приложение является большим и будет использоваться много раз людьми и возможно продаваться клиенту.
сценарий А начинается маленький, остается маленьким, если Вы удачливы, редко продается клиенту, и мог бы или быть выполнен автоматически или выйти из употребления.
Лично, я думаю, что разделение является шагом назад от фактической реализации.
По моей оценке, приложение планируется. Это имеет несколько целей, это имеет несколько результатов. Существуют задачи, отложенные во время проектирования перед кодированием, которое должно встретить приложение.
сценарий А однако, просто брошен вместе как иски, и мало планирования включено.
Отсутствие надлежащего планирования однако не понижает Вас до сценария. Возможно, это подает Вашу заявку плохо организованный набор плохо запланированных сценариев.
Далее больше, приложение может содержать сценарии, которые агрегировались, включают целое. Но сценарий может только сослаться на приложение.
Беря жемчуг в качестве примера, можно записать сценарии жемчуга или приложения жемчуга.
сценарий А подразумевал бы единственный файл или единое пространство имен. (например, updateFile.pl).
приложение было бы чем-то составленным из набора файлов или пространств имен/классов (например, разработанное на основе OO приложение жемчуга со многими .pm файлами модуля).
Язык сценариев не имеет стандартной библиотеки или платформы (или не большая часть одной). Это является маленьким и легким, разработано, чтобы быть встроенным в объемное приложение. Bash и JavaScript являются яркими примерами языков сценариев, потому что они полагаются абсолютно на другие программы для своей функциональности.
Используя это определение, сценарий является кодом, разработанным для управления объемным приложением (комплект). JavaScript мог бы обратиться к Firefox с просьбой открыть окна или управлять DOM. Сценарий Bash выполняет существующие программы или другие сценарии и соединяет их вместе с каналами.
<час>Вы также спрашиваете почему не языки сценариев, таким образом:
там даже какие-либо инструменты поблочного тестирования для языков сценариев? Это кажется очень важным инструментом для "реальных" приложений, который является абсолютно недостающим. И редко существует любая реальная привязка библиотеки для языков сценариев.
большинство времен, сценарии могли быть заменены реальным, легким языком как Python или Ruby так или иначе.
Сценарий обычно работает как часть объемного приложения в механизме выполнения сценариев, например, JavaScript-> Браузер, который Это и в отличие от традиционных статических введенных скомпилированных языков и на динамические языки, где код предназначается для явлений основной частью приложения.
Это - часто просто семантический аргумент, или даже способ клеветать на определенные языки программирования. Насколько я заинтересован, "сценарий" является типом программы, и точное определение несколько неопределенно и меняется в зависимости от контекста.
я мог бы использовать термин "сценарий" для значения программы, которая, прежде всего, выполняется линейно, а не с большой последовательной логикой или подпрограммами, во многом как "сценарий" в Голливуде линейная последовательность инструкций для агента для выполнения. Я мог бы использовать его для значения программы, которая записана на языке, встроенном в большей программе, в целях управления той программой. Например, автоматизируя задачи в соответствии со старым Mac OS с AppleScript или управляя программой, которая представляет себя в некотором роде со встроенным интерфейсом TCL.
, Но во всех тех случаях, сценарий является типом программы.
термин "язык сценариев" был использован для динамично интерпретируемого (иногда компилируемый) языки, обычно они имеют много типичных функций, таких как инструкции очень высокого уровня, созданные в хешах и списках произвольной длины и других структурах данных высокого уровня, и т.д. Но те языки способны к очень большим, сложным, модульным, хорошо разработанным программам, поэтому при размышлении о "сценарии", поскольку что-то другое, чем программа, тот термин мог бы смутить Вас.
Видят также , действительно ли это - программа Perl или сценарий Perl? в perlfaq1.
Сценарий мне подразумевает линию за линией интерпретацию кода. Можно открыть сценарий и просмотреть его читаемое программистом содержание. Приложение подразумевает автономный скомпилированный исполняемый файл.
Сценарий имеет тенденцию быть рядом команд, который запускается, работает и завершается. Это часто требует нет/мало человеческого взаимодействия. Приложение является "программой"..., оно часто требует человеческого взаимодействия, оно имеет тенденцию быть больше.
У John Ousterhout (изобретатель TCL) есть хорошая статья в http://www.tcl.tk/doc/scripting.html , где он предлагает различие между системными языками программирования (для реализации стандартных блоков, акцента на правильность, безопасность типов) по сравнению с языками сценариев (для объединения стандартных блоков, акцента на скорость отклика к изменяющим средам и требованиям, легкому преобразованию в и из текстовых представлений). Если Вы идете с той системой классификации, то 99% программистов делают работы, которые более соответствуют языкам сценариев, чем на системные языки программирования.
Это - интересная тема, и я не думаю, что существуют очень хорошие инструкции для дифференциации "сценария" и "приложения".
Позволяют нам смотреть на некоторые статьи Wikipedia для получения ощущения различия.
Сценарий (Википедия-> Язык сценариев):
язык сценариев А, язык сценария или дополнительный язык, является языком программирования, который управляет приложением. "Сценарии" часто рассматривают в отличие от "программ", которые выполняются независимо из любого другого приложения. В то же время они отличны от базового кода приложения, которое обычно пишется на различном языке, и будучи доступными конечному пользователю они позволяют поведению приложения быть адаптированным к потребностям пользователя.
Приложение (Википедия-> Прикладное программное обеспечение-> Терминология)
В информатике, приложение является компьютерной программой, разработанной, чтобы помочь людям выполнить определенный тип работы. Приложение таким образом отличается от операционной системы (который выполняет компьютер), утилита (который выполняет обслуживание или работу по дому общего назначения), и язык программирования (с которым компьютерные программы создаются). В зависимости от работы, для которой это было разработано, приложение может управлять текстом, числами, графикой или комбинацией этих элементов.
Чтение вышеупомянутые записи, кажется, предполагают, что различие - то, что сценарий "размещается" другой частью программного обеспечения, в то время как приложение не. Я предполагаю, что это может быть обсуждено, такие как сценарии оболочки, управляющие поведением оболочки и сценариями жемчуга, управляющими поведением интерпретатора для выполнения желаемых операций. (Я чувствую, что это может быть чем-то вроде фрагмента, таким образом, я не могу достичь единой точки зрения с ним.)
, Когда это сводится к нему, это, по-моему, которым разговорное различие может быть сделано с точки зрения масштаб из программы. Сценарии обычно меньше по своим масштабам когда по сравнению с приложениями.
кроме того, с точки зрения цели, сценарий обычно выполняет задачи , которому нужно заботившийся о, скажите, например, создайте сценарии, которые производят несколько версий выпуска для определенной части программного обеспечения. На otherhand приложения приспособлены к обеспечивающая функциональность , который более усовершенствован и приспособлен к конечному пользователю. Например, Блокнот или Firefox.
Обычно, это - "сценарий" по сравнению с "программой".
я с Вами, которых это различие является главным образом "скомпилированным снобизмом языка", или заключить Larry Wall в кавычки и взять другую сторону забора, "сценарий - то, что имеют агенты, программа дана аудитории".
Я сказал бы, что приложение имеет тенденцию использоваться в интерактивном режиме, куда сценарий выполнил бы свой курс, подходящий для работы в пакетном режиме. Я не думаю, что это - конкретное различие.
Приложение является набором сценариев, приспособленных к единому набору проблем.
сценарий А является небольшим количеством кода для выполнения одной довольно определенной задачи.
IMO, различие не имеет ничего вообще, чтобы сделать с языком, это используется. Возможно записать сложное приложение с ударом, и возможно записать простой сценарий с C++.
Прежде всего, я хотел бы внести ясность в то, что скрипт - это программа. Другими словами, скрипт - это набор инструкций.
Программа:
Набор инструкций, который будет скомпилирован, известен как программа.
Скрипт:
Набор инструкций, который будет интерпретирован, известен как скрипт.