помещение капитала 'я' перед [закрытыми] интерфейсами JAVA

Использование префикса «I» в интерфейсах - это то, что основано на COM (.NET только что унаследовал это соглашение) и не стандарт в Ява. Посмотрите на любой JDK или другой код, разработанный Sun, и вы не увидите префикса I. И это не только Sun, большинство проектов Java не используют префикс I. Приставка I - это не стандарт Java, а аберрация, принятая в некоторых уголках мира Java.

Это обычно не делается в Java - это вещь C # /. NET.

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

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

Но это все равно не стандарт.

Нет, это не условие. По крайней мере, в рамках JDK. Тем не менее, если ваш магазин имеет это как соглашение, даже если это может не быть практикой снаружи, я бы предложил вам последовать его примеру. Обеспечение согласованности в рамках группы имеет более важное значение с точки зрения конвенций.

Необходимо включить параметр "Generate debug info" в параметрах компилятора

В Java соглашение заключается в попытке завершить интерфейсы в "able". Сериализуемый, клонируемый и так далее. В .NET они начинаются с "I".

Я бы придерживался подхода, который является стандартным в вашем языке (т.е. попробуйте "возможное" расширение). Я не согласен с Software Monkey в том, что она "утекает информацию, которая не должна просачиваться". Прекрасно иметь имя, показывающее, что это за вещь, IMHO.

Мне, эээ, не нравятся такие вещи. Я работал с одним продуктом Java, который делал это, и это было безумием.

В конечном счете, этот вид вещей восходит к FORTRAN-I в 1950-х годах, когда I, J, K,... вплоть до, забыл, какого числа, были автоматически целыми числами, а остальной алфавит - вещественными (с плавающей точкой).

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

Один из аргументов против использования префикса, который я слышал, заключается в том, что по сути дела в схему именования переносится языковой вопрос (т.е. дикотомия интерфейсов и классов). Другой аргумент заключается в том, что "все в публичном API в любом случае должно быть интерфейсом, а не классом". Поскольку многие классы, реализующие интерфейс, называются "XImpl", можно утверждать, что это может быть излишним. Однако использование префикса может иметь смысл, если тип является просто маркером.

Это, конечно, соглашение .NET, и Microsoft делает это со своими собственными интерфейсами в библиотеке базовых классов .NET. Это было принято в Java, когда я изучал Java, и не могу представить, что это изменилось, хотя я не в курсе последних событий в Java.

В качестве примечания: в C++ мы также всегда использовали префикс "I", и действительно, мы всегда использовали префикс классов "C". Мы не перенесли это соглашение 'C' на .NET.

В моей сети имеется сервер apache. Мой сервер называется «сервер», поэтому я просто набираю на других рабочих станциях http ://server . Другой наконечник помещается в файлы хоста это разрешение:

192.168.0.100 server

IP-адрес является лишь примером, если у вас есть три рабочие станции и вы хотите получить доступ к ним, как:

http://machine1
http://machine2
http://machine3

Вы бы имели в вашем хосте файлы:

192.168.0.1 machine1
192.168.0.2 machine2
192.168.0.3 machine3

Так что...

1) Да, если вы задаете имя компьютера в файлах хоста, как я сказал выше 2) Apache запускается автоматически, если зарегистрирован как сервис. 3) Да. Apache - это то, что нужно, чтобы писать локальные сайты с помощью PHP (Если вы хотите MySql тоже, то установите его)

Учитывая, что это стандартный модуль, перейти с подходом из Модуль:: Загружено :

sub is_loaded (*) { 
    my $pm      = shift;
    my $file    = __PACKAGE__->_pm_to_file( $pm ) or return;

    return $INC{$file} if exists $INC{$file};

    return;
}

sub _pm_to_file {
    my $pkg = shift;
    my $pm  = shift or return;

    my $file = join '/', split '::', $pm;
    $file .= '.pm';

    return $file;
}

Этот вид стиля кодирования называется Венгерская нотация , потому что он был изобретен Шарлем Симони в Microsoft, Целью венгерской нотации является кодирование семантической информации, которая не может быть выражена внутри системы типов в имена идентификаторов.

Однако система типов Java прекрасно способна различать интерфейсы (просто попытаться расширить один с классом), абстрактные классы (просто попытаться создать экземпляр одного) и классы (просто попытаться реализовать один), и так же большинство IDE. Так что использовать венгерскую нотацию таким образом совершенно бесполезно.

Это никогда не было конгрессом, насколько я знаю, и это, конечно, не сейчас. По крайней мере, в сообществе Java. (Однако некоторые проекты Java используют его. Он также иногда используется в C++, но там это имеет смысл, потому что нет такой вещи, как интерфейс в C++, поэтому вы должны иметь способ отметить их. Он также используется в CLI, где он не имеет абсолютно никакого смысла по той же причине, что и в Java.)

Он довольно часто используется в Eclipse Framework. Это зависит от индивидуального стиля проекта, но это не стандартная конвенция. Тем не менее, в некоторых случаях это может помочь в обслуживании и поиске кода.

Я бы не рекомендовал его использовать. Вы никогда не знаете, если ваш интерфейс однажды станет абстрактным классом. Тогда вам придется переименовывать каждый отдельный случай использования или просто придерживаться уродливого названия абстрактного класса с префиксом.

(Источник: Роберт К. Мартин - Agile Software Development: Principles, Patterns and Practices)