# oop

Published articles for oop.

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

## Why Rider and ReSharper Were Slow to Start, and How Microsoft Helped Fix the Problem

DevFeed: [Why Rider and ReSharper Were Slow to Start, and How Microsoft Helped Fix the Problem](<https://devfeed.tech/articles/why-rider-and-resharper-were-slow-to-start-and-how-microsoft-helped-fix-the-problem-8801.md>)

Original publisher: [Read original article](<https://blog.jetbrains.com/dotnet/2026/09/09/why-rider-and-resharper-were-slow-to-start-and-how-microsoft-helped-fix-the-problem/>)

Author: Alexander Ulitin

Published: 2026-09-09T16:45:27Z

Content type: article

Language: en

Sources: [The JetBrains Blog](<https://devfeed.tech/sources/the-jetbrains-blog.md>)

Topics: [resharper](<https://devfeed.tech/topics/resharper.md>), [out-of-process](<https://devfeed.tech/topics/out-of-process.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [Microsoft](<https://devfeed.tech/topics/microsoft.md>), [telemetry](<https://devfeed.tech/topics/telemetry.md>)

Tags: [defender](<https://devfeed.tech/tags/defender.md>), [logs](<https://devfeed.tech/tags/logs.md>), [microsoft](<https://devfeed.tech/tags/microsoft.md>), [net-tools](<https://devfeed.tech/tags/net-tools.md>), [oop](<https://devfeed.tech/tags/oop.md>), [out-of-process](<https://devfeed.tech/tags/out-of-process.md>), [performance](<https://devfeed.tech/tags/performance.md>), [resharper](<https://devfeed.tech/tags/resharper.md>), [resharper-oop](<https://devfeed.tech/tags/resharper-oop.md>), [rider](<https://devfeed.tech/tags/rider.md>), [telemetry](<https://devfeed.tech/tags/telemetry.md>)

### AI overview

The article investigates slow ReSharper startup after its out-of-process architecture was introduced. Profiling identified Microsoft Defender scanning as the source of substantial first-launch latency, and describes a repeatable investigation tool built with input from Microsoft.

### Source excerpt

When we launched ReSharper's out-of-process (OOP) architecture, users reported slower startup times for IDEs using ReSharper on Windows. After profiling, the cause surprised us: Microsoft Defender was scanning our process for longer than we expected. This post is about what we found, what we learned working with Microsoft, and a tool we built that allows [...]

## Understanding Mixin Classes in Python

DevFeed: [Understanding Mixin Classes in Python](<https://devfeed.tech/articles/understanding-mixin-classes-in-python-4372.md>)

Original publisher: [Read original article](<https://realpython.com/courses/understanding-mixin-classes-in-python/>)

Author: Real Python

Published: 2026-07-14T14:00:00Z

Content type: tutorial

Language: en

Sources: [Real Python](<https://devfeed.tech/sources/real-python.md>)

Topics: [Python](<https://devfeed.tech/topics/python.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [how-to](<https://devfeed.tech/tags/how-to.md>), [oop](<https://devfeed.tech/tags/oop.md>), [python](<https://devfeed.tech/tags/python.md>), [tutorial](<https://devfeed.tech/tags/tutorial.md>), [video](<https://devfeed.tech/tags/video.md>)

### AI overview

A video course on using Python mixin classes to share reusable behavior across classes without creating rigid inheritance hierarchies. It explains multiple inheritance, stateful mixins, method resolution order, and common design considerations.

### Source excerpt

Learn how to write reusable Python mixin classes, distinguish them from abstract base classes, and steer clear of common pitfalls.

## Inheritance and Composition in Python

DevFeed: [Inheritance and Composition in Python](<https://devfeed.tech/articles/how-to-oop-in-python-like-a-pro-38807.md>)

Original publisher: [Read original article](<https://thepalindrome.org/p/how-to-oop-in-python-like-a-pro>)

Author: Stephen Gruppetta

Published: 2026-05-30T06:49:08Z

Content type: tutorial

Language: en

Sources: [The Palindrome](<https://devfeed.tech/sources/the-palindrome.md>)

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

Tags: [how-to](<https://devfeed.tech/tags/how-to.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [oop](<https://devfeed.tech/tags/oop.md>), [python](<https://devfeed.tech/tags/python.md>)

### 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](<https://devfeed.tech/articles/managing-multi-table-inserts-with-room-22825.md>)

Original publisher: [Read original article](<http://androidessence.com/multi-table-inserts/>)

Author: Adam McNeilly

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

Content type: article

Language: en

Sources: [Android Essence](<https://devfeed.tech/sources/android-essence.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [Polymorphism](<https://devfeed.tech/topics/polymorphism.md>), [interfaces](<https://devfeed.tech/topics/interfaces.md>), [Dependency injection](<https://devfeed.tech/topics/dependency-injection.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [database](<https://devfeed.tech/tags/database.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [oop](<https://devfeed.tech/tags/oop.md>)

### 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.

## 12 OOP Concepts EVERY Developer Should Know

DevFeed: [12 OOP Concepts EVERY Developer Should Know](<https://devfeed.tech/articles/12-oop-concepts-every-developer-should-know-33559.md>)

Original publisher: [Read original article](<https://blog.algomaster.io/p/12-oop-concepts-every-developer-should-know>)

Author: Ashish Pratap Singh

Published: 2026-02-12T04:27:26Z

Content type: tutorial

Language: en

Sources: [AlgoMaster Newsletter](<https://devfeed.tech/sources/algomaster-newsletter.md>)

Topics: [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Code](<https://devfeed.tech/topics/code.md>), [interfaces](<https://devfeed.tech/topics/interfaces.md>), [Polymorphism](<https://devfeed.tech/topics/polymorphism.md>), [App](<https://devfeed.tech/topics/app.md>)

Tags: [class](<https://devfeed.tech/tags/class.md>), [classes](<https://devfeed.tech/tags/classes.md>), [code](<https://devfeed.tech/tags/code.md>), [concepts](<https://devfeed.tech/tags/concepts.md>), [developer](<https://devfeed.tech/tags/developer.md>), [interface](<https://devfeed.tech/tags/interface.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [object-oriented](<https://devfeed.tech/tags/object-oriented.md>), [oop](<https://devfeed.tech/tags/oop.md>), [practical](<https://devfeed.tech/tags/practical.md>), [programming](<https://devfeed.tech/tags/programming.md>), [real-world](<https://devfeed.tech/tags/real-world.md>)

### AI overview

An introductory tutorial on object-oriented programming explains how classes, objects, and interfaces organize state and behavior. It uses real-world examples such as users, orders, payments, and payment gateways, and notes that these concepts are relevant to low-level design interviews.

### Source excerpt

Key Object-Oriented Programming Concepts

## The Liskov Substitution Principle: Subtyping Contracts, Invariants, and History Properties

DevFeed: [The Liskov Substitution Principle: Subtyping Contracts, Invariants, and History Properties](<https://devfeed.tech/articles/the-liskov-substitution-principle-does-more-than-you-think-25507.md>)

Original publisher: [Read original article](<https://buttondown.com/hillelwayne/archive/the-liskov-substitution-principle-does-more-than/>)

Author: Hillel Wayne

Published: 2026-01-06T16:51:26Z

Content type: article

Language: en

Sources: [Newsletter feed for Hillel Wayne's Newsletter](<https://devfeed.tech/sources/newsletter-feed-for-hillel-wayne-s-newsletter.md>)

Topics: [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [Polymorphism](<https://devfeed.tech/topics/polymorphism.md>)

Tags: [inheritance](<https://devfeed.tech/tags/inheritance.md>), [oop](<https://devfeed.tech/tags/oop.md>), [properties](<https://devfeed.tech/tags/properties.md>), [solid-principles](<https://devfeed.tech/tags/solid-principles.md>), [subtype](<https://devfeed.tech/tags/subtype.md>)

### 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

## A critical history of JavaScript's prototype-based design and later TypeScript and ES6 changes

DevFeed: [A critical history of JavaScript's prototype-based design and later TypeScript and ES6 changes](<https://devfeed.tech/articles/the-fall-of-javascript-35600.md>)

Original publisher: [Read original article](<https://www.yegor256.com/2025/12/28/fall-of-javascript.html>)

Author: Yegor Bugayenko (yegor256@gmail.com)

Published: 2025-12-27T21:00:00Z

Content type: opinion

Language: en

Sources: [Yegor Bugayenko](<https://devfeed.tech/sources/yegor-bugayenko.md>)

Topics: [JavaScript](<https://devfeed.tech/topics/javascript.md>), [TypeScript](<https://devfeed.tech/topics/typescript.md>), [es6](<https://devfeed.tech/topics/es6.md>), [Functional programming](<https://devfeed.tech/topics/functional-programming.md>)

Tags: [es6](<https://devfeed.tech/tags/es6.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [object-oriented](<https://devfeed.tech/tags/object-oriented.md>), [oop](<https://devfeed.tech/tags/oop.md>), [prototype](<https://devfeed.tech/tags/prototype.md>), [prototypes](<https://devfeed.tech/tags/prototypes.md>), [typescript](<https://devfeed.tech/tags/typescript.md>), [typescript-is-clumsy](<https://devfeed.tech/tags/typescript-is-clumsy.md>), [typescript-is-ugly](<https://devfeed.tech/tags/typescript-is-ugly.md>), [typescript-types](<https://devfeed.tech/tags/typescript-types.md>), [typescript-vs-javascript](<https://devfeed.tech/tags/typescript-vs-javascript.md>)

### AI overview

This opinion article recounts JavaScript's origins and argues that its prototype-based, class-free design was later undermined by TypeScript and ES6 classes. It also compares JavaScript's object model with Scheme, Self, C++, and Java.

### Source excerpt

JavaScript was an elegant prototype-based class-free language until TypeScript and ES6 classes ruined it.

## ESP-IDF tutorial series: Object oriented programming in C

DevFeed: [ESP-IDF tutorial series: Object oriented programming in C](<https://devfeed.tech/articles/esp-idf-tutorial-series-object-oriented-programming-in-c-13731.md>)

Original publisher: [Read original article](<https://developer.espressif.com/blog/2025/10/oop_with_c/>)

Author: John Lee

Published: 2025-10-03T00:00:00Z

Content type: tutorial

Language: en

Sources: [Blog on Developer Portal](<https://devfeed.tech/sources/blog-on-developer-portal.md>)

Topics: [C](<https://devfeed.tech/topics/c.md>), [ESP-IDF](<https://devfeed.tech/topics/esp-idf.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [blog](<https://devfeed.tech/tags/blog.md>), [c](<https://devfeed.tech/tags/c.md>), [esp-idf](<https://devfeed.tech/tags/esp-idf.md>), [esp32c3](<https://devfeed.tech/tags/esp32c3.md>), [object](<https://devfeed.tech/tags/object.md>), [oop](<https://devfeed.tech/tags/oop.md>), [programming](<https://devfeed.tech/tags/programming.md>), [tutorial](<https://devfeed.tech/tags/tutorial.md>)

### AI overview

This tutorial explains how ESP-IDF applies object-oriented programming principles in C using structs, opaque pointers, handles, function pointers, and modular design. It also discusses encapsulation, reusable components, and examples involving HTTP servers and I²C buses.

### Source excerpt

This article explains how ESP-IDF brings object-oriented programming principles into C by using structs, opaque pointers, and handles to enforce encapsulation and modularity. It shows how components like HTTP servers and I²C buses are managed through handles that represent distinct objects for configuration and operation, and compares this approach to Python and C++.

## Object-Oriented Programming in iOS

DevFeed: [Object-Oriented Programming in iOS](<https://devfeed.tech/articles/object-oriented-programming-in-ios-11528.md>)

Original publisher: [Read original article](<https://www.kodeco.com/ios/paths/object-oriented-programming>)

Published: 2023-10-17T00:00:00Z

Content type: tutorial

Language: en

Sources: [Kodeco | High quality programming tutorials: iOS, Android, Swift, Kotlin, Unity, and more](<https://devfeed.tech/sources/kodeco-high-quality-programming-tutorials-ios-android-swift-kotlin-unity-and-more.md>)

Topics: [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [iOS](<https://devfeed.tech/topics/ios.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Application Development](<https://devfeed.tech/topics/application-development.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>)

Tags: [application-development](<https://devfeed.tech/tags/application-development.md>), [code](<https://devfeed.tech/tags/code.md>), [concepts](<https://devfeed.tech/tags/concepts.md>), [course](<https://devfeed.tech/tags/course.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [ios](<https://devfeed.tech/tags/ios.md>), [learning](<https://devfeed.tech/tags/learning.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [oop](<https://devfeed.tech/tags/oop.md>), [programming](<https://devfeed.tech/tags/programming.md>), [skills](<https://devfeed.tech/tags/skills.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>), [techniques](<https://devfeed.tech/tags/techniques.md>)

### AI overview

This learning path teaches Object-Oriented Programming in iOS development, including foundational and advanced OOP concepts and their integration with Protocol-Oriented Programming. It aims to help learners design and implement reusable, maintainable software for mobile application development.

### Source excerpt

The Object-Oriented Programming (OOP) learning path offers a comprehensive exploration of software development principles and techniques. Covering three modules, learners will delve into foundational OOP concepts, advanced techniques, and their integration with Protocol-Oriented Programming (POP). By mastering both OOP and POP paradigms, participants will emerge ready to craft robust, adaptable software solutions that excel in the dynamic world of modern software engineering.

## Class Modifiers in Dart: Sealed, Interface, Base

DevFeed: [Class Modifiers in Dart: Sealed, Interface, Base](<https://devfeed.tech/articles/class-modifiers-in-dart-sealed-interface-base-23989.md>)

Original publisher: [Read original article](<https://quickbirdstudios.com/blog/flutter-dart-class-modifiers/>)

Author: Marvin März

Published: 2023-06-23T11:29:43Z

Content type: tutorial

Language: en

Sources: [QuickBird Studios Blog](<https://devfeed.tech/sources/quickbird-studios-blog.md>)

Topics: [Dart](<https://devfeed.tech/topics/dart.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>)

Tags: [abstract-class](<https://devfeed.tech/tags/abstract-class.md>), [class](<https://devfeed.tech/tags/class.md>), [classes](<https://devfeed.tech/tags/classes.md>), [dart](<https://devfeed.tech/tags/dart.md>), [flutter](<https://devfeed.tech/tags/flutter.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [interface](<https://devfeed.tech/tags/interface.md>), [oop](<https://devfeed.tech/tags/oop.md>), [pattern-matching](<https://devfeed.tech/tags/pattern-matching.md>), [post](<https://devfeed.tech/tags/post.md>), [sealed](<https://devfeed.tech/tags/sealed.md>), [sealed-interface](<https://devfeed.tech/tags/sealed-interface.md>)

### AI overview

This tutorial explains Dart 3 class modifiers, including the newly introduced sealed, interface, final, and base modifiers and changes to existing modifiers. It describes how modifiers control whether classes can be extended, mixed in, constructed, or implemented, and discusses their practical use cases.

### Source excerpt

With Dart 3 the class modifiers sealed, interface, final and base were introduced into the Dart language. They also updated how existing ones work. In this article, we show you why this change was made and how those new modifiers work. The post Class Modifiers in Dart: Sealed, Interface, Base appeared first on QuickBird Studios.

## Application-as-a-Function Thinking

DevFeed: [Application-as-a-Function Thinking](<https://devfeed.tech/articles/application-as-a-function-thinking-26037.md>)

Original publisher: [Read original article](<http://doridori.github.io//Architecture-Application-as-a-Function/>)

Author: SystemDotRun

Published: 2022-10-11T00:00:00Z

Content type: article

Language: en

Sources: [SystemDotRun](<https://devfeed.tech/sources/systemdotrun.md>)

Topics: [Development](<https://devfeed.tech/topics/development.md>), [Code](<https://devfeed.tech/topics/code.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Requirements](<https://devfeed.tech/topics/requirements.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [race-condition](<https://devfeed.tech/topics/race-condition.md>), [event driven](<https://devfeed.tech/topics/event-driven.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [development](<https://devfeed.tech/tags/development.md>), [event-driven](<https://devfeed.tech/tags/event-driven.md>), [oop](<https://devfeed.tech/tags/oop.md>), [productivity](<https://devfeed.tech/tags/productivity.md>), [race-condition](<https://devfeed.tech/tags/race-condition.md>), [requirements](<https://devfeed.tech/tags/requirements.md>), [testing](<https://devfeed.tech/tags/testing.md>)

### AI overview

The article argues that placing a stateless pure function at the core of an application, within a functional-core imperative-shell architecture, can simplify testing and reduce complexity. It discusses how scattered requirements, weak documentation, poor tests, naming problems, race-prone object-oriented state, low cohesion, and event handling can make systems harder to understand and maintain.

### Source excerpt

TL;DR Architecting an application with a pure function at its core can be a first step towards the "functional-core imperative shell" ideal, which can simplify testing and lower an applications complexity bar. Why? Simplification. As a novel alternative to KISS, we start with a quote from The Grug Brained Developer: complexity very, very bad And for completeness: Complexity: a measure of how difficult it is to understand how a system will behave or to predict the consequences of changing it For many applications the challenge is how to simply & correctly represent a large number of domain requirements in code, and how to raise the complexity-bar sufficently to enable a high degree of engineer productivity & runtime stability . A low complexity-bar reduces the amount of time it takes for a developer to get to the brain-meltdown-event-horizon-like state after which completion of new work slows down expontentially due to sheer codebase and test suite complexity which results in low grokability (i.e. code which is hard to understand or follow), an increasing degree of emergent behaviour, a higher probability of introducing regressions and generally, just slow development. A high complexity-bar conversely allows a desired order and serenity to take hold and more time spent on adding value as opposed to fire-fighting. I have observed different reasons for a low complexity bar, including: Domain requirements being spread throughout all codebase components Non-existent / incomplete / disorganised domain requirements documentation A non-existent / disorganised / bloated / poorly performing test suite Poor naming Race condition rich OOP state manipulations Low architectural cohesion across a codebase / team In addition if your application is highly event driven (user input / network / OS / peripherals / sensors) not having a simple approach to process incoming events can lead to chaotic code. Multiply this if you are working within a sensitive domain which has strict requirem

## Object-oriented or functional? Two ways to see the world

DevFeed: [Object-oriented or functional? Two ways to see the world](<https://devfeed.tech/articles/object-oriented-or-functional-two-ways-to-see-the-world-39357.md>)

Original publisher: [Read original article](<https://kt.academy/article/oop-vs-fp>)

Published: 2022-08-18T00:00:00Z

Content type: opinion

Language: en

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

Topics: [Functional programming](<https://devfeed.tech/topics/functional-programming.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [fp](<https://devfeed.tech/tags/fp.md>), [functional](<https://devfeed.tech/tags/functional.md>), [immutability](<https://devfeed.tech/tags/immutability.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [object-oriented](<https://devfeed.tech/tags/object-oriented.md>), [oop](<https://devfeed.tech/tags/oop.md>), [polymorphism](<https://devfeed.tech/tags/polymorphism.md>), [recursion](<https://devfeed.tech/tags/recursion.md>), [workshop-learning-programming](<https://devfeed.tech/tags/workshop-learning-programming.md>)

### 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.

## Represent data with generic data structures

DevFeed: [Represent data with generic data structures](<https://devfeed.tech/articles/represent-data-with-generic-data-structures-37567.md>)

Original publisher: [Read original article](<https://blog.klipse.tech/databook/2022/06/22/generic-data-structures.html>)

Author: Yehonathan Sharvit

Published: 2022-06-22T02:33:24Z

Content type: article

Language: en

Sources: [Klipse](<https://devfeed.tech/sources/klipse.md>)

Topics: [Data structures](<https://devfeed.tech/topics/data-structures.md>), [Code](<https://devfeed.tech/topics/code.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>)

Tags: [array](<https://devfeed.tech/tags/array.md>), [arrays](<https://devfeed.tech/tags/arrays.md>), [code](<https://devfeed.tech/tags/code.md>), [d](<https://devfeed.tech/tags/d.md>), [data-structures](<https://devfeed.tech/tags/data-structures.md>), [dop](<https://devfeed.tech/tags/dop.md>), [immutability](<https://devfeed.tech/tags/immutability.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [oop](<https://devfeed.tech/tags/oop.md>), [programming](<https://devfeed.tech/tags/programming.md>)

### AI overview

This article explores the second principle of Data-Oriented Programming: representing application data with generic data structures such as maps and arrays instead of specific classes. It also discusses other structures, including sets, trees, and queues, and describes benefits such as reusable generic functions and a flexible data model.

### Source excerpt

When adhering to Principle #1 of DOP, code is separated from data. DOP is not opinionated about the programming constructs to use for organizing the code, but it has a lot to say about how the data should be represented. This is the theme of Principle #2.

## Separate code from data

DevFeed: [Separate code from data](<https://devfeed.tech/articles/separate-code-from-data-37569.md>)

Original publisher: [Read original article](<https://blog.klipse.tech/databook/2022/06/22/separate-code-from-data.html>)

Author: Yehonathan Sharvit

Published: 2022-06-22T02:32:24Z

Content type: tutorial

Language: en

Sources: [Klipse](<https://devfeed.tech/sources/klipse.md>)

Topics: [Programming](<https://devfeed.tech/topics/programming.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [classes](<https://devfeed.tech/topics/classes.md>)

Tags: [behavior](<https://devfeed.tech/tags/behavior.md>), [classes](<https://devfeed.tech/tags/classes.md>), [code](<https://devfeed.tech/tags/code.md>), [d](<https://devfeed.tech/tags/d.md>), [data](<https://devfeed.tech/tags/data.md>), [dop](<https://devfeed.tech/tags/dop.md>), [oop](<https://devfeed.tech/tags/oop.md>), [programming](<https://devfeed.tech/tags/programming.md>)

### AI overview

This article explores the first principle of Data-Oriented Programming: separating code, or behavior, from data. It explains how the principle can be followed or violated in both object-oriented programming and functional programming, including examples involving classes, static methods, and lexical scope.

### Source excerpt

The first principle of Data-Oriented Programming (DOP) is a design principle that recommends a clear separation between code (behavior) and data. This may appear to be a FP principle, but in fact, one can adhere to it or break it either in FP or in OOP:

## 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...

## Programming Language Evolution

DevFeed: [Programming Language Evolution](<https://devfeed.tech/articles/programming-language-evolution-26026.md>)

Original publisher: [Read original article](<https://elizarov.medium.com/programming-language-evolution-ab7d7d2b0d0b?source=rss-4762e889f8fc------2>)

Author: Roman Elizarov

Published: 2020-11-23T16:18:08Z

Content type: opinion

Language: en

Sources: [Stories by Roman Elizarov on Medium](<https://devfeed.tech/sources/stories-by-roman-elizarov-on-medium.md>)

Topics: [Programming](<https://devfeed.tech/topics/programming.md>), [Programming language](<https://devfeed.tech/topics/programming-language.md>), [Code](<https://devfeed.tech/topics/code.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [C](<https://devfeed.tech/topics/c.md>), [Java](<https://devfeed.tech/topics/java.md>), [Python](<https://devfeed.tech/topics/python.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [evolution](<https://devfeed.tech/tags/evolution.md>), [history](<https://devfeed.tech/tags/history.md>), [improvements](<https://devfeed.tech/tags/improvements.md>), [language](<https://devfeed.tech/tags/language.md>), [loops](<https://devfeed.tech/tags/loops.md>), [oop](<https://devfeed.tech/tags/oop.md>), [patterns](<https://devfeed.tech/tags/patterns.md>), [pointers](<https://devfeed.tech/tags/pointers.md>), [programming](<https://devfeed.tech/tags/programming.md>), [programming-language](<https://devfeed.tech/tags/programming-language.md>), [programming-languages](<https://devfeed.tech/tags/programming-languages.md>), [software](<https://devfeed.tech/tags/software.md>)

### AI overview

The article examines how programming languages evolve through gradual improvements that follow changes in programming practice. It uses the transition from GOTOs to structured loops and the adoption of object-oriented patterns, classes, methods, and implicit object references as examples.

### Source excerpt

Photo by Anne Nygård on Unsplash The history of programming languages is ripe with evolution. Existing languages constantly evolve and new languages are created to address the emerging needs. Sometimes there are radical, revolutionary breakthroughs, with a complete paradigm shift, but often there are just gradual improvements and refinements. The latter is the topic of this story. The practice of programming at any given era usually goes ahead of capabilities that programming languages provide, while programming language designers recognize it and catch up to fulfill the demand. Let us see some examples to the point. From GOTOs to the structured code In early languages, you had to write a lot of repetitive code just to do a simple loop. The loop was such a common programming pattern, that it was adopted even by the primitive higher-level languages in the era predating structured programming. So, there was a time when you still had GOTOs in your programming language but a significant fraction of the code had structured loops: 10 LET N=10 20 FOR I=1 TO N 30 PRINT "Hello, World!" 40 NEXT I As we know, the subsequent generation of languages not only added structured IF statements but also made the structure explicit in the source and ended up abolishing GOTOs completely. This kind of evolution can be seen in other areas, too. Objects and pointers Let's take a brief look at OOP. The object-oriented style of programming does not need an object-oriented language. Even nowadays you can find software written in C where methods are just a convention of writing functions whose first parameter is a pointer to the receiver: void Point_move(Point* self, int dx, int dy) { ... } Virtual methods are routinely implemented in pure C, too, explicitly keeping a virtual methods table with references to methods somewhere in the object's structure. However, the rising popularity of object-oriented programming back in the day cemented the growth of languages that incorporated these patterns

## Unspoken Assumptions Underlying OO Design Maxims

DevFeed: [Unspoken Assumptions Underlying OO Design Maxims](<https://devfeed.tech/articles/unspoken-assumptions-underlying-oo-design-maxims-32238.md>)

Original publisher: [Read original article](<https://bruceeckel.com/blog/2019-12-24-unspoken-assumptions-underlying-oo-design-maxims/>)

Author: Bruce Eckel

Published: 2019-12-24T00:00:00Z

Content type: opinion

Language: en

Sources: [Bruce Eckel - Computing Thoughts](<https://devfeed.tech/sources/bruce-eckel-computing-thoughts.md>)

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

Tags: [approach](<https://devfeed.tech/tags/approach.md>), [change](<https://devfeed.tech/tags/change.md>), [complexity](<https://devfeed.tech/tags/complexity.md>), [object-oriented](<https://devfeed.tech/tags/object-oriented.md>), [oop](<https://devfeed.tech/tags/oop.md>)

### AI overview

The article argues that many object-oriented design maxims implicitly assume developers can predict how a system will change. It questions whether adding complexity to support uncertain future changes is justified, using the open-closed principle and polymorphism as examples.

### Source excerpt

For Atomic Kotlin, I've been struggling with an "atom" (very small chapter) during the last couple of months. It's on object-oriented design, and it brought up a lot of feelings I've had for quite awhile about some of the various maxims and design guidelines that have appeared in recent decades, since OO became mainstream. I couldn't quite put my finger on what bothered me about these design ideas. Then @codingunicorn did it for me by writing a post called Flexible code considered harmful.

## Clean architecture for Android with Kotlin: a pragmatic approach for starters

DevFeed: [Clean architecture for Android with Kotlin: a pragmatic approach for starters](<https://devfeed.tech/articles/clean-architecture-for-android-with-kotlin-a-pragmatic-approach-for-starters-27142.md>)

Original publisher: [Read original article](<https://antonioleiva.com/clean-architecture-android>)

Published: 2018-09-30T00:00:00Z

Content type: tutorial

Language: en

Sources: [Antonio Leiva](<https://devfeed.tech/sources/antonio-leiva.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Dependency Inversion](<https://devfeed.tech/topics/dependency-inversion.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [clean-architecture](<https://devfeed.tech/tags/clean-architecture.md>), [decoupling](<https://devfeed.tech/tags/decoupling.md>), [dependency-inversion](<https://devfeed.tech/tags/dependency-inversion.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [oop](<https://devfeed.tech/tags/oop.md>), [programming](<https://devfeed.tech/tags/programming.md>), [ui](<https://devfeed.tech/tags/ui.md>)

### AI overview

A pragmatic introductory tutorial on clean architecture for Android apps using Kotlin. It focuses on dependency inversion, explains the tradeoff between decoupling and added complexity, and introduces a five-layer application structure.

### Source excerpt

Everything Android, Kotlin and other random topics

## A Go Developer's Subjective Critiques of the Language

DevFeed: [A Go Developer's Subjective Critiques of the Language](<https://devfeed.tech/articles/go-is-amazing-so-here-s-what-i-don-t-like-about-it-41258.md>)

Original publisher: [Read original article](<https://www.evilsocket.net/2018/03/14/Go-is-amazing-so-here-s-what-i-don-t-like-about-it/>)

Author: Simone Margaritelli

Published: 2018-03-14T22:39:09Z

Content type: opinion

Language: en

Sources: [evilsocket](<https://devfeed.tech/sources/evilsocket.md>)

Topics: [Go Language](<https://devfeed.tech/topics/go-language.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [cybersecurity](<https://devfeed.tech/tags/cybersecurity.md>), [design-patterns](<https://devfeed.tech/tags/design-patterns.md>), [developing](<https://devfeed.tech/tags/developing.md>), [go](<https://devfeed.tech/tags/go.md>), [golang](<https://devfeed.tech/tags/golang.md>), [language-critique](<https://devfeed.tech/tags/language-critique.md>), [oop](<https://devfeed.tech/tags/oop.md>), [opinion](<https://devfeed.tech/tags/opinion.md>), [programming](<https://devfeed.tech/tags/programming.md>), [software-development](<https://devfeed.tech/tags/software-development.md>)

### AI overview

A Go programmer presents subjective criticisms of the language to offer a more balanced account of their experience. The author says Go may still be a better choice for several applications and does not frame the piece as a Go-versus-Rust debate.

### Source excerpt

After my last post and generally the kind of indirect advertising I'm doing to the Go programming language for a few months now, I heard about and talked with a lot of people who started being interested in the language, so for once I decided to write what I don't like about it instead, to provide a more balanced perspective of what's my experience so far and maybe let some of those people realize that Go is not the right choice for their projects after all. NOTE 1 It's important to say that some, if not most of the things I'm about to write are purely subjective and related to my programming habits, they do not necessarily represent so called "best practices" and should not be taken like so. Moreover, I'm still a Go noob, some of the things I'm going to say might just be inaccurate / wrong, in which case feel free to correct me and teach me something new, please :D NOTE 2 Before we start: I love this language and I already explained why I still consider it a better choice for several applications, but I'm not interested in an opinion war about Go vs Rust, or Go vs whatever ... use what you think it's best for what you have to do: if that's Rust go for it, if you think it's binary code you send to the processor by using your nipples to inject faults into some data bus, go for it, both cases, code and let code, life is too short for being a language hipster.

## BetterReflection version 2.0.0 released

DevFeed: [BetterReflection version 2.0.0 released](<https://devfeed.tech/articles/betterreflection-version-2-0-0-released-21148.md>)

Original publisher: [Read original article](<https://ocramius.github.io/blog/roave-better-reflection-v2.0/>)

Published: 2017-09-18T00:00:00Z

Content type: release

Language: en

Sources: [Marco Pivetta](<https://devfeed.tech/sources/marco-pivetta.md>)

Topics: [PHP](<https://devfeed.tech/topics/php.md>), [Library](<https://devfeed.tech/topics/library.md>), [Parser](<https://devfeed.tech/topics/parser.md>), [Security](<https://devfeed.tech/topics/security.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [Malware](<https://devfeed.tech/topics/malware.md>), [Composer](<https://devfeed.tech/topics/composer.md>)

Tags: [2-0-0](<https://devfeed.tech/tags/2-0-0.md>), [code](<https://devfeed.tech/tags/code.md>), [compilation](<https://devfeed.tech/tags/compilation.md>), [env-file-security](<https://devfeed.tech/tags/env-file-security.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [oop](<https://devfeed.tech/tags/oop.md>), [php](<https://devfeed.tech/tags/php.md>), [procedural](<https://devfeed.tech/tags/procedural.md>), [scope](<https://devfeed.tech/tags/scope.md>), [security](<https://devfeed.tech/tags/security.md>), [use-cases](<https://devfeed.tech/tags/use-cases.md>), [version-2-0-0](<https://devfeed.tech/tags/version-2-0-0.md>)

### AI overview

Roave's BetterReflection 2.0.0 reproduces PHP's reflection API without triggering autoloading. It scans source files, parses PHP code into an AST, and exposes reflection objects for analysis before classes are loaded.

### Source excerpt

Roave's BetterReflection 2.0.0s was released today! I and James Titcumb started working on this project back in 2015, and it is a pleasure to see it reaching maturity. The initial idea was simple: James would implement all my wicked ideas, while I would lay back and get drunk on Drambuie. Yes, that actually happened. Thank you, James, for all the hard work! 🍻 (I did some work too, by the way!) What the heck is BetterReflection? Jokes apart, the project is quite ambitious, and it aims at reproducing the entirety of the PHP reflection API without having any actual autoloading being triggered. When put in use, it looks like this: <?php // src/MyClass.php namespace MyProject; class MyClass { public function something() {} } <?php // example1.php use MyProject\MyClass; use Roave\BetterReflection\BetterReflection; use Roave\BetterReflection\Reflection\ReflectionMethod; require_once __DIR__ . '/vendor/autoload.php'; $myClass = (new BetterReflection()) ->classReflector() ->reflect(MyClass::class); $methodNames = \array_map(function (ReflectionMethod $method) : string { return $method->getName(); }, $myClass->getMethods()); \var_dump($methodNames); // class was not loaded: \var_dump(\sprintf('Class %s loaded: ', MyClass::class)); \var_dump(\class_exists(MyClass::class, false)); As you can see, the difference is just in how you bootstrap the reflection API. Also, we do provide a fully backwards-compatible reflection API that you can use if your code heavily relies on ext-reflection: <?php // example2.php use MyProject\MyClass; use Roave\BetterReflection\BetterReflection; use Roave\BetterReflection\Reflection\Adapter\ReflectionClass; require_once __DIR__ . '/vendor/autoload.php'; $myClass = (new BetterReflection()) ->classReflector() ->reflect(MyClass::class); $reflectionClass = new ReflectionClass($myClass); // You can just use it wherever you had `ReflectionClass`! \var_dump($reflectionClass instanceof \ReflectionClass); \var_dump($reflectionClass->getName()); How does that

## Poor man's functional programming

DevFeed: [Poor man's functional programming](<https://devfeed.tech/articles/poor-man-s-functional-programming-21605.md>)

Original publisher: [Read original article](<http://miqu.me/blog/2015/08/31/poor-mans-functional-programming/>)

Author: Miguel Angel Quiñones

Published: 2015-08-31T20:00:00Z

Content type: article

Language: en

Sources: [Miguel Quinones](<https://devfeed.tech/sources/miguel-quinones.md>)

Topics: [Functional programming](<https://devfeed.tech/topics/functional-programming.md>), [Swift](<https://devfeed.tech/topics/swift.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [beginner](<https://devfeed.tech/tags/beginner.md>), [functional-programming](<https://devfeed.tech/tags/functional-programming.md>), [ios](<https://devfeed.tech/tags/ios.md>), [learning](<https://devfeed.tech/tags/learning.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [oop](<https://devfeed.tech/tags/oop.md>), [programming](<https://devfeed.tech/tags/programming.md>), [swift](<https://devfeed.tech/tags/swift.md>)

### AI overview

The article encourages iOS and Mac developers familiar with object-oriented programming to explore functional programming through Swift. It discusses the learning barriers, abstract terminology, and gap between toy examples and large projects, while arguing against treating programming paradigms as ideological camps.

### Source excerpt

It's a very exciting time to be an iOS or Mac developer. The platform moves very fast and we got a new toy (language) to play with: Swift. It's the perfect time to reevaluate, learn and evolve as a programmer, because you will be forced to adopt this new language (yes, I think Swift is the future, 100%). I want to relate this to the fact that most iOS engineers, or mobile application developers, are traditionally familiar with Object Oriented Programming paradigm. But Swift offers more than different syntax and OOP. I'm referring to some features inspired by functional languages. If you've ever had an interest, but never the chance or motivation to go forth and look into this paradigm, now it's the perfect time to do it. Functional programming is... I don't want to start reviewing what functional programming is, there are excellent resources out there, check them out. I want to point out how a beginner, somebody who starts learning Functional Programming (FP), might feel: Too abstract Not applicable to my problems For academics What does even 'pure' mean? I need to mutate stuff! Meh, I'll go back to my familiar way of doing things There's a higher barrier of entry to learn how to think and code programs which are more 'functional'. The concepts are abstract, and the benefits are often described as it's more functional without emphasis of what you are actually gaining. Also there's the problem that many times all is explained by simple examples. But every programmer knows there's a huge difference between toy programs and real big projects. Flame wars You'll find engineers and computer scientists that believe that the only and true way of doing things is of course thinking functionally, and we've all been doing it wrong during the last decades. The math is the only source of truth and validity, hence FP is the only way. They've got their very valid reasons to think this way, but my opinion is that many people familiar with FP start to use higher-level vocabulary, and d

## Avoid static imports

DevFeed: [Avoid static imports](<https://devfeed.tech/articles/avoid-static-imports-37681.md>)

Original publisher: [Read original article](<https://carlosbecker.com/posts/avoid-static-imports/>)

Author: Carlos Alexandro Becker

Published: 2015-07-05T00:00:00Z

Content type: opinion

Language: en

Sources: [Carlos Becker](<https://devfeed.tech/sources/carlos-becker.md>)

Topics: [Java](<https://devfeed.tech/topics/java.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>)

Tags: [antipattern](<https://devfeed.tech/tags/antipattern.md>), [avoid](<https://devfeed.tech/tags/avoid.md>), [code](<https://devfeed.tech/tags/code.md>), [java](<https://devfeed.tech/tags/java.md>), [oop](<https://devfeed.tech/tags/oop.md>), [readability](<https://devfeed.tech/tags/readability.md>)

### AI overview

The article argues that Java static imports should be used sparingly because overuse can obscure where methods and members originate, pollute the namespace, and reduce code readability and maintainability. It recommends importing only a small number of frequently used static members when appropriate.

### Source excerpt

There are a lot of Java API's and Frameworks which rely on static methods and the sort. Arguably, this is a bad OOP practice, but let's not enter this particular subject just yet.

## When to declare classes final

DevFeed: [When to declare classes final](<https://devfeed.tech/articles/when-to-declare-classes-final-21149.md>)

Original publisher: [Read original article](<https://ocramius.github.io/blog/when-to-declare-classes-final/>)

Published: 2015-01-06T00:00:00Z

Content type: opinion

Language: en

Sources: [Marco Pivetta](<https://devfeed.tech/sources/marco-pivetta.md>)

Topics: [PHP](<https://devfeed.tech/topics/php.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Refactoring](<https://devfeed.tech/topics/refactoring.md>)

Tags: [articles](<https://devfeed.tech/tags/articles.md>), [doom](<https://devfeed.tech/tags/doom.md>), [examples](<https://devfeed.tech/tags/examples.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [oop](<https://devfeed.tech/tags/oop.md>), [opinion](<https://devfeed.tech/tags/opinion.md>), [php](<https://devfeed.tech/tags/php.md>), [programming](<https://devfeed.tech/tags/programming.md>)

### AI overview

This opinion article argues that PHP classes should generally be declared final, especially when they implement an interface and expose no other public methods. It explains that preventing inheritance can discourage deep inheritance chains, encourage composition, and make developers design clearer public APIs.

### Source excerpt

TL;DR: Make your classes always final, if they implement an interface, and no other public methods are defined In the last month, I had a few discussions about the usage of the final marker on PHP classes. The pattern is recurrent: I ask for a newly introduced class to be declared as final the author of the code is reluctant to this proposal, stating that final limits flexibility I have to explain that flexibility comes from good abstractions, and not from inheritance It is therefore clear that coders need a better explanation of when to use final, and when to avoid it. There are many other articles about the subject, but this is mainly thought as a "quick reference" for those that will ask me the same questions in future. When to use "final": final should be used whenever possible. Why do I have to use final? There are numerous reasons to mark a class as final: I will list and describe those that are most relevant in my opinion. 1. Preventing massive inheritance chain of doom Developers have the bad habit of fixing problems by providing specific subclasses of an existing (not adequate) solution. You probably saw it yourself with examples like following: <?php class Db { /* ... */ } class Core extends Db { /* ... */ } class User extends Core { /* ... */ } class Admin extends User { /* ... */ } class Bot extends Admin { /* ... */ } class BotThatDoesSpecialThings extends Bot { /* ... */ } class PatchedBot extends BotThatDoesSpecialThings { /* ... */ } This is, without any doubts, how you should NOT design your code. The approach described above is usually adopted by developers who confuse OOP with "a way of solving problems via inheritance" ("inheritance-oriented-programming", maybe?). 2. Encouraging composition In general, preventing inheritance in a forceful way (by default) has the nice advantage of making developers think more about composition. There will be less stuffing functionality in existing code via inheritance, which, in my opinion, is a symptom of haste

## Object Oriented Programming in Go

DevFeed: [Object Oriented Programming in Go](<https://devfeed.tech/articles/object-oriented-programming-in-go-22058.md>)

Original publisher: [Read original article](<https://www.ardanlabs.com/blog/2013/07/object-oriented-programming-in-go.html>)

Published: 2013-07-10T00:00:00Z

Content type: tutorial

Language: en

Sources: [William Kennedy](<https://devfeed.tech/sources/william-kennedy.md>)

Topics: [Go Language](<https://devfeed.tech/topics/go-language.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [Polymorphism](<https://devfeed.tech/topics/polymorphism.md>), [interfaces](<https://devfeed.tech/topics/interfaces.md>)

Tags: [ardan-labs](<https://devfeed.tech/tags/ardan-labs.md>), [blog](<https://devfeed.tech/tags/blog.md>), [embedding](<https://devfeed.tech/tags/embedding.md>), [function](<https://devfeed.tech/tags/function.md>), [go](<https://devfeed.tech/tags/go.md>), [go-programming](<https://devfeed.tech/tags/go-programming.md>), [golang](<https://devfeed.tech/tags/golang.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [oop](<https://devfeed.tech/tags/oop.md>), [polymorphism](<https://devfeed.tech/tags/polymorphism.md>), [private-access](<https://devfeed.tech/tags/private-access.md>), [programming](<https://devfeed.tech/tags/programming.md>), [properties](<https://devfeed.tech/tags/properties.md>), [structure](<https://devfeed.tech/tags/structure.md>)

### AI overview

This tutorial explains object-oriented programming in Go, focusing on how composition, embedding, and interfaces provide polymorphic behavior without traditional inheritance. It also introduces structs, field visibility, and methods through Cat, Dog, and Animal examples.

### Source excerpt

Someone asked a question on the forum today on how to gain the benefits of inheritance without embedding. It is really important for everyone to think in terms of Go and not the languages they are leaving behind. I can't tell you much code I removed from my early Go implementations because it wasn't necessary. The language designers have years of experience and knowledge. Hindsight is helping to create a language that is fast, lean and really fun to code in.

[Next page](<https://devfeed.tech/tags/oop.md?cursor=WyIyMDEzLTA3LTEwVDAwOjAwOjAwKzAwOjAwIiwgImIwOWZiN2JhLTZhN2EtNDlhNy1iNTY2LTZiNjU1MTdiYmU2YiJd>)