Мы прошли долгий путь, с тех дней когда мы в ручную писали SQL запросы в наших веб приложения. Инструменты, такие как Laravel’ий Eloquent ORM позволяют нам работать с базой данных на более высоком уровне, освобождают нас от деталей более низкого уровня — таких как синтаксис запросов и безопасность.
Вы хотя бы примерно представляете, сколько потратили денег на свой аккаунт в Steam? Попробуйте прикинуть сумму, пусть даже приблизительную — полезно будет помнить её, потому что сегодня мы поговорим об этом. Если вы, как я думаю, купили за много лет много разных игр, то эти затраты были приличными.
И несмотря на ту денежную и ностальгическую ценность, которую может иметь библиотека в Steam, после вашей смерти, в соответствии с действующим пользовательским соглашением Valve Corporation, ваш аккаунт фактически умрёт вместе с вами. При существующем состоянии вещей вы просто не можете оставить ваш аккаунт близкому другу или любимому человеку.
Читать полностью »
Привет! Представляю вашему вниманию перевод статьи A Curious Java Language Feature and How it Produced a Subtle Bug автора Lukas Eder.
Правила видимости в Java иногда могут быть слегка запутанными и непонятными. Как вы думаете, что будет выведено на экран после запуска этого кода?
package p;
import static p.A.x;
class A {
static String x = "A.x";
}
class B {
String x = "B.x";
}
class C {
String x = "C.x";
class D extends B {
void m() {
System.out.println(x);
}
}
}
public class X {
public static void main(String[] args) {
new C().new D().m();
}
}
Будет выведено:
B.xПотому, что:
Члены суперкласса B скрывают все вложенные элементы класса C, которые, в свою очередь, перекрывают статический импорт класса A.Эта статья посвящена созданию модели данных, которая красиво ложилась бы на SQL и содержала в себе «правильное» ООП наследование. Надо сказать, что эта задача возникала у меня в разное время на разных проектах, и решалась она там тоже по-разному. Названия подходов взяты из сложившейся на соответствующих проектах терминологии.
Читать полностью »
Аргументов достаточно много:
Альтернативой наследованию являются использование интерфейсов и композиция. (Интерфейсы давно используется в качестве альтернативы множественному наследованию, даже если в иерархии классов активно используется наследование.)
Декларируемым преимуществом наследование является отсутствие дублирования кода. В предметной области могут встречаться объекты с похожим или одинаковым набором свойств и методов, но имеющих частично или полностью разные поведение или механизмы реализации этого поведения. И в этом случае для устранения дублирование кода придется использовать иные механизмы.
А как можно решить эту задачу (отсутствие дублирования кода) в случае композиции и интерфейсов?
Этой теме и посвящена настоящая статья.
Читать полностью »
В большинстве реляционных баз данных, к сожалению, нет поддержки наследования, так что приходится реализовывать это вручную. В этой статье я хочу кратко показать, как реализовать такой подход к наследованию, как «single table inheritance», описанный в книге «Patterns of Enterprise Application Architecture» by Martin Fowler.
В соответствии с этим паттерном, нужно использовать общую таблицу для наследуемых моделей и в этой таблице добавить поле type, которое будет определять класс-наследника этой записи.
В этой статье будет использоваться следующая структура наследования моделей:
Car
|- SportCar
|- HeavyCar
Таблица `car` имеет следующую структуру:
CREATE TABLE `car` (
`id` int NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
`type` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
);
INSERT INTO `car` (`id`, `name`, `type`) VALUES (1, 'Kamaz', 'heavy'), (2, 'Ferrari', 'sport'), (3, 'BMW', 'city');
Модель Car можно сгенерировать с помощью Gii.
Читать полностью »
Рассмотрим, в качестве примера, следующую ситуацию. У нас имеется класс User с полями, описывающими пользователя. Имеется класс Phone, который является родительским для классов CellPhone и SatellitePhone. В классе User есть поле содержащее список телефонов пользователя. В целях уменьшения нагрузки на БД мы сделали этот список «ленивым». Он будет загружаться только по требованию.
public class User {
...
@OneToMany(fetch = FetchType.LAZY)
private List<Phone> phones = new ArrayList<Phone>();
public List<Phone> getPhones() {
return phones;
}
}
public class Phone {
...
}
public class CellPhone extends Phone {
...
}
public class SatellitePhone extends Phone {
...
}
В такой конфигурации при запросе списка телефонов конкретного пользователя мы можем получить как список проинициализированных объектов-телефонов (например, если они уже есть в кэше), так и список proxy-объектов.
В большинстве ситуаций нам не важно с чем именно мы работаем (реальным объектом или его proxy). При запросе какого-либо поля какого-либо объекта — proxy-объект автоматически проинициализируется, и мы получим ожидаемые данные. Но если нам нужно узнать тип объекта, то все идет наперекосяк.
Читать полностью »
В JavaScript существует множество разных способов наследования, классового и прототипного, фабричного и через примеси, прямого и непрямого, а так же гибриды нескольких методов. Но у Node.js есть его родной способ с применением util.inherits(ChildClass, ParentClass). До недавнего времени я использовал нодовский способ только для встроенных классов (когда нужно сделать своего наследника для EventEmitter, Readable/Writable Stream, Domain, Duffer и т.д.), а для моделирования предметной области применял общеупотребительные для всего JavaScript практики. И вот, впервые, понадобилось реализовать собственную иерархию системных классов, не наследников от встроенных, но и не классов предметной области, а классов, массово поражаемых в системном коде сервера приложений Impress. И простого использования util.inherits уже как-то не хватило, поискал я статьи и не найдя полностью всего, что мне нужно, изучил примеры наследования в исходниках самой ноды, подумал и сделал пример родного нодовского наследования себе на память и написал эту небольшую заметку, чтобы она, надеюсь, помогла еще и вам. Сразу предупреждаю, что реализация вызова метода родительского класса из переопределенного в дочернем классе метода, мне не очень нравится из-за громоздкости, поэтому, приветствую альтернативные способы и приглашаю коммитить их в репозиторий или в комментарии к этой заметке.
Эта публикация — ответ на текст «Решетчатое наследование», опубликованный хабрапользователем potan, с предложением альтернативы, на субъективный взгляд автора, более близкой к ООП с классами.
Читать полностью »
Наследование, при кажущейся простоте, часто приводит к сложным, сопротивляющимся изменениям структурам. Иерархии классов растут как самый настоящий лес.
Целью наследование является привязка кода (набора методов) к минимальному набору свойств сущности (как правило — объекта), которые он обеспечивает и которые ему требуются. Это упрощает повторное использование, тестирование и анализ кода. Но наборы свойств со временем становятся очень большими, начинают пересекаться нетривиальным образом. И в структуре классов появляются миксины и прочее множественное наследование.
Внести изменения в глубине иерархии становится проблематично, приходится думать заранее о «внедрении зависимостей», разрабатывать и использовать сложные инструменты рефакторинга.
Возможно ли всего этого избежать? Стоит попытаться — пусть методы будут привязаны к множеству характерных свойств объекта (тегов), а иерархия наследования выстраивается автоматически по вложенности этих множеств.
Пусть мы разрабатывает иерархию для игровых персонажей. Часть кода будет общая для всех персонажей — она привязана к пустому набору свойств. Код, отвечающий за их отображение будет представлен в виде вариантов для OpenGL и DirectX разных версий. Что-то будет зависеть от расы персонажа, что-то от наличия и вида магических способностей и тп. Теги персонажа первичны. Они перечисляются явно, а не наследуются. А реализация наследуется в зависимости от набора тегов (по вложенности). Таким образом умение стрелять из ПЗРК не окажется у кенгуру, потому что его унаследовали от пехотинца.
Идея такого подхода была предложена Дмитрием Кимом. Автор не стал ее воплощать в код, я попробую исправить это упущение.
Реализация такого подхода на Clojure, как обычно, на github.
Читать полностью »