<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>oop on Diogo Moreira</title><link>https://diogomoreira.dev/tags/oop/</link><description>Recent content in oop on Diogo Moreira</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Sun, 18 Feb 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://diogomoreira.dev/tags/oop/index.xml" rel="self" type="application/rss+xml"/><item><title>Sealed and Final in Java 17+</title><link>https://diogomoreira.dev/blog/sealed-and-final-in-java-17/</link><pubDate>Sun, 18 Feb 2024 00:00:00 +0000</pubDate><guid>https://diogomoreira.dev/blog/sealed-and-final-in-java-17/</guid><description>&lt;p&gt;Java 17 brought the &lt;strong&gt;Sealed Classes&lt;/strong&gt; feature, which allows greater control over how to structure a project&amp;rsquo;s class hierarchy. In this post, we&amp;rsquo;ll discuss this feature that permits classes and interfaces to have more control over their allowed subtypes.&lt;/p&gt;
&lt;p&gt;The keywords &lt;code&gt;sealed&lt;/code&gt;, &lt;code&gt;non-sealed&lt;/code&gt; and &lt;code&gt;permits&lt;/code&gt; are the ones to be used in the syntax of sealed classes in Java. When we mark a class as &lt;code&gt;sealed&lt;/code&gt;, it is as if we were marking it as &lt;code&gt;final&lt;/code&gt;, which does not allow other classes to extend it. So, we add classes that can extend a sealed class with the help of &lt;code&gt;permits&lt;/code&gt; keyword and then we list the permitted classes.&lt;/p&gt;</description></item></channel></rss>