# superclass

Published articles for superclass.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Abstract and Open Classes

DevFeed: [Abstract and Open Classes](<https://devfeed.tech/articles/abstract-and-open-classes-25047.md>)

Original publisher: [Read original article](<https://typealias.com/start/kotlin-abstract-and-open-classes/>)

Author: author@typealias.com (Dave Leeds)

Published: 2023-08-21T00:00:00Z

Content type: tutorial

Language: en

Sources: [Dave Leeds on Kotlin - typealias.com](<https://devfeed.tech/sources/dave-leeds-on-kotlin-typealias-com.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [interfaces](<https://devfeed.tech/topics/interfaces.md>)

Tags: [abstract-class](<https://devfeed.tech/tags/abstract-class.md>), [classes](<https://devfeed.tech/tags/classes.md>), [compare](<https://devfeed.tech/tags/compare.md>), [delegation](<https://devfeed.tech/tags/delegation.md>), [extend](<https://devfeed.tech/tags/extend.md>), [function](<https://devfeed.tech/tags/function.md>), [implement](<https://devfeed.tech/tags/implement.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [interface](<https://devfeed.tech/tags/interface.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [introduction](<https://devfeed.tech/tags/introduction.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [learn-to-program](<https://devfeed.tech/tags/learn-to-program.md>), [open-class](<https://devfeed.tech/tags/open-class.md>), [polymorphism](<https://devfeed.tech/tags/polymorphism.md>), [programming](<https://devfeed.tech/tags/programming.md>), [retro](<https://devfeed.tech/tags/retro.md>), [speed](<https://devfeed.tech/tags/speed.md>), [subclass](<https://devfeed.tech/tags/subclass.md>), [superclass](<https://devfeed.tech/tags/superclass.md>)

### AI overview

A tutorial chapter explaining how to extend open and abstract classes to create subtypes and share general code. It compares this approach with interfaces and delegation, highlighting that each has advantages and disadvantages.

### Source excerpt

In Chapter 12, we saw how we could use interfaces to create subtypes, and in the last chapter, we saw how we could use delegation with interfaces in order to share general code among specific classes. In this chapter, we'll learn how we can extend open and abstract classes to accomplish these same things with a different approach. Each approach has its advantages and disadvantages, so we'll also look at how they compare to one another.

## Enum classes in Kotlin

DevFeed: [Enum classes in Kotlin](<https://devfeed.tech/articles/enum-classes-in-kotlin-39330.md>)

Original publisher: [Read original article](<https://kt.academy/article/kfde-enum>)

Published: 2023-02-01T00:01:00Z

Content type: tutorial

Language: en

Sources: [Kt. Academy](<https://devfeed.tech/sources/kt-academy.md>)

Topics: [enum class](<https://devfeed.tech/topics/enum-class.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>)

Tags: [abstract-class](<https://devfeed.tech/tags/abstract-class.md>), [class](<https://devfeed.tech/tags/class.md>), [constructor](<https://devfeed.tech/tags/constructor.md>), [enum](<https://devfeed.tech/tags/enum.md>), [enum-class](<https://devfeed.tech/tags/enum-class.md>), [enums](<https://devfeed.tech/tags/enums.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [property](<https://devfeed.tech/tags/property.md>), [superclass](<https://devfeed.tech/tags/superclass.md>), [workshop-learning-programming](<https://devfeed.tech/tags/workshop-learning-programming.md>)

### AI overview

This Kotlin tutorial explains how to define and use enum classes to represent finite sets of values. It covers enum values and their order, companion object utilities, exhaustive when conditions, stored state, and custom methods.

### Source excerpt

What are enum classes in Kotlin and how do we use them.

## Effective Kotlin Item 36: Prefer composition over inheritance

DevFeed: [Effective Kotlin Item 36: Prefer composition over inheritance](<https://devfeed.tech/articles/effective-kotlin-item-36-prefer-composition-over-inheritance-39274.md>)

Original publisher: [Read original article](<https://kt.academy/article/ek-composition>)

Published: 2021-04-25T00:00:00Z

Content type: article

Language: en

Sources: [Kt. Academy](<https://devfeed.tech/sources/kt-academy.md>)

Topics: [Inheritance](<https://devfeed.tech/topics/inheritance.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [reuse](<https://devfeed.tech/topics/reuse.md>), [superclass](<https://devfeed.tech/topics/superclass.md>)

Tags: [approach](<https://devfeed.tech/tags/approach.md>), [behavior](<https://devfeed.tech/tags/behavior.md>), [hierarchy](<https://devfeed.tech/tags/hierarchy.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [object](<https://devfeed.tech/tags/object.md>), [oop](<https://devfeed.tech/tags/oop.md>), [reuse](<https://devfeed.tech/tags/reuse.md>), [superclass](<https://devfeed.tech/tags/superclass.md>), [workshop-learning-programming](<https://devfeed.tech/tags/workshop-learning-programming.md>)

### AI overview

The article argues that inheritance should primarily model a clear "is a" relationship and can be problematic when used mainly for code extraction or reuse. It presents class composition as a safer and more explicit alternative, while acknowledging that composition requires additional code.

### Source excerpt

Years of OOP made us overuse inheritance. Instead, we should more often use a composition that is safer and more explicit. More often, but not always...

## Effective Class Delegation

DevFeed: [Effective Class Delegation](<https://devfeed.tech/articles/effective-class-delegation-27061.md>)

Original publisher: [Read original article](<https://zsmb.co/effective-class-delegation/>)

Author: Márton Braun

Published: 2020-09-29T20:00:00Z

Content type: tutorial

Language: en

Sources: [zsmb.co](<https://devfeed.tech/sources/zsmb-co.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Inheritance](<https://devfeed.tech/topics/inheritance.md>), [Java](<https://devfeed.tech/topics/java.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [bytecode](<https://devfeed.tech/tags/bytecode.md>), [delegation](<https://devfeed.tech/tags/delegation.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [interface](<https://devfeed.tech/tags/interface.md>), [java](<https://devfeed.tech/tags/java.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [marton-braun](<https://devfeed.tech/tags/marton-braun.md>), [override](<https://devfeed.tech/tags/override.md>), [subclass](<https://devfeed.tech/tags/subclass.md>), [superclass](<https://devfeed.tech/tags/superclass.md>), [zsmb](<https://devfeed.tech/tags/zsmb.md>), [zsmb-co](<https://devfeed.tech/tags/zsmb-co.md>), [zsmb13](<https://devfeed.tech/tags/zsmb13.md>), [zsmbco](<https://devfeed.tech/tags/zsmbco.md>)

### AI overview

This tutorial explains how Kotlin class delegation can implement an interface by forwarding calls to a contained object. It contrasts this concise approach with Java solutions motivated by Effective Java's recommendation to favor composition over inheritance.

### Source excerpt

One of the most significant items of the Effective Java book is Item 18: Favor composition over inheritance. Let's see how Kotlin promotes this with class delegation.

## Covariance

DevFeed: [Covariance](<https://devfeed.tech/articles/covariance-25011.md>)

Original publisher: [Read original article](<https://typealias.com/concepts/covariance/>)

Author: author@typealias.com (Dave Leeds)

Published: 2017-11-14T00:00:00Z

Content type: tutorial

Language: en

Sources: [Dave Leeds on Kotlin - typealias.com](<https://devfeed.tech/sources/dave-leeds-on-kotlin-typealias-com.md>)

Topics: [generics](<https://devfeed.tech/topics/generics.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Polymorphism](<https://devfeed.tech/topics/polymorphism.md>)

Tags: [classes](<https://devfeed.tech/tags/classes.md>), [contravariance](<https://devfeed.tech/tags/contravariance.md>), [covariance](<https://devfeed.tech/tags/covariance.md>), [generic](<https://devfeed.tech/tags/generic.md>), [generics](<https://devfeed.tech/tags/generics.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [programming](<https://devfeed.tech/tags/programming.md>), [subtype](<https://devfeed.tech/tags/subtype.md>), [superclass](<https://devfeed.tech/tags/superclass.md>), [variance](<https://devfeed.tech/tags/variance.md>)

### AI overview

This tutorial explains covariance in type systems, focusing on how subtype relationships behave with generic types. It uses Kotlin examples to distinguish covariant read-only types from invariant mutable types, shows how to declare covariance with the out annotation, and discusses related constraints involving function arguments, properties, and inheritance.

### Source excerpt

On the surface, subtypes seem straightforward. Most programmers who write object-oriented code are familiar with the concept of inheritance, and how you can pass off a subclass as if it were its superclass. But subtyping rules aren't always as intuitive when you start working with generics. What is Covariance? Covariance describes a relationship between two sets of types where they both subtype in the same direction. For example, for our first set of types, here are two classes, A and B, where B is a subtype of A:

## Ruby Duck Typing, Dynamic Dispatch, and Singleton Classes

DevFeed: [Ruby Duck Typing, Dynamic Dispatch, and Singleton Classes](<https://devfeed.tech/articles/i-object-21038.md>)

Original publisher: [Read original article](<https://jakeyesbeck.com/2015/08/23/ruby-objects/>)

Published: 2015-08-23T12:00:00Z

Content type: tutorial

Language: en

Sources: [Jake Yesbeck](<https://devfeed.tech/sources/jake-yesbeck.md>)

Topics: [Ruby](<https://devfeed.tech/topics/ruby.md>), [coding](<https://devfeed.tech/topics/coding.md>)

Tags: [class](<https://devfeed.tech/tags/class.md>), [coding](<https://devfeed.tech/tags/coding.md>), [object](<https://devfeed.tech/tags/object.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [superclass](<https://devfeed.tech/tags/superclass.md>)

### AI overview

This tutorial explains Ruby's duck typing and dynamic dispatch, then shows how singleton classes store methods specific to individual objects and affect method lookup.

### Source excerpt

I am lucky enough to work with wonderfully talented people every single day. This is a guest post by one of my magnificent coworkers, Kristján Pétursson. Thank you for allowing me to share this knowledge with everyone! This post is adapted from my answer to this Stack Overflow question. If you want to start from the beginning of the universe and build out, go read that one. If you prefer to start with something you can touch and work backwards, here we go. Ruby likes ducks. Which is to say that when we're coding, and we have an object, we don't particularly care what kind of object it is, so long as it responds to the messages we send it. It might be a Duck or a Child or a Doctor, and as long as when we call #quack we hear a noise, all is well. That's called Duck Typing, and Ruby digs it. So if we have some arbitrary object and we ask it to #quack, the Ruby interpreter needs to figure out where the object's #quack method is. Nothing's been compiled, and Ruby lets you define methods pretty much any place or time you like, so #quack needs to be looked up at runtime. That's called Dynamic dispatch, and it's how Ruby handles ducks. Now for the thing we can touch; let's make a Duck class Duck def quack puts "Quack, I say!" end end duck = Duck.new duck.quack #=> Quack, I say! Surely, this is no surprise. You've done this in the past, or quieter things like it, and you understand just fine that a method called on duck will be found in Duck. But we less frequently do things like: def duck.quack puts "I'm tired of quacking." end duck.quack #=> I'm tired of quacking. other_duck = Duck.new other_duck.quack #=> Quack, I say! Hm, so if we can just redefine duck.quack without messing up other_duck, where is the second #quack method? It turns out every object has a Singleton Class where it can stash all its personal possessions. Other words for singleton class include metaclass, eigenclass, and virtual class, but Ruby implements a method called #singleton_class, so we'll use that