# object oriented Published articles for object oriented. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Introduction to Object-Oriented Programming in Python DevFeed: [Introduction to Object-Oriented Programming in Python]() Original publisher: [Read original article]() Author: Stephen Gruppetta Published: 2026-05-08T12:29:01Z Content type: tutorial Language: en Sources: [The Palindrome]() Topics: [Programming](), [Python]() Tags: [introduction](), [object-oriented](), [programming](), [python]() ### AI overview An introduction to object-oriented programming in Python. The supplied evidence does not provide further substantive details. ### Source excerpt The true way of doing stuff with data ## 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 ## 12 OOP Concepts EVERY Developer Should Know DevFeed: [12 OOP Concepts EVERY Developer Should Know]() Original publisher: [Read original article]() Author: Ashish Pratap Singh Published: 2026-02-12T04:27:26Z Content type: tutorial Language: en Sources: [AlgoMaster Newsletter]() Topics: [Object-oriented programming (OOP)](), [Programming](), [Code](), [interfaces](), [Polymorphism](), [App]() Tags: [class](), [classes](), [code](), [concepts](), [developer](), [interface](), [interfaces](), [object-oriented](), [oop](), [practical](), [programming](), [real-world]() ### 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 ## 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]() Original publisher: [Read original article]() Author: Yegor Bugayenko (yegor256@gmail.com) Published: 2025-12-27T21:00:00Z Content type: opinion Language: en Sources: [Yegor Bugayenko]() Topics: [JavaScript](), [TypeScript](), [es6](), [Functional programming]() Tags: [es6](), [javascript](), [object-oriented](), [oop](), [prototype](), [prototypes](), [typescript](), [typescript-is-clumsy](), [typescript-is-ugly](), [typescript-types](), [typescript-vs-javascript]() ### 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. ## Abstraction design: Introduction DevFeed: [Abstraction design: Introduction]() Original publisher: [Read original article]() Published: 2024-02-05T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [abstraction](), [Programming](), [Object-oriented programming (OOP)](), [interfaces](), [Functional programming]() Tags: [abstraction](), [concepts](), [core](), [function](), [interfaces](), [object-oriented](), [programming](), [workshop-learning-programming]() ### AI overview This introduction explains abstraction as a form of simplification that hides complexity by deciding what to expose and what to conceal. It discusses abstractions in object-oriented and functional programming, including interfaces, classes, functions, and higher-level operations, with examples involving Java and Kotlin. ### Source excerpt What is abstraction in programming and why is it so important. ## Workflows as Actors: Is it really possible? DevFeed: [Workflows as Actors: Is it really possible?]() Original publisher: [Read original article]() Author: Fitz Published: 2023-06-27T22:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [Actor](), [systems](), [Object-oriented programming (OOP)](), [Complex Systems]() Tags: [actor](), [blog-post](), [concurrent](), [design-patterns](), [object-oriented](), [parallel](), [temporal-concepts](), [workflows]() ### AI overview This article introduces the Actor Model and compares actors with objects, focusing on message passing, state, actor creation, and encapsulation. It then explains how Temporal Workflows can be built to behave like actors. ### Source excerpt An overview on how to use Temporal Workflows in the form of an Actor Model ## Four of a Kotlin Kind at I code Java 2022 conference DevFeed: [Four of a Kotlin Kind at I code Java 2022 conference]() Original publisher: [Read original article]() Published: 2022-10-14T08:30:41Z Content type: article Language: en Sources: [maiatoday]() Topics: [Kotlin](), [Code](), [Software]() Tags: [code](), [concepts](), [conference](), [declarative](), [functional](), [imperative](), [java](), [kotlin](), [object-oriented](), [pitfalls](), [talk](), [tips](), [traces]() ### AI overview The article introduces a talk about Kotlin's support for imperative, declarative, functional, and object-oriented programming. It highlights tips, guidelines, pitfalls, definitions, software history, and how Kotlin supports these concepts. ### Source excerpt I shared my talk titled Imperative, Declarative, Object oriented, functional: Four of a Kotlin Kind at the I code Java conference. The abstract: Is Kotlin a functional language? Yes, but... Is it object oriented? Yes, but... Looking at four concepts: imperative, declarative, functional and object oriented How does Kotlin make it easy to use either or all at the same time. This talk contains: Some useful Kotlin tips, some guidelines and pitfalls for the four concepts, traces of definitions and software history. After listening to this talk you will understand what these concepts are, what each is good for and how they are supported by the Kotlin language. You can see the talk here ## 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. ## Unspoken Assumptions Underlying OO Design Maxims DevFeed: [Unspoken Assumptions Underlying OO Design Maxims]() Original publisher: [Read original article]() Author: Bruce Eckel Published: 2019-12-24T00:00:00Z Content type: opinion Language: en Sources: [Bruce Eckel - Computing Thoughts]() Topics: [Object-oriented programming (OOP)](), [Kotlin](), [Code]() Tags: [approach](), [change](), [complexity](), [object-oriented](), [oop]() ### 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. ## Object Relational Database Management System DevFeed: [Object Relational Database Management System]() Original publisher: [Read original article]() Author: Dimitri Fontaine PostgreSQL Major Contributor; Author Published: 2018-03-22T16:40:39Z Content type: article Language: en Sources: [Dimitri Fontaine]() Topics: [PostgreSQL](), [Database](), [Polymorphism]() Tags: [database](), [object-oriented](), [open-source](), [ordbms](), [postgresql](), [programming]() ### AI overview This article explains why PostgreSQL is described as an object-relational database management system. It introduces object-oriented programming and discusses object-orientation models, including message passing, in relation to database systems and programming languages. ### Source excerpt PostgreSQL is the world's most advanced open source database, and per the PostgreSQL Wikipedia page it is an object-relational database management system (ORDBMS) with an emphasis on extensibility and standards compliance. In this article, we try to understand why would PostgreSQL be named an object-relational thing. What is Object Oriented Programming and how does that apply to a database system? ## Functional vs Object-oriented approaches to validation DevFeed: [Functional vs Object-oriented approaches to validation]() Original publisher: [Read original article]() Published: 2014-12-07T00:00:00Z Content type: tutorial Language: en Sources: [Adam Bard]() Topics: [Functional programming](), [Programming](), [Python](), [Exception]() Tags: [exception](), [functional](), [object-oriented](), [python](), [validation]() ### AI overview This article compares functional and object-oriented approaches to validating and cleaning data in Python. It presents equivalent validation designs that return cleaned data on success and collect errors when validation fails, while discussing closures, exceptions, and execution flow. ### Source excerpt Functional programming is often described in terms of its contrast with object-oriented programs; that is, you write functions that act on data instead of objects that wrap data and use methods to act on themselves. Functional programming wonks (like me) will tell you that writing code this way is generally better than OO, but I don't want to do that (right now). However, in this post, I'm not here to argue either side. Today, I'm just going to demonstrate a few equivalent approaches to the same problem: validating data. ## Clojure is not for geniuses DevFeed: [Clojure is not for geniuses]() Original publisher: [Read original article]() Published: 2014-11-18T00:00:00Z Content type: opinion Language: en Sources: [Adam Bard]() Topics: [ClojureScript](), [Programming](), [systems](), [Software]() Tags: [article](), [assembly](), [blog](), [c](), [complexity](), [debugging](), [functional](), [language](), [languages](), [memory](), [object-oriented](), [objective-c](), [programming](), [software](), [systems]() ### AI overview The article argues that Clojure is not limited to genius programmers. It presents immutable collection semantics and reduced program and library complexity as ways to reduce the mental effort required to understand and debug software, contrasting this with the lifecycle-tracing demands of mutable object-oriented systems. ### Source excerpt It's a common attitude that functional languages with immutable collection semantics, such as Clojure, are for a) pretentious language geeks, or b) actual genius programmers. I'm in no position to defend against point a) given the body of my writing on this blog, so today I'd like to write an article about point b). ## Java to Clojure: "Refactoring" refactored functionally DevFeed: [Java to Clojure: "Refactoring" refactored functionally]() Original publisher: [Read original article]() Published: 2014-06-10T00:00:00Z Content type: tutorial Language: en Sources: [Adam Bard]() Topics: [Refactoring](), [Clojure](), [Java](), [Code]() Tags: [clojure](), [code](), [functional](), [interfaces](), [java](), [object-oriented](), [refactoring](), [types]() ### AI overview This tutorial refactors a video-store example from object-oriented Java into a more functional Clojure style. It compares the original class-based design with Clojure protocols and immutable records, while noting that the source example differs from Martin Fowler's book. ### Source excerpt I was searching for a good example to illustrate some properties of refactoring object-oriented code into a more functional style, and I came across this example from Martin Fowler's Refactoring. It describes the process of refactoring code for a video store. It's a nice little example with a useful narrative to go along with it. ## Monstera: An Experiment in Using C++ and Object-Oriented Design for ReactOS's Memory Manager DevFeed: [Monstera: An Experiment in Using C++ and Object-Oriented Design for ReactOS's Memory Manager]() Original publisher: [Read original article]() Published: 2014-01-05T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [Kernel](), [C++](), [coding patterns](), [Development]() Tags: [c-plus-plus](), [coding-patterns](), [experiment](), [free](), [hybrid](), [kernel](), [object-oriented](), [open-source](), [os](), [procedural](), [react](), [reactos](), [win32](), [winapi]() ### AI overview Monstera is an experiment to assess whether C++ and selected object-oriented design principles can simplify development of ReactOS's predominantly procedural, C-centric memory manager. The post notes that kernel-code constraints limit which C++ features can be used, and that the experiment's success remains uncertain. ### Source excerpt This post really should have been made months ago, but finding the time to write a full blown newsletter has been getting more and more scarce. That being said, I've decided for the short term to split things that would normally act as a single newsletter section into separate blog posts so I don't need to wait and gather things. There was a lot of speculation as to what Monstera was when Aleksey made his commit with some suggesting it is a repeat of his ARWINSS effort but targetted at the memory manager. ## An Unbiased Comparison of F# and Scala DevFeed: [An Unbiased Comparison of F# and Scala]() Original publisher: [Read original article]() Published: 2013-06-22T00:00:00Z Content type: comparison Language: en Sources: [Tim Kellogg]() Topics: [F#](), [Scala](), [Functional programming](), [Programming]() Tags: [comparison](), [f-sharp](), [functional](), [functional-programming](), [languages](), [object](), [object-oriented](), [programming](), [scala]() ### AI overview A developer compares F# and Scala from the perspective of a .NET developer who began working with Scala. The article argues that Scala is more approachable but less purely functional, while F# adheres more closely to functional programming principles. It also compares their object-oriented features, function definitions, currying, and partial function application. ### Source excerpt Given my history as a .NET developer I learned Functional Programming via F#, but I just started a new job as a Scala developer. Naturally, I've been comparing the two languages and the quirks and nuances that make could make them enjoyable or problematic. To summarize quickly, I think Scala is more approachable but less "pure" than F#. Scala seems to have a diverse set of influences whereas F# tries to stick closely to proven Functional Programming basics. ## Things that make me dislike Java DevFeed: [Things that make me dislike Java]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2012-12-15T00:00:00Z Content type: opinion Language: en Sources: [Carlos Becker]() Topics: [Java](), [Object-oriented programming (OOP)](), [class](), [generics](), [Inheritance]() Tags: [generics](), [inheritance](), [java](), [object-oriented]() ### AI overview An opinion piece discussing aspects of Java that the author dislikes, especially its object-oriented model, primitive types, wrapper classes, generics, autoboxing, and null behavior. The author also acknowledges Java's community, specifications, and libraries. ### Source excerpt So, I just compiled a little list of things that, I believe, make me dislike Java everyday a little more. ## Dependency Inversion Principle DevFeed: [Dependency Inversion Principle]() Original publisher: [Read original article]() Published: 2011-08-10T00:00:00Z Content type: article Language: en Sources: [Radek Pazdera]() Topics: [Dependency Inversion](), [abstraction](), [interface](), [object](), [modules](), [Software]() Tags: [abstraction](), [dependency-inversion](), [dependency-inversion-principle](), [interface](), [interfaces](), [object-oriented](), [software](), [solid]() ### AI overview The article explains the Dependency Inversion Principle, the D in SOLID, for object-oriented software design. It argues that high-level and low-level modules should depend on abstractions, while details should depend on those abstractions, improving module reuse and reducing direct coupling. ### Source excerpt SOLID Object-Oriented Design ## Liskov Substitution Principle DevFeed: [Liskov Substitution Principle]() Original publisher: [Read original article]() Published: 2011-08-09T00:00:00Z Content type: tutorial Language: en Sources: [Radek Pazdera]() Topics: [Software Engineering](), [Architecture & Design](), [coding](), [subclass](), [subtype]() Tags: [hierarchy](), [object-oriented](), [software-design](), [solid](), [subclass](), [subtype]() ### AI overview This article explains the Liskov Substitution Principle, the L in SOLID object-oriented design. It presents definitions from Barbara Liskov and Jeannette Wing, a formulation by Robert C. Martin, and a Square-Rectangle hierarchy example showing how subtype behavior can violate substitutability. ### Source excerpt SOLID Object-Oriented Design ## Single Responsibility Principle DevFeed: [Single Responsibility Principle]() Original publisher: [Read original article]() Published: 2011-08-08T00:00:00Z Content type: tutorial Language: en Sources: [Radek Pazdera]() Topics: [object](), [class](), [Code](), [Software](), [MySQL]() Tags: [class](), [code](), [complexity](), [design](), [implementation](), [mysql](), [object-oriented](), [solid](), [sql]() ### AI overview The article explains the Single Responsibility Principle (SRP), a SOLID guideline for object-oriented design. It defines a responsibility as a reason for a class to change and uses a MySQL connection and query-handling example to show why separate responsibilities should be split. ### Source excerpt SOLID Object-Oriented Design ## SOLID Object-Oriented Design DevFeed: [SOLID Object-Oriented Design]() Original publisher: [Read original article]() Published: 2011-08-05T00:00:00Z Content type: tutorial Language: en Sources: [Radek Pazdera]() Topics: [object](), [Programming](), [Software](), [interface](), [Dependency Inversion]() Tags: [dependency-inversion-principle](), [interface](), [object-oriented](), [solid]() ### AI overview The article introduces SOLID, an acronym for five principles of object-oriented programming and design: single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion. It presents them as guidelines intended to support systems that are easier to maintain and extend over time. ### Source excerpt I build software products and write on the Internet. ## Object Incest DevFeed: [Object Incest]() Original publisher: [Read original article]() Published: 2011-03-23T00:00:00Z Content type: tutorial Language: en Sources: [Tim Kellogg]() Topics: [Code](), [interfaces](), [Development]() Tags: [classes](), [code](), [dependencies](), [design-patterns](), [interfaces](), [object-oriented]() ### AI overview The article defines "object incest" as a design anti-pattern in which two unrelated classes depend directly on each other. It explains that splitting a class without removing mutual dependencies still violates separation of concerns, and recommends extracting roles into interfaces so the classes depend on abstractions instead. ### Source excerpt Note: I thought I had read this term from somewhere else, but after a quick internet search turned up only dirty videos, I think I may be the sole "coiner" of the term. Many inexperience developers (and experienced ones too) have been known to make several common mistakes in object oriented design. Hence, the coining of the terms anti-pattern and code smell to refer to patterns of development (like design patterns) that lead to convoluted, overly complex code that costs exponentially to maintain and exhibits little value.Object incest is a pattern where two unrelated classes are intimately dependent on each other. Simply put, if object A directly relies on object B and B relies directly on A, you have two incestual objects. This usually happens to intermediate developers who realize that they need separation of concerns and break a class into two classes without actually breaking the dependencies. While it is understandable (and almost respectable) why a developer might commit object incest, it is no less dangerous and harmful to a code base full of child objects.Here is an example of object incest:class Brother { public Sister MySister { get; set; } private void GetMyHairBrushed() { MySister.BrushHair(this); } public void DefendFromBullies(Sister sis) { // ... }}class Sister { public Brother MyBrother { get; set; } public void BrushHair(Brother bro) { // ... } private void GetRidOfBullies() { MyBrother.DefendFromBullies(this); }}This is wrong because the two objects are so involved that it's hard to tell them apart, breaking the principal of separation of concerns. You can fix this by extracting roles from the objects as interfaces. Therefore, each object depends on some kind of object that can fulfill a role. A brother object needs someone to brush his hair, a sister needs someone to defend her from bullies.class Brother : IDefenderOfTheWeak, IPersonWithHair { public IHairBrusher MyHairBrushPartner { get; set; } private void BrushMyHair() { MyHairBrushPartner.Brus ## Writing Object-Oriented JavaScript in a Python-Inspired Style DevFeed: [Writing Object-Oriented JavaScript in a Python-Inspired Style]() Original publisher: [Read original article]() Author: Graham King Published: 2009-01-22T23:47:30Z Content type: tutorial Language: en Sources: [Graham King]() Topics: [JavaScript](), [Programming]() Tags: [code](), [constructor](), [function](), [javascript](), [module](), [object-oriented](), [properties](), [prototype](), [python](), [software]() ### AI overview A tutorial that translates a whimsical Moose Observation Project from Python to JavaScript and explains how to structure object-oriented JavaScript. It covers namespaces, constructor functions, the new operator, prototype methods, and instance properties. ### Source excerpt "Making Javascript look like Python: A whimsical Moose Observation Project"