Фиксация Пустого указателя EntityManger в Spring приложение MVC?

Несколько ключевых «отличий» в «Стиле» внутри более широкого баннера ООП.

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

Полиморфное позднее связывание

или «что означает foo.Bar(x)?»

1. Иерархия типов сводится к конкретной реализации в каждом случае (часто делается через vtable ) и часто допускает явную ссылку на реализацию базовых классов.
   • Концептуально вы смотрите на наиболее конкретный тип, который foo находится на месте вызова. Если он имеет реализацию Bar для вызываемого параметра x, если не выбран родительский элемент foo, и процесс повторяется.
   • Примеры: C ++ / Java / C #, « Simula style » часто используется.
2. Чистая передача сообщений. Код в foo, который обрабатывает сообщения с именем «Bar», должен принять x. Только имя имеет значение, а не какие-либо предположения, которые сайт мог сделать о том, каким должен был быть Бар. В отличие от предыдущего стиля, в котором рассматриваемый метод представлял собой Bar, который, как известно, определен во всем, что было известно об иерархии типов, определенной во время компиляции (хотя точное место в иерархии оставлено до времени выполнения).
   • Примеры: Objective-C / Ruby, « Smalltalk style » часто используется.

1 часто используется в статически типизированных средах, где это ошибка, проверяется во время компиляции на отсутствие такой реализации. Кроме того, языки часто различают Bar (x) и Bar (y), если x и y - разные типы. Это перегрузка методов, и результирующие методы с одинаковыми именами рассматриваются как совершенно разные.

2 часто используется в динамических языках (которые имеют тенденцию избегать перегрузки методов), так как возможно, что во время выполнения тип foo не имеет «обработчика» для сообщения с именем «Bar», разные языки обрабатывают это по-разному пути.

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

Наследование / повторное использование

или «Откуда берутся дети?»

1. На основе классов
   • Реализации методов организованы в группы называется классы. Когда требуется наследование реализации, определяется класс, который расширяет родительский класс. Таким образом, он получает все раскрытые аспекты родительского (как поля, так и методы) и может изменить некоторые / все эти аспекты, но не может удалить любые. Вы можете добавлять и обновлять, но не удалять.
   • Примеры: C ++ / Java / C # (обратите внимание, что используют SmallTalk и Simula)
2. На основе прототипов
   • Любой экземпляр объекта - это просто набор идентифицированных методов (обычно идентифицируемых по имени) и состояния в форме (снова именованных) полей. Всякий раз, когда требуется новый экземпляр этого типа, можно использовать существующий экземпляр для клонирования нового. Этот новый класс сохраняет копию состояния и методов предыдущего класса, но затем может быть изменен для удаления, добавления или изменения существующих именованных полей и методов.
   • Примеры: Self / JavaScript

Снова 1 имеет тенденцию происходить в статических языках, 2 в динамике, хотя это ни в коем случае не является требованием, они просто поддаются стилю.

Интерфейс или класс на основе

или «что или как?»

1. Интерфейсы перечисляют требуемые методы. Это контракт
   • Примеры: VB6
2. Методы списка классов, которые требуются, но могут при желании предоставить их реализацию
   • Примеры: Simula

Это очень не бинарный выбор. Большинство языков на основе классов допускают концепцию абстрактных методов (еще не реализованных). Если у вас есть класс, в котором все методы являются абстрактными (называемыми в C ++ чисто виртуальными), то этот класс в значительной степени представляет собой интерфейс, хотя и тот, который, возможно, также определил некоторое состояние (поля). Настоящий Интерфейс не должен иметь состояния (поскольку он определяет только , что возможно, а не как это происходит.

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

Single или Multiple Inheritance

или «Кто такой папа?»

1. Одиночный
   • Только один тип может быть родительским для другого. В приведенной выше форме на основе классов вы можете расширить (взять реализация из) только одного типа. Обычно эта форма включает в себя концепцию интерфейсов как первоклассных аспектов языка, чтобы восполнить это.
   • Преимущества включают более чистые метаданные и самоанализ, более простые правила языка.
   • осложнения включают усложнение внедрения полезных методов в область действия (например, MixIns и методы расширения решить эту проблему)
   • Примеры: C # / java
2. Несколько - вы можете расширять несколько классов
   • преимущества включают некоторые структуры легче моделировать и проектировать
   • . ​​Сложности включают сложные правила разрешения коллизий, особенно когда существуют перегруженные методы, которые могут принимать родительский тип.
   • Примеры: C ++ / Eiffel

Этот вопрос вызывает серьезные споры, тем более что он является ключевым отличием между реализацией ООП в C ++ и многими современными статически типизированными языками, которые воспринимаются как возможные преемники, такие как c # и java.

Изменчивость

или «что вы хотите со мной сделать?»

1. Изменяемые
   • Объекты, однажды созданные, могут изменить свое состояние .
2. Imutable
   • Однажды созданные объекты не могут быть изменены.

Зачастую это не все или ничего, это просто значение по умолчанию (наиболее часто используемые языки ООП по умолчанию изменяются по умолчанию). Это может оказать большое влияние на структуру языка. Многие в основном функциональные языки, включающие функции ООП, по умолчанию устанавливают неизменное состояние объектов.

«Чистота» их ООП

или «Является ли все объектом?»

1. Абсолютно все в системе рассматривается как объект (возможно, даже вплоть до самих методов которые являются просто другим типом объекта и могут взаимодействовать так же, как и другие объекты).
   • Примеры: SmallTalk
2. Не все является объектом, вы не можете передавать сообщения всем (хотя система может перепрыгивать через обручи, чтобы сделать это кажется, что вы можете)
   • Примеры: C ++ / C # / Java (см. примечание *)

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

• В отношении Java / C # система autoboxing (или в c # ) позволяет обрабатывать, синтаксически любую переменную, как если бы это был объект, но на самом деле это не так, и это проявляется в таких областях, как попытка блокировки автоматически помещаемого объекта (отклонено компилятором, поскольку это будет явной ошибкой).

Статический или Динамический

или «Кем вы себя считаете?»

Гораздо более распространенный аспект языкового дизайна, и здесь не один, но присущий выбор на это решение влияют многие аспекты ООП, как упоминалось ранее.

Только аспекты полиморфного позднего связывания могут зависеть от:

• Тип объекта, которому передается сообщение (во время компиляции / во время выполнения)
• The тип параметра ( s ), который передается (во время компиляции / во время выполнения)

Чем динамичнее язык, тем более сложными становятся эти решения, но наоборот тем больше вводит пользователь языка, а не разработчик языка в решении. Давать примеры здесь было бы несколько глупо, поскольку статически типизированные языки могут быть модифицированы для включения динамических аспектов (например, c # 4.0).