Multiple Inheritance in Java

Ever since Java 8 introduced default interface methods, I felt there had to be a way to use it for multiple inheritance. I have never needed it, but I was bored for a bit today, so decided to try the following idea:

  • Create a non-public class XData to hold the fields the interface needs to work with, and a public interface X in the same X.java source file
  • The interface has one virtual method getXData() that returns the XData instance
  • The remaining interface methods are default methods that call getXData() to read and write the fields as necessary to perform some useful operations.
  • Create another interface Y and class YDatain the same pattern
  • Create a class XY that implements both interfaces X and Y
  • The class XY has XData and YData fields, which are returned by getXData() and getYData(). These are the only two interface methods XY is required to implement.
  • I didn't bother in my example, but XY would have to decide how to implement the Object methods hashCode, equals, and toString. These methods cannot be implemented by interfaces (but they could be implemented in XData and YData classes if desired)

The end result is the XY class is an instance of both X and Y interfaces, and inherits the encapsulated behaviors of both X and Y default methods - multiple inheritance by any reasonable measure.

Polymorphism, Encapsulation, Data Abstraction and Inheritance in Object-Oriented Programming

Object-Oriented programming refers to the concept in high-level languages, such as Java and Python that uses Objects and classes in their implementations. OOP has four major building blocks which are, Polymorphism, Encapsulation, Abstraction, and Inheritance. There are other programming paradigms, such as Procedural programming in which code is written sequentially.

Python and Java are multi-paradigm high-level, programming languages. This means they support both OOP and procedural programming. A programmer decides on the paradigm to use based on their expertise and the problems they're trying to solve. However, there is no debate that OOP makes programming easier, faster, more dynamic, and secure. This is a major reason Java and Python are two fo the top most popular programming languages in the world today

Shadow Roots and Inheritance

There is a helluva gotcha with styling a <details> element, as documented here by Kitty Guiraudel. It’s obscure enough that you might never run into it, but if you do, I could see it being very confusing (it would confuse me, at least).

Perhaps you’re aware of the shadow DOM? It’s talked about a lot in terms of web components and comes up when thinking in terms of <svg> and <use>. But <details> has a shadow DOM too:

<details>
  #shadow-root (user-agent)
  <slot name="user-agent-custom-assign-slot" id="details-summary">
    <!-- <summary> reveal -->
  </slot>
  <slot name="user-agent-default-slot" id="details-content">
    <!-- <p> reveal -->
  </slot>

  <summary>System Requirements</summary>
  <p>
    Requires a computer running an operating system. The computer must have some
    memory and ideally some kind of long-term storage. An input device as well
    as some form of output device is recommended.
  </p>
</details>

As Amelia explains, the <summary> is inserted in the first shadow root slot, while the rest of the content (called “light DOM”, or the <p> tag in our case) is inserted in the second slot.

The thing is, none of these slots or the shadow root are matched by the universal selector *, which only matches elements from the light DOM. 

So the <slot> is kind of “in the way” there. That <p> is actually a child of the <slot>, in the end. It’s extra weird, because a selector like details > p will still select it just fine. Presumably, that selector gets resolved in the light DOM and then continues to work after it gets slotted in.

But if you tell a property to inherit, things break down. If you did something like…

<div>
  <p></p>
</div>
div {
  border-radius: 8px;
}
div p {
  border-radius: inherit;
}

…that <p> is going to have an 8px border radius.

But if you do…

<details>
  <summary>Summary</summary>
  <p>Lorem ipsum...</p>
</details>
details {
  border-radius: 8px;
}
details p {
  border-radius: inherit;
}

That <p> is going to be square as a square doorknob. I guess that’s either because you can’t force inheritance through the shadow DOM, or the inherit only happens from the parent which is a <slot>? Whatever the case, it doesn’t work.

Direct Link to ArticlePermalink


The post Shadow Roots and Inheritance appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

inherit, initial, unset, revert

There are four keywords that are valid values for any CSS property (see the title). Of those, day to day, I’d say I see the inherit used the most. Perhaps because it’s been around the longest (I think?) but also because it makes logical sense (“please inherit your value from the next parent up that sets it”). You might see that with an override of a link color, for example.

<footer>
  ©2012 Website — <a href="/contact">Contact</a>
</footer>
/* General site styles */
a {
  color: blue;
}

footer {
  color: white;
}
footer a {
  color: inherit;
}

That’s a decent and elegant way to handle the fact that you want the text and links in the footer to be the same color without having to set it twice.

The others behave differently though…

  • initial will reset the property back to the spec default.
  • unset is weird as heck. For a property that is inherited (e.g. color) it means inherit, and for a property that isn’t inherited (e.g. float) it means initial. That’s a brain twister for me such that I’ve never used it.
  • revert is similarly weird. Same deal for inherited properties, it means inherit. But for non-inherited properties it means to revert to the UA stylesheet. Kinnnnnda useful in that reverting display, for example, won’t make a <p> element display: inline; but it will remain a sensible display: block;.

PPK covered all this in more detail.

I’m glad he found my whining about all this:

Chris Coyier argues we need a new value which he calls default. It reverts to the browser style sheet in all cases, even for inherited properties. Thus it is a stronger version of revert. I agree. This keyword would be actually useful.

Amen. We have four properties for fiddling with the cascade on individual properties, but none that allow us to blast everything back to the UA stylesheet defaults. If we had that, we’d have a very powerful tool for starting fresh with styles on any given element. In one sense: scoped styles!

PPK has a fifth value he thinks would be useful: cascade. The idea (I suppose) is it kinda acts like currentColor except for any property. Sort of like a free variable you don’t have to define that gives you access to what the cascaded value would have been, except you’re going to use it in some other context (like a calculation).


The post inherit, initial, unset, revert appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

What Are the Differences Between Interfaces and Abstract Classes in 2021?

What you are reading is the fifth in a series of articles titled "Stranger things in Java", inspired by the contents of my book "Java for Aliens". These articles are dedicated to insights into the Java language. Better understanding the topics we use every day will allow us to master Java coding in even the most difficult scenarios.

The definitions for abstract class and interface have evolved since version 8 of Java, and knowing how the two now differ and interact is crucial. An understanding of their key differences will help users best work with these tools to leverage their full potential. 

Stranger Things in Java: Constants

What you are reading is the fourth in a series of articles titled "Stranger things in Java", inspired by the contents of my book "Java for Aliens". These articles are dedicated to insights of the Java language. Deepening the topics we use every day will allow us to master the Java coding even in the strangest scenario.

Introduction

In this article, we will explore some scenarios involving the use of constants where even experienced programmers may have doubts. Although the topic may be well known, not everyone has explored particular scenarios such as solving multiple inheritance in presence of homonymous constants. Strengthening one's theoretical basis is essential to be able to program with confidence.

Scala vs. Kotlin: Multiple Inheritance and the Diamond Problem

Inheritance is one of the basic tenets of Object-Oriented Programming, along with encapsulation and polymorphism. Alongside simple inheritance, there is multiple inheritance:

Multiple inheritance is a feature of some object-oriented computer programming languages in which an object or class can inherit characteristics and features from more than one parent object or parent class. It is distinct from single inheritance, where an object or class may only inherit from one particular object or class.
Wikipedia

C++ is famous for allowing multiple inheritance and describing the diamond problem. It states that there’s an issue when a child class inherits from multiple classes that have the same method.

Why Do We Need an Interface in OOP?

Most of us feel confused about the usefulness of interfaces at a first glance. We have questions like “Why do we need interfaces?" and “What is the advantage of using interfaces?" In this blog, we will try to find the answers to these questions.

Let’s begin with a simple example. Assume that you are a student and need to prepare for an exam. You know that there will be distractions during your exam preparation. We will use mobile applications and friends as our example. Let’s describe each as a class:

How to Create Basic Inheritance in JavaScript Constructors

There are four ways to create an object in JavaScript. They are as follows:

  1. Object as literal
  2. Constructor Invocation Pattern
  3. The create() method
  4. Using class after ES6

The implementation of inheritance varies according to the object creation method. In this post, I am going to explain creating inheritance between a function constructor.