# Inheritance Published articles for Inheritance. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Inheritance and Composition in Python DevFeed: [Inheritance and Composition in Python]() Original publisher: [Read original article]() Author: Stephen Gruppetta Published: 2026-05-30T06:49:08Z Content type: tutorial Language: en Sources: [The Palindrome]() Topics: [Object-oriented programming (OOP)](), [Python](), [Inheritance]() Tags: [how-to](), [inheritance](), [oop](), [python]() ### AI overview A tutorial about inheritance and composition in Python. ### Source excerpt Inheritance and composition ## Managing Multi Table Inserts With Room DevFeed: [Managing Multi Table Inserts With Room]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2026-04-25T00:00:00Z Content type: article Language: en Sources: [Android Essence]() Topics: [Database](), [Object-oriented programming (OOP)](), [Polymorphism](), [interfaces](), [Dependency injection]() Tags: [android](), [database](), [dependency-injection](), [inheritance](), [interfaces](), [oop]() ### AI overview This article explains how to handle multi-table inserts in Room when entities have nested dependencies. It first considers separate DAO interfaces and a wrapper class, then shows how interface inheritance can centralize insertion logic and let dependent DAOs reuse it. ### Source excerpt A properly relational database may have a type that appears referenced multiple times. In my SpaceNerd playground app, that is the Country object. An Agency has a country, and an Agency is a dependency of a Launch, of a Space Station, and likely more types to come. How do I enforce that any time I insert an Agency, I also insert the Countries associated with it? That's what this blog post sets out to explore, and the answer is much simpler than I thought when I started. ## Object Oriented Programming - The Key Terms DevFeed: [Object Oriented Programming - The Key Terms]() Original publisher: [Read original article]() Author: Saurabh Dashora Published: 2026-03-24T08:38:43Z Content type: article Language: en Sources: [System Design Codex]() Topics: [Object-oriented programming (OOP)](), [Programming](), [Polymorphism](), [Inheritance](), [implementation](), [interface]() Tags: [abstraction](), [concepts](), [inheritance](), [maintainability](), [object-oriented](), [polymorphism](), [programming](), [security]() ### AI overview This tutorial introduces object-oriented programming through four principles: abstraction, encapsulation, inheritance, and polymorphism. It explains how abstraction hides implementation details, encapsulation controls access to data and methods, and inheritance supports reuse and hierarchical relationships. The supplied text begins its discussion of polymorphism but is truncated. ### Source excerpt The essential concepts ## Comparing Python and Kotlin for Backend Development DevFeed: [Comparing Python and Kotlin for Backend Development]() Original publisher: [Read original article]() Published: 2026-03-09T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [Python](), [backend-development](), [Development]() Tags: [backend-development](), [bugs](), [concurrency](), [inheritance](), [kotlin](), [python](), [switching](), [syntax](), [workshop-learning-programming]() ### AI overview The article compares Python and Kotlin for backend development, explaining why teams may switch to Kotlin and examining differences in performance, type and mutability safety, concurrency, syntax, and default arguments. ### Source excerpt Exploring the benefits of switching from Python to Kotlin for modern backend development. ## The Liskov Substitution Principle: Subtyping Contracts, Invariants, and History Properties DevFeed: [The Liskov Substitution Principle: Subtyping Contracts, Invariants, and History Properties]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-01-06T16:51:26Z Content type: article Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [Object-oriented programming (OOP)](), [Polymorphism]() Tags: [inheritance](), [oop](), [properties](), [solid-principles](), [subtype]() ### AI overview The article explains that the Liskov Substitution Principle is broader than simply treating it as subtyping. It presents requirements involving method preconditions and postconditions, supertype state invariants, and history properties. ### Source excerpt Happy New Year! I'm done with the newsletter hiatus and am going to try updating weekly again. To ease into things a bit, I'll try to keep posts a little more off the cuff and casual for a while, at least until Logic for Programmers is done. Speaking of which, v0.13 should be out by the end of this month. So for this newsletter I want to talk about the Liskov Substitution Principle (LSP). Last week I read A SOLID Load of Bull by cryptographer Loupe Vaillant, where he argues the SOLID principles of OOP are not worth following. He makes an exception for LSP, but also claims that it's "just subtyping" and further: If I were trying really hard to be negative about the Liskov substitution principle, I would stress that it only applies when inheritance is involved, and inheritance is strongly discouraged anyway. LSP is more interesting than that! In the original paper, A Behavioral Notion of Subtyping, Barbara Liskov and Jeannette Wing start by defining a "correct" subtyping as follows: Subtype Requirement: Let ϕ(x) be a property provable about objects x of type T. Then ϕ(y) should be true for objects y of type S where S is a subtype of T. From then on, the paper determine what guarantees that a subtype is correct.1 They identify three conditions: Each of the subtype's methods has the same or weaker preconditions and the same or stronger postconditions as the corresponding supertype method.2 The subtype satisfies all state invariants of the supertype. The subtype satisfies all "history properties" of the supertype. 3 e.g. if a supertype has an immutable field, the subtype cannot make it mutable. (Later, Elisa Baniassad and Alexander Summers would realize these are equivalent to "the subtype passes all black-box tests designed for the supertype", which I wrote a little bit more about here.) I want to focus on the first rule about preconditions and postconditions. This refers to the method's contract. For a function f, f.Pre is what must be true going into the function, and ## Bazel rule extensions DevFeed: [Bazel rule extensions]() Original publisher: [Read original article]() Author: Keith Smiley Published: 2025-10-31T17:00:00Z Content type: tutorial Language: en Sources: [Keith Smiley]() Topics: [Programming](), [Code](), [Polymorphism]() Tags: [bazel](), [extensions](), [inheritance]() ### AI overview This article explains Bazel 8.0 rule extensions, which let developers inherit and modify the behavior of existing rules without reimplementing them or maintaining a fork. It presents examples of post-processing rule outputs and manipulating providers, including a use case for consistent debug information across macOS and Linux. ### Source excerpt One of Bazel's best features is being able to easily write custom rules specific to your project. This is great for many use cases, but when what you really want is to enhance the behavior of existing rules, historically your options have been limited. What you would often do is wrap the existing rule in a macro, and add some number of custom rules to try and achieve the desired effect. When really what you want is to edit the existing rule, without having to re-implement all of its functionality (or maintain a fork). With Bazel 8.0, Googlers added a few new ways to extend existing rules that can help with this use case. In this post we will look at the aptly named rule extensions feature and some practical use cases I have found for it. Basic rule extensions Rule extensions allow you to inherit the behavior of an existing rule, similar to class inheritance in object-oriented programming. Importantly you can make a few modifications to augment the behavior of the rule to your liking. Let's say you have a rule that concatenates the given srcs: def _foo_impl(ctx): output = ctx.actions.declare_file("output.txt") ctx.actions.run_shell( inputs = ctx.files.srcs, outputs = [output], command = "cat {} > {}".format(" ".join([src.path for src in ctx.files.srcs]), output.path), ) return [DefaultInfo(files = depset([output]))] foo = rule( implementation = _foo_impl, attrs = { "srcs": attr.label_list(allow_files = True), }, ) Now let's assume in your project, you want the output file to be sorted. If you own the original rule you could of course change _foo_impl to handle that for you, but if you are relying on a more complex upstream rule, you may not have that luxury. Here's how we can extend this to post-process the file it produces: def _bar_impl(ctx): providers = ctx.super() # Invoke 'foo' and get the providers # NOTE: This assumes there's always only the provider we want. original_output = providers[0].files.to_list()[0] new_output = ctx.actions.declare_file("new_output.tx ## Android interview resources and a Compose Stability Inference guide DevFeed: [Android interview resources and a Compose Stability Inference guide]() Original publisher: [Read original article]() Author: Jorge Castillo Published: 2025-10-17T18:01:31Z Content type: opinion Language: en Sources: [Effective Android]() Topics: [Android](), [Jetpack Compose](), [Compiler](), [Inference](), [Algorithms]() Tags: [algorithms](), [android](), [compiler](), [compose-compiler](), [configuration](), [generics](), [inheritance](), [interfaces](), [jetpack-compose](), [reports](), [type-system]() ### AI overview A promotional newsletter post highlights an Android interview book with interview questions and practical tips, and a Compose Stability Inference guide covering the Compose compiler's stability type system, inference algorithms, compiler phases, and performance-related tooling. ### Source excerpt Exclusive price and resources for the newsletter subscribers only ## Inside Burst's Test Interceptors DevFeed: [Inside Burst's Test Interceptors]() Original publisher: [Read original article]() Author: Jesse Wilson Published: 2025-09-06T04:27:03Z Content type: article Language: en Sources: [Public Object]() Topics: [Kotlin Multiplatform](), [Compiler](), [Inheritance](), [Code]() Tags: [compiler](), [implementation](), [inheritance](), [kotlin](), [tests]() ### AI overview This article explains Burst's test interceptors, which provide JUnit-rule-like capabilities for connecting lifecycle behavior to test execution. It describes how Burst, a Kotlin Multiplatform library, uses a compiler plugin instead of reflection and handles interceptor ordering, inheritance, and independently compiled modules. ### Source excerpt I recently posted on the Cash Code Blog announcing Burst's new test interceptors feature. They are similar to JUnit rules in API and capability. A Small API A typical use case is connecting some lifecycle to a test's execution. Perhaps we want a chess engine to be available ## Six Principles for Writing Clean, Maintainable Classes DevFeed: [Six Principles for Writing Clean, Maintainable Classes]() Original publisher: [Read original article]() Author: Daniel Moka Published: 2025-04-19T05:00:55Z Content type: tutorial Language: en Sources: [Craft Better Software]() Topics: [clean-code](), [Code](), [Development](), [implementation](), [Inheritance]() Tags: [classes](), [clean-code](), [code](), [implementation](), [inheritance](), [quality](), [reuse]() ### AI overview This tutorial presents six principles for writing clean classes: use noun-based names, avoid unnecessary getters and setters, hide internal state, expose a focused API, order methods by call flow, and favor composition over inheritance. It argues that small, focused, intention-revealing classes are easier to change, test, and understand. ### Source excerpt 7 essential tips to produce maintainable and intention-revealing classes ## Sealed classes and interfaces in Kotlin DevFeed: [Sealed classes and interfaces in Kotlin]() Original publisher: [Read original article]() Published: 2023-09-04T00:01:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [sealed class](), [sealed interface](), [interface](), [abstract class](), [Inheritance](), [Polymorphism]() Tags: [inheritance](), [interface](), [kotlin](), [polymorphism](), [sealed](), [sealed-classes](), [sealed-interface](), [workshop-learning-programming]() ### AI overview This Kotlin tutorial explains sealed classes and sealed interfaces as restricted hierarchies whose direct subclasses are controlled. It contrasts them with regular interfaces and abstract classes, describes their package and module requirements, and explains their use in exhaustive expressions. ### Source excerpt What are sealed classes and interfaces in Kotlin and how do we use them. ## Abstract and Open Classes DevFeed: [Abstract and Open Classes]() Original publisher: [Read original article]() Author: author@typealias.com (Dave Leeds) Published: 2023-08-21T00:00:00Z Content type: tutorial Language: en Sources: [Dave Leeds on Kotlin - typealias.com]() Topics: [Code](), [interfaces]() Tags: [abstract-class](), [classes](), [compare](), [delegation](), [extend](), [function](), [implement](), [inheritance](), [interface](), [interfaces](), [introduction](), [kotlin](), [learn-to-program](), [open-class](), [polymorphism](), [programming](), [retro](), [speed](), [subclass](), [superclass]() ### 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. ## Interface Delegation DevFeed: [Interface Delegation]() Original publisher: [Read original article]() Published: 2023-03-06T00:15:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [interface](), [Inheritance](), [Polymorphism]() Tags: [delegates](), [delegation](), [inheritance](), [interface](), [kotlin](), [safety](), [workshop-learning-programming]() ### AI overview This tutorial explains Kotlin interface delegation through the delegation pattern, composition, and comparison with inheritance. It describes how delegation reuses implementations, supports polymorphic behavior, and reduces the additional code needed when specifying a delegate. ### Source excerpt One of the least known Kotlin features, that can be sometimes found really useful. ## Functional Classes in Clojure DevFeed: [Functional Classes in Clojure]() Original publisher: [Read original article]() Published: 2023-01-19T00:00:00Z Content type: article Language: en Sources: [Robert C. Martin](), [The Clean Code Blog]() Topics: [Clojure](), [Functional programming](), [Programming](), [Code](), [Polymorphism]() Tags: [clojure](), [code](), [functional-programming](), [inheritance](), [programming]() ### AI overview The article explains how class-like abstractions can be implemented in functional programming using Clojure. It presents a Dilithium Cloud example built from named functions, an internally defined data structure, dynamic type specifications, constructors, methods, and unit-test validation, while arguing that class syntax, inheritance, and polymorphic dispatch are not required. ### Source excerpt My previous blog seemed only to continue the confusion regarding classes in Functional Programming. Indeed, many people got quite irate. So perhaps a bit of code will help. Trigger Warning: Object Oriented Terminology. Dynamically Typed Language. Mixed Metaphors. Distracting Animations. To all the adherents of the Statically Typed Functional Programming religion: I know that you believe that Static Typing is an essential aspect of Functional Programming and that no mere dynamically typed language could ever begin to approach the heights and glory of The One True and Holy TYPED Functional Apotheotic Paradigm. But we lowly programmers quivering down here at the base of Orthanc can only hope to meekly subsist on the dregs that fall from on high. (R.I.P. Kirstie Alley OK, so, once again... A class is an intentionally named abstraction that consists of a set of narrowly cohesive functions that operate over an internally defined data structure. We do not need the class keyword. Nor do we need polymorphic dispatch. Nor do we need inheritance. A class is just a description, whether in full or in part, of an object. For example - it's time we talked about clouds (which I have looked at from both sides now; and do, in fact, understand pretty well). So... Here come your father's parentheses! (ns spacewar.game-logic.clouds (:require [clojure.spec.alpha :as s] [spacewar.geometry :as geo] [spacewar.game-logic.config :as glc])) (s/def ::x number?) (s/def ::y number?) (s/def ::concentration number?) (s/def ::cloud (s/keys :req-un [::x ::y ::concentration])) (s/def ::clouds (s/coll-of ::cloud)) (defn valid-cloud? [cloud] (let [valid (s/valid? ::cloud cloud)] (when (not valid) (println (s/explain-str ::cloud cloud))) valid)) (defn make-cloud ([] (make-cloud 0 0 0)) ([x y concentration] {:x x :y y :concentration concentration})) (defn harvest-dilithium [ms ship cloud] (let [ship-pos [(:x ship) (:y ship)] cloud-pos [(:x cloud) (:y cloud)]] (if (< (geo/distance ship-pos cloud-pos) glc/dilit ## Sealed classes in Kotlin DevFeed: [Sealed classes in Kotlin]() Original publisher: [Read original article]() Author: Florian Garcia Published: 2022-09-26T13:51:32Z Content type: tutorial Language: en Sources: [betclic-tech - Medium]() Topics: [Kotlin](), [interfaces](), [Inheritance](), [Code](), [Exception]() Tags: [classes](), [code](), [exception](), [inheritance](), [interfaces](), [kotlin](), [sealed](), [sealed-classes]() ### AI overview A tutorial explaining how Kotlin sealed classes and interfaces represent restricted class hierarchies. It shows how they help the compiler identify all supported cases and avoid missing-case handling when the hierarchy changes. ### Source excerpt In this article, we will talk about sealed classes and interfaces. What they are, what problem they solve and how we can leverage this in real life. The problem Let's take the following code: https://medium.com/media/f1f04b5ee8f0bfc98d41cad1fbd803a2/href Our code only handles two types of animals (cats and dogs). But the compiled code does not know that only those two types exist. This means we have to add this ugly else block in our when. This can be a real issue because you start to think about what to do in a situation that shouldn't exist but that will potentially exist in the future. For instance, say that tomorrow we add cows to the list of supported animals, the code will compile just fine because we have put the else block. We could change the else part to throw an exception but Kotlin does not have checked exceptions (so it's easy to forget to catch one), and thus we end up with runtime exceptions. That's a bit sad because we probably want to know at compile time that we need to handle this new case. Solution As you probably have guessed, the solution is sealed classes or interfaces. But what are they? From the Kotlin documentation: Sealed classes and interfaces represent restricted class hierarchies that provide more control over inheritance. All direct subclasses of a sealed class are known at compile time. No other subclasses may appear after a module with the sealed class is compiled. For example, third-party clients can't extend your sealed class in their code. Thus, each instance of a sealed class has a type from a limited set that is known when this class is compiled. If rephrased, this means that we can define a bounded hierarchy. One of the important things to know when working with sealed classes is that you cannot instantiate the sealed class; thus only the leaves of the structure exist at runtime (but you can use the interface as a type). When we develop applications that are not libraries, it is pretty rare to allow an abstract class / interfac ## Object-oriented or functional? Two ways to see the world DevFeed: [Object-oriented or functional? Two ways to see the world]() Original publisher: [Read original article]() Published: 2022-08-18T00:00:00Z Content type: opinion Language: en Sources: [Kt. Academy]() Topics: [Functional programming](), [Object-oriented programming (OOP)](), [Programming]() Tags: [fp](), [functional](), [immutability](), [inheritance](), [object-oriented](), [oop](), [polymorphism](), [recursion](), [workshop-learning-programming]() ### AI overview This opinion article compares object-oriented programming and functional programming as ways of thinking about program design, rather than merely collections of features. It uses different ways of viewing a bedroom--as objects or actions--to illustrate the distinction while acknowledging that modern languages commonly support both styles. ### Source excerpt The difference between the OOP and FP paradigms is deeply rooted in how we see the world. A few words on the philosophy of both approaches. ## Effective Kotlin Item 36: Prefer composition over inheritance DevFeed: [Effective Kotlin Item 36: Prefer composition over inheritance]() Original publisher: [Read original article]() Published: 2021-04-25T00:00:00Z Content type: article Language: en Sources: [Kt. Academy]() Topics: [Inheritance](), [Object-oriented programming (OOP)](), [Kotlin](), [reuse](), [superclass]() Tags: [approach](), [behavior](), [hierarchy](), [inheritance](), [kotlin](), [object](), [oop](), [reuse](), [superclass](), [workshop-learning-programming]() ### 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... ## Sealed goodies coming in Kotlin 1.5 DevFeed: [Sealed goodies coming in Kotlin 1.5]() Original publisher: [Read original article]() Author: Márton Braun Published: 2021-01-19T14:00:00Z Content type: article Language: en Sources: [zsmb.co]() Topics: [Kotlin](), [interfaces](), [Inheritance]() Tags: [android](), [classes](), [inheritance](), [interfaces](), [kotlin](), [marton-braun](), [pattern-matching](), [preview](), [sealed](), [sealed-classes](), [zsmb](), [zsmb-co](), [zsmb13](), [zsmbco]() ### AI overview This article explains Kotlin sealed classes and previews planned Kotlin 1.5 improvements, including relaxed inheritance restrictions and the introduction of sealed interfaces. It also discusses interoperability with newer Java sealed constructs. ### Source excerpt Kotlin 1.5 will bring exciting new features, among them improvements to sealed classes and an introduction of sealed interfaces. Let's take a look at what that will look like! ## Solid Relevance DevFeed: [Solid Relevance]() Original publisher: [Read original article]() Published: 2020-10-18T00:00:00Z Content type: opinion Language: en Sources: [Robert C. Martin](), [The Clean Code Blog]() Topics: [Architecture & Design](), [Code](), [Microservice](), [Polymorphism]() Tags: [code](), [gui](), [inheritance](), [microservices](), [sql]() ### AI overview The article argues that the SOLID principles remain relevant despite modern development practices such as microservices and reduced reliance on inheritance. It explains that software fundamentals have changed little and illustrates the Single Responsibility Principle by separating business rules, GUI code, SQL queries, communications protocols, and independently changing modules. The supplied text ends partway through the discussion. ### Source excerpt Recently I received a letter from someone with a concern. It went like this: For years the knowledge of the SOLID principle has been a standard part of our recruiting procedure. Candidates were expected to have a good working knowledge of these principles. Lately, however, one of our managers, who doesn't code much anymore, has questioned whether that is wise. His points were that the Open-Closed principle isn't very important anymore because most of the code we write isn't contained in large monoliths and making changes to small microservices is safe and easy. The Liskov Substitution Principle is long out of date because we don't focus on inheritance nearly as much as we did 20 years ago. I think we should consider Dan North's position on SOLID - "Just write simple code." I wrote the following letter in response: The SOLID principles remain as relevant to day as they were in the 90s (and indeed before that). This is because software hasn't changed all that much in all those years -- and that is because software hasn't change all that much since 1945 when Turing wrote the first lines of code for an electronic computer. Software is still if statements, while loops, and assignment statements -- Sequence, Selection, and Iteration. Every new generation likes to think that their world is vastly different from the generation before. Every new generation is wrong about that; which is something that every new generation learns once the next new generation comes along to tell them how much everything has changed. So let's walk through the principles, one by one. SRP) The Single Responsibility Principle. Gather together the things that change for the same reasons. Separate things that change for different reasons. It is hard to imagine that this principle is not relevant in software. We do not mix business rules with GUI code. We do not mix SQL queries with communications protocols. We keep code that is changed for different reasons separate so that changes to one part t ## Effective Class Delegation DevFeed: [Effective Class Delegation]() Original publisher: [Read original article]() Author: Márton Braun Published: 2020-09-29T20:00:00Z Content type: tutorial Language: en Sources: [zsmb.co]() Topics: [Kotlin](), [Inheritance](), [Java]() Tags: [android](), [bytecode](), [delegation](), [implementation](), [inheritance](), [interface](), [java](), [kotlin](), [marton-braun](), [override](), [subclass](), [superclass](), [zsmb](), [zsmb-co](), [zsmb13](), [zsmbco]() ### 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. ## Java Records: A Closer Look DevFeed: [Java Records: A Closer Look]() Original publisher: [Read original article]() Author: Alimate Published: 2020-02-09T00:00:00Z Content type: tutorial Language: en Sources: [Ali Dehghan - Kemikit]() Topics: [Java](), [Compiler](), [Kotlin](), [Scala]() Tags: [bytecode](), [class](), [classes](), [code](), [compiler](), [inheritance](), [java](), [scala]() ### AI overview A technical tutorial examines how Java 14 Records are represented under the hood, including their generated classes, accessors, constructors, methods, and bytecode. It also compares Records with Kotlin data classes and Scala case classes. ### Source excerpt How records are represented under the hood? ## Mongoid - Inheritance: change embedded document's type via nested attributes DevFeed: [Mongoid - Inheritance: change embedded document's type via nested attributes]() Original publisher: [Read original article]() Author: Lazarus Lazaridis Published: 2019-11-22T07:00:00Z Content type: tutorial Language: en Sources: [Lazarus Lazaridis]() Topics: [file](), [Rails](), [Polymorphism](), [Forms]() Tags: [class](), [code](), [create](), [how-to](), [inheritance](), [mongodb](), [mongoid](), [opensource](), [programming](), [rails](), [ruby](), [tutorial]() ### AI overview This tutorial examines problems that arise when changing the type of an embedded Mongoid document through nested attributes. Using a Rails console example with Book and BoardGame subclasses of Item, it demonstrates failed attribute assignments, leftover attributes, and incorrect validators caused by the in-memory object retaining its previous type. ### Source excerpt I recently faced some issues when trying to update a nested document's type via nested attributes using the mongoid gem. Bare with me if this sentence doesn't make any sense yet. Use case Suppose we have a document named Person that embeds a document that can be any of the types Book or BoardGame which inherit from the class Item. Item class Item include Mongoid::Document embedded_in :person, inverse_of: :item field :name end Book class Book < Item field :authors, type: Array end BoardGame class BoardGame < Item field :players, type: Integer end Person class Person include Mongoid::Document embeds_one :item, inverse_of: :person accepts_nested_attributes_for :item, allow_destroy: true end The problems To simplify the post I won't go with the scenario of building the forms and the controller actions to demonstrate the problems but instead I will simulate the behavior in the rails console. Let's create a Person with a Book as an Item. >> person = Person.create!({ item_attributes: { _type: "Book", name: "Jitterbug Perfume", authors: ["Tom Robbins"] } }) => # >> person.item => # Failing attribute assignments Let's try to change the person's item from Book to BoardGame with 5 players. >> person.update_attributes({ item_attributes: { _type: "BoardGame", name: "Ticket to Ride", players: 5 } }) Traceback (most recent call last): 1: from (irb):9 Mongoid::Errors::UnknownAttribute () message: Attempted to set a value for 'players' which is not allowed on the model Book. summary: Without including Mongoid::Attributes::Dynamic in your model and the attribute does not already exist in the attributes hash, attempting to call Book#players= for it is not allowed. This is also triggered by passing the attribute to any method that accepts an attributes hash, and is raised instead of getting a NoMethodError. resolution: You can include Mongoid:: ## Under the hood of Kotlin Class Delegation DevFeed: [Under the hood of Kotlin Class Delegation]() Original publisher: [Read original article]() Author: Jossi Wolf Published: 2019-04-09T13:20:12Z Content type: tutorial Language: en Sources: [Stories by Jossi Wolf on Medium]() Topics: [Kotlin](), [Code](), [Inheritance](), [Programming](), [software-development]() Tags: [android](), [api](), [bytecode](), [delegation](), [inheritance](), [interface](), [kotlin](), [proxy](), [stories]() ### AI overview This Kotlin tutorial explains how class delegation can expose an interface through a class without cluttering it with proxy methods. It also describes the generated delegation functions and their effect on compiled code size. ### Source excerpt I was told to add an image to the post, so here's one Photo by Jf Brou from Unsplash. Bonus points since Samoyeds are some of the cutest dogs out there! A piece of rather popular advice heard in software development is "favour composition over inheritance". I won't go into the details of why as there is an excellent chapter in "Effective Java" about it, as well as this nice article by Eric Lin. This article explores how class delegation can be useful and how it works under the hood. In our case, we had a custom view which should expose an interface looking like this: https://medium.com/media/2efb0d0125ffec7f388ee2df190bcf6a/href Now it was time to create the CanvasCapabilities implementation. https://medium.com/media/3d8b72ac99b28b99f39c95c882a69dce/href Of course, we don't want to start putting logic into our view just for the sake of exposing the interface through it, which meant that the view now had to act as a "proxy" (implementing the interface and calling the ArtboardCanvas ): https://medium.com/media/f3d51d082e7f23d725ef7efafb3fe131/href Not a nice solution, but at least we extracted the logic. The view was still cluttered though :( Class Delegation to the rescue Using the by keyword in Kotlin, properties and even classes can be delegated. You might know it from using lazy : https://medium.com/media/cbea2e6d1363f31e28552d9a8c87823e/href You can also delegate inheritance, which is what we are after. The usage looks like this: https://medium.com/media/5482d423d1b2a0fcff239f25c4ab31e9/href This delegates the methods from CanvasCapabilities to ArtboardCanvas . No more cluttering with "proxy" calls! Under The Hood Under the hood, Kotlin actually doesn't do any "black magic": It just generates a function which invokes the delegate. The bytecode, decompiled to Java looks like this: https://medium.com/media/34cf5d85a4bcf122bc98d74425e9a5dd/href If you have a lot of methods, that code will still be generated and adding to your compiled code's size, but at least it do ## Improving Android Tests with JUnit4 DevFeed: [Improving Android Tests with JUnit4]() Original publisher: [Read original article]() Author: info@jeroenmols.com (Jeroen Mols) Published: 2018-12-06T00:00:00Z Content type: tutorial Language: en Sources: [Jeroen Mols]() Topics: [Testing](), [Android](), [Kotlin](), [Mocking]() Tags: [android](), [blogs](), [cleancode](), [code](), [exception](), [exceptions](), [inheritance](), [kotlin](), [mocking](), [syntax](), [testing](), [tests]() ### AI overview This tutorial uses a quiz format to examine mistakes in Android tests. It explains replacing old JUnit3 syntax with JUnit4 annotations, using expected-exception annotations, and making mock-based tests fail for clearer, more specific reasons. ### Source excerpt Learning from analyzing code is one of the greatest ways to improve your skills. Can you spot the mistakes in the tests below? This post brings a fun little quiz for both testing gurus as novices, with a deep dive into the how and why of awesome tests. ## Modern C++ for C Programmers: Part 3 DevFeed: [Modern C++ for C Programmers: Part 3]() Original publisher: [Read original article]() Published: 2018-07-02T19:30:31Z Content type: tutorial Language: en Sources: [Bert Hubert's writings]() Topics: [C++](), [Inheritance](), [Polymorphism](), [Programming](), [Code]() Tags: [c](), [c-plus-plus](), [code](), [inheritance](), [polymorphism](), [programming](), [programming-language]() ### AI overview Part 3 of a tutorial on modern C++ for C programmers explains inheritance and polymorphism, including base and derived classes, virtual methods, runtime type metadata, and related overhead. ### Source excerpt Welcome back! In part 2 I discussed basic classes, threading, atomic operations, smart pointers, resource acquisition and (very briefly) namespaces. In this part we continue with further C++ features that you can use to spice up your code 'line by line', without immediately having to use all 1400 pages of 'The C++ Programming Language'. Various code samples discussed here can be found on GitHub. If you have any favorite things you'd like to see discussed or questions, please hit me up on @bert_hu_bert or bert@hubertnet. [Next page]()