Ответ 1
Достаточно ли этого, чтобы я определил свою спецификацию следующим образом:
JMA должен предоставить метод, который добавляет два целых числа?
Это спецификация.
Это не очень полезно, потому что он не дает много гарантий пользователю в реализации этой спецификации. Если бы я хотел написать программу, которая добавляет два целых числа, я не мог бы это сделать, просто прочитав спецификацию.
Это дает разработчику большую свободу. Как правило, вы хотите, чтобы ваши спецификации были точными в точках, которые важны для пользователя, но смутные в точках, которые имеют значение для разработчика. Таким образом, пользователь получает гарантии, необходимые ему для написания своих программ, но также предоставляет разработчику свободу адаптировать свою реализацию к своей конкретной нише.
Например, спецификация языка Java ничего не говорит о коллекции мусора. Он определяет только, когда объекты являются недоступными, и определяет, что вы можете создавать новые объекты. Как работает распределение памяти, как работает сборщик мусора, независимо от того, является ли он эталонным подсчетом, трассировкой или коллекцией на основе регионов и т.д., Все эти функции не учитываются, и, таким образом, различные реализации для разных ниш могут использовать различные реализации сборщика мусора, и различные реализации для одной и той же ниши могут конкурировать друг с другом.
или, мне нужно создать документ примерно так:
JMA должен предоставить метод: int jmaAdd (int x, int y)?
Это также спецификация. Это еще менее полезно, чем выше. Он определяет имя метода, но он не определяет, что он делает.
int jmaAdd(int x, int y) { return x - y; }
- вполне допустимая реализация этой спецификации, как и
int jmaAdd(int x, int y) { return 0; }
Опять же, нет никаких гарантий для пользователя и слишком много свободного (или, точнее, отклонения в неправильных областях) для разработчика.
или, нужно ли создавать интерфейсы и распространять исходный код?
public interface JMA{ int jmaAdd(int x,int y); }
Я бы не стал называть эту спецификацию. Этот код и, следовательно, реализация.
Примечание: в Java, interface
укажите спецификацию поведения, которую реализует class
es. Но это не то, что подразумевается под термином спецификация, как вы использовали его в своем вопросе.
или мне нужно скомпилировать интерфейсы и опубликовать их как jar?
Опять же, что реализация.
Кроме того, может ли спецификация содержать абстрактные классы или классы вообще? Или он должен состоять только из интерфейсов?
Спецификация не содержит ничего. Это кусок бумаги.
Как правило, спецификации написаны на английском языке. На самом деле, они написаны на специализированном языке написания спецификаций, который часто является стилизованным формальным подмножеством английского языка с определенной семантикой. Например, BCP14/RFC2119: Ключевые слова для использования в RFC для указания уровней требований определяет точное значение некоторых общих английских слов в отношении документов стандартов IETF. (Интересно, что это также спецификация, что делает ее спецификацией для написания спецификаций.)
Формальная логика также иногда используется, особенно в спецификациях языка программирования для описания правил ввода. И иногда используются даже специализированные языки официальной спецификации, такие как Z Notation.
Что делает спецификацию, спецификацию?
Простой и не очень удовлетворительный ответ заключается в том, что спецификация является спецификацией, если она называется спецификацией тех, кто интересуется спецификациями. (Или, в более общем плане, мысль о спецификации).
Различные сообщества имеют разные взгляды на спецификации. И разные имена для них.
Например, исходная спецификация schemeязык программирования был просто опубликован в научном отчете. Затем после нескольких раундов усовершенствований и новых отчетов они опубликовали "Пересмотренный отчет по алгоритмической языковой схеме". И после этого "Пересмотренный пересмотренный отчет по алгоритмической языковой схеме". С этим началась своего рода шутка, и текущая версия языка определена в "Пересмотренном пересмотренном пересмотренном пересмотренном пересмотренном пересмотренном пересмотренном пересмотренном отчете об алгоритмической языковой схеме", обычно на котором написано "Пересмотренный 7 Отчет по алгоритмической языковой схеме" или просто "R 7 RS".
Ни один из этих отчетов не называется "спецификацией", но каждый из них является спецификацией. До схемы ALGOL также использовал термин "Отчет", как и несколько других языков.
Интернет-RFC также являются хорошим примером. Технически, все RFC есть, это "Запрос комментариев". Только очень немногие из этих RFC фактически повышены до статуса "Стандарты". Некоторые из них также являются "Лучшими действующими практиками". Ни один из них не называется "Спецификация", но многие из них рассматриваются таким образом. Например, HTTP не является стандартом, но он рассматривается как стандарт и спецификация, и значительная часть нашей новой мировой экономики построена на этом.
Если вы хотите получить представление о спецификациях, вероятно, лучше всего, если вы просто прочитаете:
- Отчет о языке Haskell 2010 (Другой пример имени "Отчет" )
- Scala Спецификация языка версии 2.11
- ECMA-262 6-е издание, спецификация ECMAScript 2015
- Спецификация языка Java, версия Java SE 8
- Спецификация виртуальной машины Java, версия Java SE 8
- Спецификации HTTP, включая, но не ограничиваясь,
- Уровень жизни HTML (иначе HTML5)