# 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. ## Object-Oriented Programming in Python vs Java DevFeed: [Object-Oriented Programming in Python vs Java]() Original publisher: [Read original article]() Author: Jon Fincher Published: 2026-10-31T14:00:00Z Content type: comparison Language: en Sources: [Real Python]() Topics: [Object-oriented programming (OOP)](), [Java](), [Python](), [class](), [object](), [Inheritance](), [Polymorphism](), [subclass](), [constructor]() Tags: [access-control](), [car](), [classes](), [code](), [color](), [compare](), [comparison](), [compilation-error](), [complete](), [composition](), [how-to](), [java](), [knowledge](), [learn](), [object](), [object-oriented](), [object-oriented-programming](), [programming](), [python](), [vs]() ### AI overview The article shows how Java OOP concepts translate into Python and where the languages differ. Java declares typed attributes in class bodies, commonly keeps them private behind getters and setters, and restricts classes to single inheritance while allowing shared behavior through interfaces. Python creates instance attributes with `self` in `__init__`, exposes them by default, and offers properties for controlled access; underscore naming conventions signal non-public attributes but do not provide Java-style access control. Python also supports multiple inheritance and duck typing, while Java uses interface types for polymorphic interchangeability. Both languages provide reflection and type checks, though the article describes Python's `dir()`, `getattr()`, and `callable()` workflow as simpler than Java's reflection APIs. Python dunder methods can customize representations and overload operators; the article notes Java has no comparable operator overloading. Examples use a `Car` class to illustrate these mechanisms and practical pitfalls, including class versus instance attributes. ### Source excerpt Compare Python vs Java for object-oriented programming and learn how to apply your Java knowledge of classes and objects to Python in a Pythonic way. ## A Modern Smalltalk DevFeed: [A Modern Smalltalk]() Original publisher: [Read original article]() Author: Al Williams Published: 2026-10-30T18:30:54Z Content type: article Language: en Sources: [Hackaday]() Topics: [Object-oriented programming (OOP)](), [Squeak/Smalltalk](), [object](), [Polymorphism]() Tags: [architecture](), [arduino](), [browser](), [c-plus-plus](), [clone](), [desktop](), [free](), [git](), [gnu](), [help](), [install](), [introduced](), [mvc](), [nice](), [object-oriented](), [open](), [operator](), [packages](), [raspberry](), [smalltalk](), [software-development]() ### AI overview Cuis Smalltalk is a free, portable Smalltalk-80 environment that keeps a simple core and adds complexity through packages. It replaces the traditional MVC framework with Morphic while retaining a style familiar to users of 1990s Smalltalk. The desktop includes workspaces, help documents, and a transcript, and a class browser helps explore classes and their messages. The language treats operations such as addition as messages sent between objects, which can respond differently to the same message. Cuis uses rolling releases, though a stable release may suit application deployment. Packages for Arduino communication over a serial port exist, but they have not been updated lately and may need work. ### Source excerpt In the history of object-oriented (OO) computer languages, Smalltalk has a special place. It wasn't the first OO language, and it hasn't spread as well as some others. But it ...read more ## Inheritance and Composition: A Python OOP Guide DevFeed: [Inheritance and Composition: A Python OOP Guide]() Original publisher: [Read original article]() Author: Isaac Rodriguez Published: 2026-10-30T14:00:00Z Content type: article Language: en Sources: [Real Python]() Topics: [Inheritance](), [Object-oriented programming (OOP)](), [Python](), [Polymorphism](), [class](), [Learning](), [Tutorial]() Tags: [abstract-class](), [cardinality](), [class](), [classes](), [code-duplication](), [component](), [components](), [composition](), [design](), [guide](), [inheritance](), [object](), [object-oriented](), [oop](), [python](), [relationships]() ### AI overview Inheritance models an "is a" relationship and reuses a base class's interface and implementation; composition models a "has a" relationship, combining objects while keeping their classes more loosely coupled. The excerpt illustrates inheritance with employee types sharing payroll behavior, and shows how expanding roles and pay policies can create large hierarchies. Multiple inheritance can introduce method resolution order and diamond problems that require explicit handling. The composition design instead gives employees separate role and payroll policy objects, so behaviors can be combined or changed without multiplying employee subclasses. The excerpt also covers Python's implicit inheritance from `object`, abstract base classes, and duck typing: a payroll system can accept any object providing the attributes and method it uses. The supplied text ends during the composition example, so its later implementation and conclusions are not available. ### Source excerpt Learn how inheritance and composition in Python model is-a and has-a relationships, and when to use each to design flexible object-oriented code. ## Your Wish Is My Commit: Over-Compliant Refactoring in AI Coding Agents DevFeed: [Your Wish Is My Commit: Over-Compliant Refactoring in AI Coding Agents]() Original publisher: [Read original article]() Author: Haocong Jiang, Sadra Sabouri, Sepand Haghighi, Souti Chattopadhyay Published: 2026-10-28T04:00:00Z Content type: article Language: en Sources: [arXiv: Software Engineering]() Topics: [AI-assisted coding](), [agentic-coding](), [Tech Debt](), [codex](), [Claude Code]() Tags: [agents](), [ai](), [ai-coding-agents](), [churn](), [claude-code](), [code](), [codex](), [coding](), [coding-agents](), [compliance](), [cs-hc](), [cs-se](), [developers](), [language-models](), [large-language-models](), [object-oriented](), [refactor](), [refactoring](), [review](), [software-engineering](), [technical-debt]() ### AI overview A controlled study found that Codex and Claude Code models kept refactoring after the code was already clean, even resuming edits after saying they were done. Across algorithmic (50) and object-oriented (10) suites, five models and more than 3,000 turns, every model continued editing; in some cases, the codebase was rewritten up to 31 times its original size before the first stop. The authors frame this as costly over-compliance that can add churn, technical debt and review burden. They define six behavioral signals intended to help developers and tool builders detect and curb it. The supplied text is an abstract, so it does not detail the signals or compare individual agents or models. ### Source excerpt arXiv:2610.36346v1 Announce Type: new Abstract: Large language models are known to be sycophantic, over-complying with users even when doing so is unproductive. When these models act as coding agents, this can be costly: an agent that keeps editing after no edit improves the code writes churn, technical debt, and review burden into the codebase. Yet the consequences of sycophancy in software engineering remain largely understudied. To understand them, we run a controlled study of iterative refactoring, an open-ended task with no stopping criterion, where any edit an agent makes once the code is already clean reflects compliance rather than improvement. Across algorithmic (n=50) and object-oriented (n=10) suites, we repeatedly ask two widely used agents, Codex and Claude Code, to refactor further across five models. Over 3,000 turns, we define six behavioral signals of over-compliance. We hypothesized that a capable agent would stop once it recognized an optimized codebase; none did. Every model kept editing, rewriting up to 31x the original codebase before first stopping and resuming edits even after declaring the task complete. Over-compliance is a costly, multi-turn behavior that compounds with every turn, and our six signals give developers and tool builders a way to detect and curb it. ## Object-Oriented Harness: Evolving Agent Harnesses through Object-Oriented Design DevFeed: [Object-Oriented Harness: Evolving Agent Harnesses through Object-Oriented Design]() Original publisher: [Read original article]() Author: Gaotang Li, Bhavana Dalvi Mishra, Yifei Ming, Yanfei Chen, Zhongying CuiZhu, Lesly Miculicich, Long T. Le, Rui Meng, Chun-Liang Li, Hanghang Tong, Chen-Yu Lee, Tomas Pfister Published: 2026-10-21T04:00:00Z Content type: article Language: en Sources: [arXiv: Software Engineering]() Topics: [Agent Harness](), [Object-oriented programming (OOP)](), [subclass](), [Inheritance](), [class]() Tags: [agent-harnesses](), [benchmarks](), [cs-cl](), [cs-se](), [design](), [hierarchy](), [inheritance](), [object-oriented](), [performance](), [router](), [routing]() ### AI overview OO-Harness addresses varied task needs by evolving a hierarchy of specialized executable harnesses. During training, an evolution agent uses execution records to create harness subclasses that inherit from a base or existing specialized harness. At test time, a router applies lessons learned during training to select a harness for each task. On three long-horizon benchmarks covering business workflows, workspace tasks, and tool use, it achieved the best performance among the compared methods, with an absolute improvement of up to 15% over the base. The supplied abstract does not specify benchmark details or the ablation findings. ### Source excerpt arXiv:2610.28380v1 Announce Type: cross Abstract: Agent harnesses are executable code that specifies the prompts, tools, and control flow around a language model. A single global harness can struggle with heterogeneous tasks that require different execution strategies. In this work, we introduce Object-Oriented Harness (OO-Harness), a harness optimization framework that evolves a hierarchy of executable harness classes using object-oriented design. During training, an evolution agent uses execution records to create a family of specialized harnesses, each implemented as a subclass of the base or an existing specialized harness via inheritance. At test time, a harness router uses routing lessons accumulated during training to select a specific harness for each task. Across three long-horizon benchmarks spanning business workflows, workspace tasks, and tool use, OO-Harness achieves the best performance among the compared methods, with an absolute improvement of up to 15% over the base. Extensive ablation studies examine the contributions of its core components. ## The Art of Object-Oriented Programming DevFeed: [The Art of Object-Oriented Programming]() Original publisher: [Read original article]() Author: Syed Ahmer Shah Published: 2026-10-04T11:53:47Z Content type: tutorial Language: en Sources: [HackerNoon]() Topics: [Object-oriented programming (OOP)](), [Polymorphism](), [solid principles](), [Inheritance](), [class](), [object](), [Dependency injection]() Tags: [common-oop-design-mistakes](), [composition](), [composition-over-inheritance](), [coupling](), [coupling-and-cohesion-in-oop](), [design-patterns](), [four-pillars-of-oop](), [inheritance](), [object-oriented](), [object-oriented-programming](), [oop-design-principles](), [oop-principles](), [polymorphism](), [programming]() ### AI overview A practical tutorial explains object-oriented programming through classes, objects, state, behavior, encapsulation, abstraction, inheritance, and polymorphism. It compares composition with inheritance and discusses association, aggregation, coupling, cohesion, and common design mistakes, using code examples to show how responsibilities can be separated in a software system. ### Source excerpt Understand OOP from classes and objects to composition, inheritance, polymorphism, coupling, and cohesion with practical examples. ## Object-Oriented Programming (OOP) in Python DevFeed: [Object-Oriented Programming (OOP) in Python]() Original publisher: [Read original article]() Author: David Amos Published: 2026-09-26T14:00:00Z Content type: tutorial Language: en Sources: [Real Python]() Topics: [Object-oriented programming (OOP)](), [Python](), [Inheritance](), [object](), [Polymorphism]() Tags: [class](), [classes](), [how-to](), [inheritance](), [object-oriented](), [oop](), [programming](), [python](), [tutorial]() ### AI overview This tutorial introduces object-oriented programming in Python, explaining how classes define objects and how objects group data with methods. It covers inheritance, encapsulation, abstraction, polymorphism, and creating instances from classes. ### Source excerpt Learn object-oriented programming in Python: the OOP paradigm, classes and inheritance, and how to instantiate objects from a class. ## Support Local Variables DevFeed: [Support Local Variables]() Original publisher: [Read original article]() Author: Max Bernstein Published: 2026-09-04T00:00:00Z Content type: article Language: en Sources: [Max Bernstein's Blog]() Topics: [Programming](), [Ruby](), [Compiler](), [Optimization](), [implementation](), [Programming language]() Tags: [code](), [compiler](), [jit](), [language](), [machine](), [memory](), [object-oriented](), [optimization](), [programming](), [programming-language](), [ruby](), [ssa](), [variables](), [virtual-machine]() ### AI overview The article introduces ZJIT, a method-based just-in-time compiler for Ruby. It explains how ZJIT uses global and local optimization passes and represents local variables as static single-assignment values to compile Ruby semantics correctly and efficiently. ### Source excerpt Discovering and supporting all of the wild semantics for local variables in Ruby was so interesting that the ZJIT team decided to write a paper about it: Support Local Variables (PDF). It's also the first bit of academic literature that documents and explains ZJIT. It's published at VMIL 2026, where someone on our team will be presenting it. Abstract Ruby is a dynamically typed and object-oriented programming language. Its primary implementation, CRuby, contains a bytecode virtual machine and a mature lazy basic block versioning (LBBV) just-in-time (JIT) compiler called YJIT. In order to both implement more advanced optimizations than YJIT supports and also encourage more outside contributions, we present a new method-based JIT called ZJIT. Like YJIT, ZJIT compiles from bytecode to machine code. Unlike YJIT, ZJIT has multiple global and local optimization passes. ZJIT's high-level intermediate representation is in static single assignment (SSA) form. In order to optimize Ruby's local variables, ZJIT lifts local variables into SSA values. This is a departure from how other Ruby compilers handle locals: other JIT compilers either leave local variables as memory loads and stores or do advanced partial evaluation to recover SSA values from memory. While implementing locals, we (re-)discovered what features make local variables in Ruby especially challenging to compile correctly and efficiently. We demonstrate these features and illustrate how we solved these problems in ZJIT. ## The primitive paradox: Reclaiming software discipline in an agentic world DevFeed: [The primitive paradox: Reclaiming software discipline in an agentic world]() Original publisher: [Read original article]() Author: Richard Gall Published: 2026-07-14T00:00:00Z Content type: article Language: en Sources: [Thoughtworks Insights]() Topics: [Agentic AI](), [software-architecture](), [Software Engineering](), [Programming](), [API](), [function](), [Scalability](), [Inheritance]() Tags: [agentic](), [agentic-ai](), [api](), [architecture](), [design-patterns](), [engineering](), [inheritance](), [object-oriented](), [platforms](), [re]() ### AI overview This article argues that agentic AI systems need a disciplined architectural language built from explicit, composable primitives. It contrasts these primitives with higher-level patterns and discusses capability APIs, atomic tool design, autonomous units of work, and the risks of unreliable composition. ### Source excerpt The primitive paradox: Reclaiming software discipline in an agentic world ## 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](), [interface](), [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](), [ECMAScript](), [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. ## Extend or implement DevFeed: [Extend or implement]() Original publisher: [Read original article]() Author: Brent Published: 2024-08-21T00:00:00Z Content type: opinion Language: en Sources: [Stitcher]() Topics: [Object-oriented programming (OOP)](), [Inheritance](), [abstract class](), [interface](), [Polymorphism](), [Laravel](), [C++](), [Symfony]() Tags: [c-plus-plus](), [class](), [inheritance](), [interface](), [laravel](), [object-oriented](), [oop](), [symfony]() ### AI overview A personal essay examines the difference between extending an abstract class and implementing an interface, arguing that inheritance is often used to provide configuration and flexibility in ways that do not fit its intended role in object-oriented programming. It discusses examples from Laravel, Symfony, and C++ and reflects on Alan Kay's critique of how OOP evolved. ### Source excerpt Read the full post on https://stitcher.io/blog/extends-vs-implements ## 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)](), [interface](), [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]() 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. ## Immutability we can afford DevFeed: [Immutability we can afford]() Original publisher: [Read original article]() Author: Roman Elizarov Published: 2020-07-22T09:18:28Z Content type: article Language: en Sources: [Roman Elizarov]() Topics: [Programming language](), [Object-oriented programming (OOP)](), [User Interfaces](), [Cache](), [class](), [Boilerplate](), [Assembly]() Tags: [abstractions](), [framework](), [immutability](), [imperative](), [languages](), [object-oriented](), [primary](), [programming](), [programming-languages](), [state](), [ui](), [variables]() ### AI overview The article argues that immutable state is increasingly practical because modern machines can absorb costs that once made it unattractive, while immutability reduces errors caused by unexpected changes to shared state. With mutable repository data passed through asynchronous pipelines, receivers may see later changes, making caching difficult and defensive copying necessary. The article acknowledges that immutable updates can require copying and that immutable data structures may be slower, especially as data grows; it says resource efficiency still matters in constrained systems and at massive scale. It points to modern languages giving immutability greater status and to React, Compose, and SwiftUI using immutable data representations with unidirectional UI flows. The supplied text is an excerpt and does not establish full-document coverage. ### Source excerpt Photo by Li Yang on Unsplash At the dawn of software engineering computers were programmed directly in machine code, then in assembly, and only later in higher-level languages. Computers are imperative. They operate by executing instructions that mutate their state, stored in registers and memory. Naturally, the same was true about programming languages. In the old world of expensive computers with limited resources, the primary concern was an efficient translation of higher-level abstractions into low-level code. The past glory of mutable state It used to be a normal practice to write software in a way that mimics the actual computer architecture with thousands of global variables that are being mutated by various pieces of the system. It might be shocking for a modern developer to learn that just recently there were cars on the street, designed as late as 2005, that ran what we would call the "Spaghetti" code. The software industry, in general, had firmly moved past the unruly global state before the end of the last century. The rise of the object-oriented programming paradigm had established an orderly approach with the encapsulation of all the mutable state in our software systems inside of objects. It had fueled tremendous growth in the complexity of modern software, layering abstractions above abstractions, while still maintaining a reasonable degree of human's ability to make sense of it. However, any developer who worked on a non-trivial piece of UI using an object-oriented framework, or had programmed in another domain with lots of asynchronously occurring events, can tell you stories of debugging all those cases where mutable state, even encapsulated into objects, continually trips you. You expect this object to be in a such and such state, but due to some rare sequence of events, it turns out to be in a state you did not expect, having been mutated by another piece of code. For example, take a popular architectural pattern where a repository class encapsu ## What are objects anyway? - Rant With Brent 02 DevFeed: [What are objects anyway? - Rant With Brent 02]() Original publisher: [Read original article]() Author: Brent Published: 2019-06-05T00:00:00Z Content type: opinion Language: en Sources: [Stitcher]() Topics: [object](), [Object-oriented programming (OOP)](), [Programming]() Tags: [apple](), [object](), [object-oriented](), [oop](), [podcasts](), [programming](), [rant](), [spotify](), [take]() ### AI overview A podcast episode examines the original definition of object-oriented programming and compares it with how OOP is understood today. ### Source excerpt Read the full post on https://stitcher.io/blog/what-are-objects-anyway-rant-with-brent ## 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? ## Object oriented generators DevFeed: [Object oriented generators]() Original publisher: [Read original article]() Author: Brent Published: 2017-06-17T00:00:00Z Content type: tutorial Language: en Sources: [Stitcher]() Topics: [generators](), [file](), [object](), [IO]() Tags: [code](), [file](), [generators](), [memory](), [object](), [object-oriented](), [tests]() ### AI overview An article compares an object-oriented implementation of a generator that reads lines from a large file with a generator-function approach. It reports similar execution time and memory usage, while arguing that the object-oriented version is easier to reuse. ### Source excerpt Read the full post on https://stitcher.io/blog/object-oriented-generators ## Reducing Type Hierarchies DevFeed: [Reducing Type Hierarchies]() Original publisher: [Read original article]() Published: 2016-10-09T00:00:00Z Content type: article Language: en Sources: [William Kennedy]() Topics: [Object-oriented programming (OOP)](), [interface](), [Inheritance](), [Polymorphism](), [data type]() Tags: [ardan-labs](), [blog](), [c-sharp](), [composition](), [go](), [go-programming](), [golang](), [hierarchy](), [inheritance](), [interfaces](), [java](), [object-oriented](), [object-oriented-programming](), [programming](), [reuse](), [types]() ### AI overview The excerpt argues that Go's lack of base types and subtyping makes traditional object oriented type hierarchies a poor fit for some code. It proposes grouping concrete types by shared behavior rather than shared state, using interfaces to group and decouple them, and using composition for type reuse. Its examples begin with an embedded generic Animal type specialized for Dog and Cat behavior; the excerpt ends during the example and does not show the later guidelines. ### Source excerpt Introduction I see a lot of developers coming to Go from object oriented programming languages such as C# and Java. Because these developers have been trained to use type hierarchies, it makes sense for them to use this same pattern in Go. However, there are aspects of Go that don't allow type hierarchies to provide the same level of functionality they do in other object oriented programming languages. Specifically, the concepts of base types and subtyping don't exist in Go so type reuse requires a different way of thinking. ## Functional programming in the small, with Swift DevFeed: [Functional programming in the small, with Swift]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2015-09-09T15:00:23Z Content type: tutorial Language: en Sources: [Miguel Quinones]() Topics: [Functional programming](), [Swift](), [Programming](), [Closure](), [Objective-C](), [Object-oriented programming (OOP)]() Tags: [apps](), [closure](), [functional-programming](), [functions](), [ios](), [library](), [object-oriented](), [objective-c](), [programming](), [swift]() ### AI overview The author recommends "Functional Programming in the small, Object Oriented in the large" for Swift iOS teams: UIKit and other Apple frameworks are object-oriented, so adopting FP need not mean restructuring an app. Swift closures are first-class functions, with concise syntax and trailing-closure support that can aid readability and DSLs; Objective-C blocks and selectors are described as less uniform and more complex. Learning function signatures, including generic ones, helps identify how functions compose and what their types imply, though Swift does not guarantee purity. The author encourages using map, filter, reduce, and flatMap to write declarative transformations, while advising ordinary loops when no result is being produced. Custom operators can hide the mechanics of connecting functions, but may be cryptic to readers unfamiliar with them. The practical goal is clearer, maintainable code, with style choices weighed against team readability. ### Source excerpt In a previous post, I wrote about the choice of paradigms that Swift presents for it's target audience. I also gave my opinion on how people with different backgrounds might see and approach the Functional Programming paradigm. In this post I want to share how I started to take advantage of FP with Swift for the practical domain of iOS developers: Building apps. Silver bullets In software development there are no silver bullets to kill your problems and move on. We always need to find tradeoffs and evaluate our options to decide what would be the best choice. We often need to consider not only the technical aspects but cultural or team aspects too. iOS applications involve a great deal of UI programming. The iOS frameworks are object-oriented, and Swift is not a pure FP language. Throwing away all the code from Apple's frameworks just to make our code more functional is not a realistic approach. Thus we need to balance where we want to use from different programming paradigms. For a beginner, or a team with not too much experience with FP, my choice would be doing Functional Programming in the small, Object Oriented in the large. FP in the small using Swift Let's look at the features of Swift and the standard library that help write more 'functional' without having to restructure or change how we build a project. Better functions One of the first terms you will hear when diving into FP is that functions are first-class citizens, or the language supports higher-order functions. What this means is that functions are treated like any other type. Think as functions being treated like objects; They can accept other functions as input, return other functions, and be stored and passed around. Under this definition Objective-C kind of supports this, but it's lacking in several areas. Firstly, there's a difference between blocks and selectors, the way to use them is different and the syntax is more complex. Secondly, in Swift a closure is a function without name, and they bo ## 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. [Next page]()