Внутренний класс в интерфейсе по сравнению с в классе

Я думал, что первый объявит класс Levels и статический внутренний класс Items. Элементы могут ссылаться на Levels.Items и будут статичными.

Хотя второй будет объявлять простой внутренний класс, доступ к которому можно получить с помощью Levels.Items, как показано ниже:

Levels.Items hello = new Levels.Items();

РЕДАКТИРОВАТЬ: это совершенно неправильно, прочитайте комментарии и другие ответы .

Внутренний класс static является вложенным классом, а нестатический класс называется внутренним классом. Подробнее см. здесь .

Тем не менее, мне нравится цитировать отрывок из той же ссылки.

Статический вложенный класс взаимодействует с члены экземпляра его внешнего class (и другие классы) точно так же, как любой другой класс высшего уровня. В результате, статический вложенный класс поведенчески класс верхнего уровня, который был вложен в другом классе высшего уровня для удобство упаковки.

Вы не использовали слово static во втором случае. И вы думаете, что это будет неявно статическим , потому что это интерфейс. Вы правы, предполагая, что.

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

Levels.Items hello = new Levels.Items();

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

Обычно внутренний класс в классе, не в интерфейсе , будет создан, как показано ниже.

Levels levels = new Levels();
Levels.Items items = levels.new Items();

Более того, «нестатический» внутренний класс будет иметь неявную ссылку на свой внешний класс. Это не относится к «статическому» вложенному классу.

Приведенные вами примеры вложенных / внутренних классов являются (ИМО) плохими примерами. Кроме того, второй пример недопустим для Java, поскольку интерфейс может только (неявно) объявлять абстрактные методы. Вот лучший пример:

public interface Worker {

    public class Response {
        private final Status status;
        private final String message;
        public Response(Status status, String message) {
            this.status = status; this.message = message;
        }
        public Status getStatus() { return status; }
        public String getMessage() { return message; }
    }

    ...

    public Response doSomeOperation(...);
}

Встраивая класс Response, мы указываем, что он является фундаментальной частью Worker API и не имеет другого использования.

Класс Map.Entry - хорошо известный пример этой идиомы.

История iPhone восходит к OpenStep от NeXT Computer. Некоторое время в центре внимания NeXT были специализированные корпоративные приложения. Технологии, которые используются в iPhone, хорошо зарекомендовали себя в корпоративных средах. NeXT был одним из первых защитников объектной технологии, шаблонов и MVC в частности.

Тем не менее, кое-что из того, что раньше было доступно в Openstep, теперь исчезло. У NeXT была радикально продвинутая система ORM (Enterprise Objects Framework - http://en.wikipedia.org/wiki/Enterprise_Objects_Framework ), которая, хотя все еще используется внутри Apple и поддерживает iTunes и т. Д., теперь не рекомендуется для клиентов, использующих Objective-C (версия Java все еще существует). Облегченная ORM, Core Data ( http://developer.apple.com/macosx/coredata.html ), заняла свое место и теперь доступна на iPhone. SQLite (что замечательно) также входит в комплект iPhone и доступен для разработчиков.

Еще одна ложка дегтя заключается в том, что текущая версия XCode для iPhone имеет ограниченное понимание подпроектов / фреймворков, поэтому сложнее многоразовый код раздела, чем раньше. Тим Вуд из Omni предоставляет некоторые подробности о том, как управлять фреймворками в XCode на iPhone ( http://blog.omnigroup.com/2008/10/01/using-frameworks-in-iphone-applications/ ) К сожалению, процесс не так прост, как должен быть.

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

svn и mvn доступны / связаны в OS X. Также есть варианты для загрузки других пакетов с открытым исходным кодом через такие системы, как fink или MacPorts:

• http : //www.finkproject.org/about.php
• http://www.macports.org/
• http://github.com/mxcl/homebrew

Есть также несколько вариантов фреймворка, которые поддерживают TDD. Дизайн на основе тестирования для собственных приложений iPhone

В настоящее время это не похоже на сонарный анализ Objective-C. В зависимости от ваших возможностей, может быть, вы могли бы разработать для этого модуль?

Преимущество в том, что у вас меньше классов, загромождающих папку проекта, если они тривиальны; недостаток состоит в том, что когда ваш внутренний класс растет вместе с изменением требований, maintenacne становится вашим кошмаром.