Интерфейс-маркер (шаблон проектирования)
Интерфейс-маркер, маркер (англ. marker interface pattern ) — это шаблон проектирования, применяемый в языках программирования с проверкой типов во время выполнения. Шаблон предоставляет возможность связать метаданные (интерфейс) с классом даже при отсутствии в языке явной поддержки для метаданных.
Чтобы использовать эту модель, класс реализует интерфейс [1] («помечается интерфейсом»), а взаимодействующие с классом методы проверяют наличие интерфейса. В отличие от обычного интерфейса, который определяет функциональность (в виде объявлений методов и свойств), которой должен обладать реализуемый класс объектов, важен сам факт обладания класса маркером. Маркер лишь является признаком наличия определённого поведения у объектов класса, помеченного маркером. Разумеется, возможны и «смешанные» интерфейсы, однако при неаккуратном использовании они могут создавать путаницу.
Пример применения маркеров-интерфейсов в языке программирования Java является интерфейс Serializable . Класс должен реализовать этот интерфейс, чтобы показать, что его экземпляры могут быть записаны в ObjectOutputStream . Класс ObjectOutputStream имеет публичный метод writeObject() , который содержит ряд instanceof проверок возможности записи, одной из которых является интерфейс Serializable . Если вся серия проверок оканчивается неудачей, метод выбрасывает исключение NotSerializableException .
Другим примером является интерфейс INamingContainer, который определен в .NET Framework. INamingContainer определяет элемент управления контейнером, который создает новый идентификатор пространства имен в иерархии элементов управления объекта Page . [2] . Любой элемент управления, который реализует этот интерфейс, создает новое пространство имен, в котором обеспечивается уникальность всех идентификаторов атрибутов дочерних элементов управления в пределах всего приложения. При разработке шаблонных элементов управления необходимо реализовывать этот интерфейс, чтобы избежать конфликтов именования на странице.
Marker Interfaces in Java
The Kubernetes ecosystem is huge and quite complex, so it’s easy to forget about costs when trying out all of the exciting tools.
To avoid overspending on your Kubernetes cluster, definitely have a look at the free K8s cost monitoring tool from the automation platform CAST AI. You can view your costs in real time, allocate them, calculate burn rates for projects, spot anomalies or spikes, and get insightful reports you can share with your team.
Connect your cluster and start monitoring your K8s costs right away:
We rely on other people’s code in our own work. Every day.
It might be the language you’re writing in, the framework you’re building on, or some esoteric piece of software that does one thing so well you never found the need to implement it yourself.
The problem is, of course, when things fall apart in production — debugging the implementation of a 3rd party library you have no intimate knowledge of is, to say the least, tricky.
Lightrun is a new kind of debugger.
It’s one geared specifically towards real-life production environments. Using Lightrun, you can drill down into running applications, including 3rd party dependencies, with real-time logs, snapshots, and metrics.
Learn more in this quick, 5-minute Lightrun tutorial:
Slow MySQL query performance is all too common. Of course it is. A good way to go is, naturally, a dedicated profiler that actually understands the ins and outs of MySQL.
The Jet Profiler was built for MySQL only, so it can do things like real-time query performance, focus on most used tables or most frequent queries, quickly identify performance issues and basically help you optimize your queries.
Critically, it has very minimal impact on your server’s performance, with most of the profiling work done separately — so it needs no server changes, agents or separate services.
Basically, you install the desktop application, connect to your MySQL server, hit the record button, and you’ll have results within minutes:
DbSchema is a super-flexible database designer, which can take you from designing the DB with your team all the way to safely deploying the schema.
The way it does all of that is by using a design model, a database-independent image of the schema, which can be shared in a team using GIT and compared or deployed on to any database.
And, of course, it can be heavily visual, allowing you to interact with the database using diagrams, visually compose queries, explore the data, generate random data, import data or build HTML5 database reports.
The Kubernetes ecosystem is huge and quite complex, so it’s easy to forget about costs when trying out all of the exciting tools.
To avoid overspending on your Kubernetes cluster, definitely have a look at the free K8s cost monitoring tool from the automation platform CAST AI. You can view your costs in real time, allocate them, calculate burn rates for projects, spot anomalies or spikes, and get insightful reports you can share with your team.
Connect your cluster and start monitoring your K8s costs right away:
We’re looking for a new Java technical editor to help review new articles for the site.
1. Introduction
In this quick tutorial, we’ll learn about marker interfaces in Java.
2. Marker Interfaces
A marker interface is an interface that doesn’t have any methods or constants inside it. It provides run-time type information about objects, so the compiler and JVM have additional information about the object.
A marker interface is also called a tagging interface.
Though marker interfaces are still in use, they very likely point to a code smell, and we should use them carefully. The main reason for this is that they blur the lines of what an interface represents, since markers don’t define any behavior. Newer development favors annotations to solve some of the same problems.
3. JDK Marker Interfaces
Java has many built-in marker interfaces, such as Serializable, Cloneable, and Remote.
Let’s take the example of the Cloneable interface. If we try to clone an object that doesn’t implement this interface, the JVM throws a CloneNotSupportedException. Thus, the Cloneable marker interface is an indicator to the JVM that we can call the Object.clone() method.
In the same way, when calling the ObjectOutputStream.writeObject() method, the JVM checks if the object implements the Serializable marker interface. When this isn’t the case, a NotSerializableException is thrown. Therefore, the object isn’t serialized to the output stream.
4. Custom Marker Interface
Let’s create our own marker interface.
For example, we can create a marker that indicates whether an object can be removed from the database:
public interface Deletable
In order to delete an entity from the database, the object representing this entity has to implement our Deletable marker interface:
public class Entity implements Deletable < // implementation details >Let’s say that we have a DAO object with a method for removing entities from the database. We can write our delete() method so that only objects implementing our marker interface can be deleted:
public class ShapeDao < // other dao methods public boolean delete(Object object) < if (!(object instanceof Deletable)) < return false; >// delete implementation details return true; > >As we can see, we’re giving an indication to the JVM about the runtime behavior of our objects. If the object implements our marker interface, it can be deleted from the database.
5. Marker Interfaces vs. Annotations
By introducing annotations, Java provided us with an alternative to achieve the same results as the marker interfaces. Moreover, like marker interfaces, we can apply annotations to any class, and we can use them as indicators to perform certain actions.
So what’s the key difference?
Unlike annotations, interfaces allow us to take advantage of polymorphism. As a result, we can add additional restrictions to the marker interface.
For instance, let’s add a restriction that only a Shape type can be removed from the database:
In this case, our marker interface, DeletableShape, will look like this:
public interface DeletableShape extends Shape
Then our class will implement the marker interface:
public class Rectangle implements DeletableShape < // implementation details >Therefore, all DeletableShape implementations are also Shape implementations. Obviously, we can’t do that using annotations.
However, every design decision has trade-offs, and we can use polymorphism as a counter-argument against marker interfaces. In our example, every class extending Rectangle will automatically implement DeletableShape.
6. Marker Interfaces vs. Typical Interfaces
In the previous example, we could get the same results by modifying our DAO’s delete() method to test whether our object is a Shape or not, instead of testing whether it’s a Deletable:
public class ShapeDao < // other dao methods public boolean delete(Object object) < if (!(object instanceof Shape)) < return false; >// delete implementation details return true; > >So why create a marker interface when we can achieve the same results using a typical interface?
Let’s imagine that, in addition to the Shape type, we want to remove the Person type from the database as well. In this case, there are two options to achieve that.
The first option is to add an additional check to our previous delete() method to verify whether or not the object to delete is an instance of Person:
public boolean delete(Object object) < if (!(object instanceof Shape || object instanceof Person)) < return false; >// delete implementation details return true; >But what if we have more types that we want to remove from the database as well? Obviously, this won’t be a good option because we have to change our method for every new type.
The second option is to make the Person type implement the Shape interface, which acts as a marker interface. But is a Person object really a Shape? The answer is clearly no, and that makes the second option worse than the first one.
Consequently, although we can achieve the same results by using a typical interface as a marker, we’ll end up with a poor design.
7. Conclusion
In this article, we learned about marker interfaces and how to use them. Then we explored some built-in Java examples of this type of interface, and how the JDK uses them.
Next, we created our own marker interface and weighed it against using an annotation. Finally, we demonstrated why it’s good practice to use a marker interface in some scenarios instead of a traditional interface.
As always, the code can be found on GitHub.
Slow MySQL query performance is all too common. Of course it is. A good way to go is, naturally, a dedicated profiler that actually understands the ins and outs of MySQL.
The Jet Profiler was built for MySQL only, so it can do things like real-time query performance, focus on most used tables or most frequent queries, quickly identify performance issues and basically help you optimize your queries.
Critically, it has very minimal impact on your server’s performance, with most of the profiling work done separately — so it needs no server changes, agents or separate services.
Basically, you install the desktop application, connect to your MySQL server, hit the record button, and you’ll have results within minutes: