# Polymorphism Published articles for Polymorphism. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Use C# unions and closed hierarchies in ASP.NET Core DevFeed: [Use C# unions and closed hierarchies in ASP.NET Core]() Original publisher: [Read original article]() Author: Dmitrii Korolev Published: 2026-09-10T17:00:00Z Content type: tutorial Language: en Sources: [.NET Blog]() Topics: [C# 15](), [ASP.NET Core](), [.NET](), [Polymorphism]() Tags: [asp-net-core](), [blazor](), [c-sharp](), [c-sharp-15](), [closed-hierarchies](), [json](), [minimal-api](), [mvc](), [net](), [net-11](), [openapi](), [polymorphism](), [signalr](), [system-text-json](), [union-types]() ### AI overview Explains how C# unions and closed hierarchies model API values with a fixed set of possible types in ASP.NET Core. It contrasts unions with open inheritance-based polymorphism and describes System.Text.Json support. ### Source excerpt Learn how C# unions and closed hierarchies work with System.Text.Json across ASP.NET Core Minimal APIs, MVC, SignalR, Blazor, and OpenAPI. The post Use C# unions and closed hierarchies in ASP.NET Core appeared first on .NET Blog. ## Modern App Protection Requires Polymorphism | Guardsquare DevFeed: [Modern App Protection Requires Polymorphism | Guardsquare]() Original publisher: [Read original article]() Author: Jason Cortlund - Technical Marketing Writer Published: 2026-08-18T13:45:43Z Content type: article Language: en Sources: [Guardsquare Blog]() Topics: [Mobile](), [Mobile Security](), [Polymorphism](), [Security](), [Development](), [Artificial Intelligence](), [Large Language Model]() Tags: [agentic-ai](), [ai](), [development](), [dexguard](), [ixguard](), [large-language-models-llms](), [mobile](), [polymorphism](), [protection](), [reverse-engineering](), [security](), [security-research](), [thought-leadership](), [vulnerabilities]() ### AI overview The article argues that mobile app protection should use polymorphism, with protections changing for each application build. It links this approach to the risks created by development speed, AI-generated code, and scalable reverse-engineering attacks. ### Source excerpt According to credit reporting agency Equifax, "...mobile app security is often neglected by developers -- making apps more vulnerable to fraud." The reason for this is quite simple for most organizations: development speed is the dominant priority. In fact, 79% of mobile developers cite time-to-market pressure as the top barrier to stronger protection. ## SpectrePaste: An AI-Assisted, Fileless PowerShell Malware Delivery System DevFeed: [SpectrePaste: An AI-Assisted, Fileless PowerShell Malware Delivery System]() Original publisher: [Read original article]() Author: Joshua Platt Published: 2026-07-06T18:54:30Z Content type: article Language: en Sources: [Walmart Global Tech]() Topics: [Artificial Intelligence](), [Malware](), [Threat Research](), [PowerShell](), [C2](), [Caching](), [Encryption](), [Resilience](), [Routing (disambiguation)](), [Polymorphism](), [Back end](), [Spec Driven Development]() Tags: [ai](), [artificial-intelligence](), [backend](), [c2](), [cache](), [cybersecurity](), [detection-engineering](), [encryption](), [malware](), [malware-analysis](), [polymorphism](), [powershell](), [resilience](), [routing](), [spec-driven-development](), [threat-intelligence]() ### AI overview The article describes SpectrePaste, a previously undocumented fileless malware delivery system that threat actors used with AI as its primary orchestrator and developer. Its early architecture included automated AMSI-bypass generation, XOR-encrypted payloads, resilient command-and-control traffic handling, caching, request queuing, and administrative priority routing. ### Source excerpt by Joshua Platt and Jason Reaves [TLP:CLEAR] Earlier this year, Google Threat Intelligence[1] reported threat actors are increasingly deploying novel, AI-enabled malware in active operations[2]. While investigating a recent OSINT article[3] on malware campaign activity reported as "DeepLoad", our threat intelligence team identified a separate, previously undocumented fileless delivery system we track as "SpectrePaste". The prior public reporting correctly suspected AI involvement in the "DeepLoad" delivery chain, but our analysis reveals a more conclusive and concerning reality. AI did not just play a supporting role. It acted as the primary orchestrator and developer behind the entire SpectrePaste system. Threat actors internally referred to the early system as "PasteFast Panel." In this initial iteration, the system was highly modular, structured, and designed specifically for resilience against high-volume bot traffic. One of the hallmarks of automated, AI-assisted development. The early architecture functioned as a centralized PowerShell payload delivery system with several notable features: Automated Evasion Generation: The paste builder module automatically prepended Anti-Malware Scan Interface (AMSI) bypass scripts to payloads upon creation, followed by XOR encryption using a custom obfuscator template. This ensured every payload served was dynamically packed. C2 Resilience & High-Load Handling: The most sophisticated feature of the early version was its custom cache manager queue system. The threat actors anticipated massive, simultaneous beaconing from compromised hosts. To prevent database exhaustion, the panel featured an automated threshold toggle. During traffic spikes, the system queued requests, cached the encrypted payloads in memory, and deduplicated IP addresses to ensure a single infected bot could not inadvertently DDoS the command server. Admin Priority Routing: Developer requirements explicitly prioritized operator access. Administrative routes ## 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 ## What Strong Typing Means in Programming Languages DevFeed: [What Strong Typing Means in Programming Languages]() Original publisher: [Read original article]() Published: 2025-08-28T01:33:05Z Content type: opinion Language: en Sources: [Tony Finch's blog]() Topics: [Programming language](), [Programming](), [integrity](), [Polymorphism](), [Java](), [TypeScript](), [Lean]() Tags: [integrity](), [java](), [languages](), [polymorphism](), [programming-language](), [rust](), [type-system](), [typescript]() ### AI overview The article explains why "strongly typed" is a poorly defined term and examines several possible meanings, including static versus dynamic typing, soundness of static type systems, and runtime type safety. It argues that these properties are not simply yes-or-no and discusses trade-offs and examples from languages including Java, TypeScript, Rust, Lean, JavaScript, Lua, and C. ### Source excerpt What does it mean when someone writes that a programming language is "strongly typed"? I've known for many years that "strongly typed" is a poorly-defined term. Recently I was prompted on Lobsters to explain why it's hard to understand what someone means when they use the phrase. I came up with more than five meanings! how strong? The various meanings of "strongly typed" are not clearly yes-or-no. Some developers like to argue that these kinds of integrity checks must be completely perfect or else they are entirely worthless. Charitably (it took me a while to think of a polite way to phrase this), that betrays a lack of engineering maturity. Software engineers, like any engineers, have to create working systems from imperfect materials. To do so, we must understand what guarantees we can rely on, where our mistakes can be caught early, where we need to establish processes to catch mistakes, how we can control the consequences of our mistakes, and how to remediate when somethng breaks because of a mistake that wasn't caught. strong how? So, what are the ways that a programming language can be strongly or weakly typed? In what ways are real programming languages "mid"? Statically typed as opposed to dynamically typed? Many languages have a mixture of the two, such as run time polymorphism in OO languages (e.g. Java), or gradual type systems for dynamic languages (e.g. TypeScript). Sound static type system? It's common for static type systems to be deliberately unsound, such as covariant subtyping in arrays or functions (Java, again). Gradual type systems migh have gaping holes for usability reasons (TypeScript, again). And some type systems might be unsound due to bugs. (There are a few of these in Rust.) Unsoundness isn't a disaster, if a programmer won't cause it without being aware of the risk. For example: in Lean you can write "sorry" as a kind of "to do" annotation that deliberately breaks soundness; and Idris 2 has type-in-type so it accepts Girard's paradox. T ## Sealed classes and interfaces in Kotlin DevFeed: [Sealed classes and interfaces in Kotlin]() Original publisher: [Read original article]() Published: 2023-09-04T00:01:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [sealed class](), [sealed interface](), [interface](), [abstract class](), [Inheritance](), [Polymorphism]() Tags: [inheritance](), [interface](), [kotlin](), [polymorphism](), [sealed](), [sealed-classes](), [sealed-interface](), [workshop-learning-programming]() ### AI overview This Kotlin tutorial explains sealed classes and sealed interfaces as restricted hierarchies whose direct subclasses are controlled. It contrasts them with regular interfaces and abstract classes, describes their package and module requirements, and explains their use in exhaustive expressions. ### Source excerpt What are sealed classes and interfaces in Kotlin and how do we use them. ## Abstract and Open Classes DevFeed: [Abstract and Open Classes]() Original publisher: [Read original article]() Author: author@typealias.com (Dave Leeds) Published: 2023-08-21T00:00:00Z Content type: tutorial Language: en Sources: [Dave Leeds on Kotlin - typealias.com]() Topics: [Code](), [interfaces]() Tags: [abstract-class](), [classes](), [compare](), [delegation](), [extend](), [function](), [implement](), [inheritance](), [interface](), [interfaces](), [introduction](), [kotlin](), [learn-to-program](), [open-class](), [polymorphism](), [programming](), [retro](), [speed](), [subclass](), [superclass]() ### AI overview A tutorial chapter explaining how to extend open and abstract classes to create subtypes and share general code. It compares this approach with interfaces and delegation, highlighting that each has advantages and disadvantages. ### Source excerpt In Chapter 12, we saw how we could use interfaces to create subtypes, and in the last chapter, we saw how we could use delegation with interfaces in order to share general code among specific classes. In this chapter, we'll learn how we can extend open and abstract classes to accomplish these same things with a different approach. Each approach has its advantages and disadvantages, so we'll also look at how they compare to one another. ## Interfaces 101 : Interface Design Considerations Ep. 7 DevFeed: [Interfaces 101 : Interface Design Considerations Ep. 7]() Original publisher: [Read original article]() Published: 2023-03-13T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [interfaces](), [Go Language](), [Polymorphism](), [IO](), [Programming]() Tags: [go](), [golang](), [interface](), [io](), [io-copy-function](), [io-interfaces](), [io-reader](), [io-writer](), [polymorphism](), [programming]() ### AI overview A video tutorial about Go interface design. It explains how interfaces express what code needs, discusses criteria for effective interfaces, and introduces Go's io.Reader and io.Writer interfaces. It also covers polymorphism through type assertions and cautions that overly large interfaces can weaken abstraction. ### Source excerpt Introduction In episode 6, Miki built a logger package with the aim of making it as versatile as possible. To achieve this, he constructed his logger object with a function that would: accept the io.Writer interface as a parameter and perform type assertions to retrieve other interface types as needed. By building this, Miki demonstrated how polymorphism is achieved with Go by changing the type of a variable with type assertions. ## Nullability in GraphQL and Apollo Kotlin DevFeed: [Nullability in GraphQL and Apollo Kotlin]() Original publisher: [Read original article]() Author: Benoit Lubek Published: 2023-02-27T08:10:00Z Content type: tutorial Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [Kotlin](), [client library](), [Code generation](), [Error Handling]() Tags: [apollo](), [client-library](), [error-handling](), [graphql](), [kotlin](), [mobile](), [null-safety](), [polymorphism]() ### AI overview This tutorial explains how Apollo Kotlin represents GraphQL nullability in generated Kotlin models. It covers nullable schema fields, conditional directives, fragments, polymorphism, and GraphQL partial responses caused by errors. ### Source excerpt The concept of is sometimes called a "billion dollar mistake". Mistake or not, is here to stay and there are ways to coexist peacefully! In fact, nullability is one of the key features of GraphQL, allowing API authors to clearly specify which fields of a type are nullable. As for Kotlin, the language supports nullability in its type system, significantly reducing the risk for errors - for example assigning a potentially value to a non-nullable field won't even compile! ## Interfaces 101 : Implementing Generics with Interfaces Ep. 1 DevFeed: [Interfaces 101 : Implementing Generics with Interfaces Ep. 1]() Original publisher: [Read original article]() Published: 2023-01-31T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [interfaces](), [Go Language](), [Mocking]() Tags: [code](), [developers](), [generic-programming](), [generics](), [go](), [go-types](), [golang](), [interfaces](), [mocking](), [polymorphism](), [series](), [types](), [video]() ### AI overview A video tutorial explains how Go interfaces can constrain the types accepted by generic functions. It covers defining generic functions, explicitly passing types, and addressing compiler recognition issues while replacing duplicate functions that return different types. ### Source excerpt Introduction Go interfaces are beneficial to Go developers because they: Allow interfaces to separate mechanism from behavior. Increase flexibility of function parameters. Enable mocking of function parameters. With the addition of generics in Go 1.18, interfaces can be used to constrain the types of values a generic function will accept. To dive deeper into Go interfaces, we invite you to join Miki in his latest series dedicated to Go interfaces. ## Why Are There Functions? DevFeed: [Why Are There Functions?]() Original publisher: [Read original article]() Author: Bruce Eckel Published: 2022-09-29T00:00:00Z Content type: opinion Language: en Sources: [Bruce Eckel - Computing Thoughts]() Topics: [Programming](), [function](), [Assembly](), [Polymorphism](), [C](), [reusable code]() Tags: [assembly](), [c](), [code](), [polymorphism](), [programming](), [reusable-code]() ### AI overview The article examines why programmers write functions, drawing on the author's experience with assembly language for embedded systems. It argues that functions reduce repeated code, memory use, duplicate debugging effort, and reliability risks, while enabling reusable code; C automates much of the calling work required in assembly language. ### Source excerpt Returning from giving my Polymorphism Unbound presentation at StrangeLoop (not yet available on YouTube, but all the examples and presentation slides are on Github), I found myself dissatisfied. Part of this was certainly my failure to cram a 2-hour presentation into 40 minutes (after cutting it down from a day-long, workshop-length size). The bigger issue was my inability to answer the essential question at the end of the presentation: why are we writing polymorphic functions? ## 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. ## Haskell 101 Lecture Notes DevFeed: [Haskell 101 Lecture Notes]() Original publisher: [Read original article]() Published: 2022-05-04T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Functional programming](), [Programming language](), [Programming]() Tags: [abstraction](), [constructor](), [function](), [functional-programming](), [haskell](), [pattern-matching](), [polymorphism]() ### AI overview Haskell 101 lecture notes introducing functions, function abstraction and application, expressions, values, types, algebraic data types, construction and deconstruction, pattern matching, polymorphism, and type constructors. ### Source excerpt Contents 1 Functions, Computations: Abstraction and application 2 Expressions, Values, Types 3 ADTs, Construction, Deconstruction 4 Polymorphism 5 Non-nullary type constructors, Kinds 1 Functions, Computations: Abstraction and application What is a function? f(x) = 4x + 2? And what's function application? f(x) = 4x + 2 f(5) = ? In mathematics, function application is the act of applying a function to an argument from its domain so as to obtain the corresponding value from its range. In this sense, function application can be thought of as the opposite of function abstraction. In functional programming languages, computations are based on function abstraction and application. An abstraction, a.k.a a function, is denoted through the lambda notation (\x -> ...). An application, a.k.a function application, is denoted by juxtaposition: an expression followed by another expression represents the application of the first expression to the following one. f = \x -> 4 * x + 2 -- `f` is an abstraction f 5 -- application of `f` to `5` 2 Expressions, Values, Types Haskell is a purely functional programming language. As such, all computations are done via the evaluation of expressions (syntactic terms) to yield values (abstract entities that we regard as answers). Every value has an associated type (intuitively, we can think of types as sets of values). 5 :: Integer 'a' :: Char inc :: Integer -> Integer [1,2,3] :: [Integer] ('b', 4) :: (Char, Int) sum [1,2,3] :: Integer inc 5 :: Integer sum :: [Integer] -> Integer The :: can be read "has type". All expression evaluate to a value, and all values have types, which means all expressions have types too. Above are some of the common types. Which of the following are expressions, and which are values? What are the types of the expressions? product [1,2,3] product [1,2,3] They are all expressions, and only the first two are values. The first one is a function abstraction, which is a value, the second one is a value constructed with the ## Changing a polymorphic\_type in Rails DevFeed: [Changing a polymorphic\_type in Rails]() Original publisher: [Read original article]() Author: Diego Gilon Published: 2022-02-18T16:57:47Z Content type: tutorial Language: en Sources: [Shopify Engineering](), [Shopify Engineering - Shopify Engineering]() Topics: [data]() Tags: [database](), [polymorphism](), [shopify](), [types]() ### AI overview A step-by-step Rails tutorial on changing polymorphic association storage from class names to arbitrary strings, making future module and class renames easier. ### Source excerpt How my team redefined the way we store one of the polymorphic associations in the Shopify codebase. This post is the solution we wish we found when we were looking. ## if-else-switch DevFeed: [if-else-switch]() Original publisher: [Read original article]() Published: 2021-03-06T00:00:00Z Content type: opinion Language: en Sources: [Robert C. Martin](), [The Clean Code Blog]() Topics: [Refactoring](), [Polymorphism](), [Software](), [systems](), [cloud-infrastructure]() Tags: [code](), [dependencies](), [monolithic-architecture](), [polymorphism](), [refactoring](), [software](), [source](), [structure]() ### AI overview The article argues that repeated if/else or switch statements create fragile systems and tangled dependencies. It recommends isolating the conditional logic in a factory and using polymorphic objects to break dependencies on lower-level modules, supporting more flexible component-based architectures. ### Source excerpt A few days ago someone tweeted a question asking which of the following PHP snippets was better than the others, or whether there might be an even better approach. I tweeted my answer in the following cryptic paragraph. Place the if/else cases in a factory object that creates a polymorphic object for each variant. Create the factory in 'main' and pass it into your app. That will ensure that the if/else chain occurs only once. Others have since asked me for an example. Twitter is not the best medium for that so... Firstly, if the sole intent of the programmer is to translate: 0->'male', 1->'female' otherwise -> 'unknown' ...then his refactoring #2 would be my preference. However, I have a hard time believing that the business rules of the system are not using that gender code for making policy decisions. My fear is that the if/else/switch chain that the author was asking about is replicated in many more places within the code. Some of those if/else/switch statements might switch on the integer, and others might switch on the string. It's not inconceivable that you'd find a if/else/switch that used an integer in one case and a string in the next! The proliferation of if/else/switch statements is a common problem in software systems. The fact that they are replicated in many places is problematic because when such statements are inevitably changed, it is easy to miss some. This leads to fragile systems. But there is a worse problem with if/else/switch statements. It's the dependency structure. Such statements tend to have cases that point outwards towards lower level modules. This often means that the module containing the if/else/switch will have source code dependencies upon those lower level modules. That's bad enough. We don't like dependencies that run from high level modules to low level modules. They thwart our desire to create architectures that are made up of independently deployable components. However, the above diagram shows that it's worse than that. Other hig ## Android and Java Technical Interview Questions for Large Technology Companies DevFeed: [Android and Java Technical Interview Questions for Large Technology Companies]() Original publisher: [Read original article]() Author: Budhdi Sharma Published: 2020-05-08T20:48:42Z Content type: tutorial Language: en Sources: [Android & Tech News -- Medium]() Topics: [Development](), [Android](), [Java](), [Polymorphism](), [Algorithms, Complexity]() Tags: [algorithms](), [android](), [android-development](), [crack](), [development](), [how-to](), [interview](), [java](), [polymorphism](), [tips]() ### AI overview This interview-preparation article outlines knowledge areas for Android development interviews, including Java fundamentals, Android questions, advanced development technologies, and cross-platform hybrid development. It highlights topics such as Java APIs, source-code implementation principles, algorithms, design patterns, equality and hash codes, primitive sizes, and polymorphism. ### Source excerpt The interviewer in interviews asked these questions with top-tier Internet companies. Familiarity with the knowledge points listed in this... Continue reading on AndroidPub " ## Abstracting Kotlin Sealed Classes DevFeed: [Abstracting Kotlin Sealed Classes]() Original publisher: [Read original article]() Author: Artur Dryomov Published: 2019-06-04T00:00:00Z Content type: article Language: en Sources: [Artur Dryomov]() Topics: [Kotlin](), [Polymorphism](), [Refactoring](), [Java]() Tags: [bytecode](), [java](), [kotlin](), [models](), [polymorphism](), [properties](), [refactoring](), [sealed](), [sealed-classes]() ### AI overview This article examines ways to declare common properties in Kotlin sealed class hierarchies. It compares approaches involving type declarations, constructors, and separate Java-rooted abstractions, including their ergonomics and generated bytecode implications. ### Source excerpt Things tend to be similar. Cars and bikes are different for sure but both have wheels, engines, exhaust systems and so on. Such similarities between models are usually described using basic polymorphism in virtual domain modeling. Kotlin makes this process a bit more pragmatic using sealed class declarations. Specifying type hierarchies using sealed classes is simple, but what about declaring common properties? Fortunately or not there are multiple ways to achieve this -- partially because of the Java baggage. Which one is the best? ## The Economics of Generated Code DevFeed: [The Economics of Generated Code]() Original publisher: [Read original article]() Published: 2019-03-26T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [Code](), [Library](), [Parsing](), [Polymorphism](), [JSON](), [API]() Tags: [api](), [code](), [json](), [library](), [parsing](), [polymorphism]() ### AI overview The article explains the economics of generated code: because a generator is written once but its output is repeated many times, optimizing generated output can quickly repay the investment. It examines method-reference counts and shows how consolidating behavior in a runtime-library base class, then explicitly referencing the supertype method, can reduce hundreds of redundant references to one in an API model layer. ### Source excerpt Among the many things that I've stolen learned from Jesse Wilson is the phrase "the economics of generated code". This captures the idea that the things we value when generating code are different than those we value for code that's manually written. A code generator is only written once but the code it generates occurs many times. Thus, any investment into making the generator emit more efficient code will pay for itself very quickly. This generally means output less code and allocate fewer objects wherever possible. I'd like to expand on that with two specific, real-world examples which I've run into. Extra Method References While it's not as much of a problem as it used to be, method reference count is still something worth keeping an eye on. This is especially true for generated code. Small changes in the generator can result in the count going up or down by the hundreds or thousands. It's common for generated classes to be a subtype of a class in the runtime library. Aside from facilitating polymorphism, this allows consolidating common utilities and behavior. Take a JSON model that wants to retain unknown keys and values encountered during parsing. Each generated class could maintain its own Map for the unknown pairs, but this is a great candidate for consolidation into a base class in the library. abstract class JsonModel { private final Map unknownPairs; public final Map getUnknownPairs() { return unknownPairs; } // ... } Not having a getUnknownPairs() method in each generated class should obviously reduce the count. But since the count is not just about declared methods, reducing the referenced methods in the generated code will also have an impact. Each generated class extends JsonModel and implements toString() which outputs its own fields and the getUnknownPairs() map. final class UserModel extends JsonModel { private final String name; private final String email; // ... @Override public String toString() { return "UserModel{ ## Modeling Polymorphism in Django DevFeed: [Modeling Polymorphism in Django]() Original publisher: [Read original article]() Author: Haki Benita Published: 2019-01-01T22:00:00Z Content type: tutorial Language: en Sources: [Haki Benita]() Topics: [Polymorphism](), [Django](), [Object-relational mapping](), [Database]() Tags: [article](), [articles](), [django](), [orm](), [polymorphism](), [relational-databases](), [techniques]() ### AI overview The article presents several techniques for modeling polymorphic objects in relational databases using Django's object-relational mapping (ORM). ### Source excerpt Modeling polymorphism in relational databases is a challenging task. In this article, we present several modeling techniques to represent polymorphic objects in a relational database using the Django object-relational mapping (ORM). ## Modern C++ for C Programmers: Part 3 DevFeed: [Modern C++ for C Programmers: Part 3]() Original publisher: [Read original article]() Published: 2018-07-02T19:30:31Z Content type: tutorial Language: en Sources: [Bert Hubert's writings]() Topics: [C++](), [Inheritance](), [Polymorphism](), [Programming](), [Code]() Tags: [c](), [c-plus-plus](), [code](), [inheritance](), [polymorphism](), [programming](), [programming-language]() ### AI overview Part 3 of a tutorial on modern C++ for C programmers explains inheritance and polymorphism, including base and derived classes, virtual methods, runtime type metadata, and related overhead. ### Source excerpt Welcome back! In part 2 I discussed basic classes, threading, atomic operations, smart pointers, resource acquisition and (very briefly) namespaces. In this part we continue with further C++ features that you can use to spice up your code 'line by line', without immediately having to use all 1400 pages of 'The C++ Programming Language'. Various code samples discussed here can be found on GitHub. If you have any favorite things you'd like to see discussed or questions, please hit me up on @bert_hu_bert or bert@hubertnet. ## Avoid Singletons to Write Testable Code DevFeed: [Avoid Singletons to Write Testable Code]() Original publisher: [Read original article]() Author: umer Published: 2016-05-27T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [Dependency injection](), [Mocking](), [Polymorphism](), [mutation-testing]() Tags: [code](), [dependency-injection](), [interfaces](), [polymorphism](), [testing](), [unit-testing](), [unit-tests]() ### AI overview This tutorial explains why Singleton implementations make unit testing and debugging difficult by hiding dependencies and tightly coupling code to a specific instance. It recommends creating shared objects in one place and passing them through constructors using dependency injection, while retaining the requirement for a single instance. ### Source excerpt Often times there is a need to share a single object of a class throughout the code base. For example, we might want to store all online users in one central registry or share a central queue amongst all producer and consumer objects. We want to: ensure that exactly one object of a class exists. provide a way to get that object. This is a valid and a very common requirement but is often equated and related to a design pattern called Singleton. While they provide a quick and easy solution, singletons are considered bad because they make unit testing and debugging difficult. Brian Button has made some valid arguments against singletons: [Singletons] provide a well-known point of access to some service in your application so that you don't have to pass around a reference to that service. How is that different from a global variable? (remember, globals are bad, right???) What ends up happening is that the dependencies in your design are hidden inside the code, and not visible by examining the interfaces of your classes and methods. You have to inspect the code to understand exactly what other objects your class uses. One of the underlying properties that makes code testable is that it is loosely coupled to its surroundings. This property allows you to substitute alternate implementations for collaborators during testing to achieve specific testing goals (think mock objects). Singletons tightly couple you to the exact type of the singleton object, removing the opportunity to use polymorphism to substitute an alternative. He's absolutely right. It's very difficult to write unit tests for code that uses singletons because it is generally tightly coupled with the singleton instance, which makes it hard to control the creation of singleton or mock it. Recently I came across a project that made very liberal use of singletons. When I asked the developer about it, he said: "I know singletons are bad. But I needed a single instance of objects in all these cases and had no choice ## The AnyStr type variable DevFeed: [The AnyStr type variable]() Original publisher: [Read original article]() Author: Guido van Rossum (noreply@blogger.com) Published: 2016-05-17T16:53:00Z Content type: tutorial Language: en Sources: [Guido van Rossum]() Topics: [Python](), [Polymorphism](), [function](), [Variable](), [networking]() Tags: [bug](), [debugging](), [function](), [polymorphism](), [python](), [types]() ### AI overview A tutorial on Python type annotations uses a parenthesize function to explain polymorphism across str and bytes, the Union type, and how static type checking exposes a bytes-versus-str bug. It introduces AnyStr as the subject of a separate discussion related to PEP 484 and the __fspath__() protocol. ### Source excerpt The AnyStr type variable I was drafting a blog post on how to add type annotations for the new __fspath__() protocol (PEP 519) when I realized that I should write a separate post about AnyStr . So here it is. A simple function on strings Let's write a function that surrounds a string in parentheses. We'll put it in a file named demo.py : def parenthesize(s): return '(' + s + ')' It works, too: >>> from demo import parenthesize >>> print(parenthesize('hola')) (hola) Of course, if you pass it something that's not a string it will fail: >>> parenthesize(42) Traceback (most recent call last): File "demo.py", line 1, in File "demo.py", line 2, in parenthesize TypeError: Can't convert 'int' object to str implicitly Adding type annotations Using PEP 484 type annotations we can clarify our little function's signature: def parenthesize(s: str) -> str: return '(' + s + ')' Nothing to it, right? Even if you've never heard of PEP 484 before you can guess what this means. (Note that PEP 484 also says that the runtime behavior is unchanged. The calls I showed above will still have exactly the same effect, including the TypeError raised by parenthesize(42) .) Polymorphic functions Now suppose this is actually part of a networking app and we need to be able to parenthesize byte strings as well as text strings. Here's how you'd implement that: def parenthesize(s): if isinstance(s, str): return '(' + s + ')' elif isinstance(s, bytes): return b'(' + s + b')' else: raise TypeError(f"That's not a string, it's a {type(s)}") # See PEP 498 With a fancy word we call that a polymorphic function. How do you write a signature for such a function? For the answer we have to dive a little deeper into PEP 484. It defines a nifty operator named Union that lets us state that a type can be either this or that (or something else). In our case, it's either str or bytes , so we can write it like this: from typing import Union def parenthesize(s: Union[str, bytes]) -> Union[str, bytes]: if isinstance(s, ## Object Oriented Programming in Go DevFeed: [Object Oriented Programming in Go]() Original publisher: [Read original article]() Published: 2013-07-10T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Object-oriented programming (OOP)](), [Polymorphism](), [interfaces]() Tags: [ardan-labs](), [blog](), [embedding](), [function](), [go](), [go-programming](), [golang](), [inheritance](), [interfaces](), [oop](), [polymorphism](), [private-access](), [programming](), [properties](), [structure]() ### 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. ## Singleton Design Pattern in Go DevFeed: [Singleton Design Pattern in Go]() Original publisher: [Read original article]() Published: 2013-07-06T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Object-oriented programming (OOP)](), [Polymorphism](), [Concurrency](), [configuration](), [XML]() Tags: [ardan-labs](), [blog](), [configuration](), [design-patterns](), [go](), [go-programming](), [golang](), [oop](), [polymorphism](), [programming](), [thread](), [xml]() ### AI overview This tutorial explains how to implement the Singleton design pattern in Go. It discusses managing shared resources in multithreaded applications, Go's package and type scoping, and the role of interfaces in providing polymorphic behavior without inheritance. ### Source excerpt Multi-threaded applications are very complicated, especially when your code is not organized and consistent with how resources are accessed, managed and maintained. If you want to minimize bugs you need philosophies and rules to live by. Here are some of mine: Resource allocation and de-allocation should be abstracted and managed within the same type. Resource thread safeness should be abstracted and managed within the same type. A public interface should be the only means to accessing shared resources. Any thread that allocates a resource should de-allocated the same resource. In Go we don't have threads but Go Routines. The Go runtime abstracts the threading and task swapping of these routines. Regardless, the same philosophies and rules apply. One of my favorite design patterns is the Singleton. It provides a great implementation when you only need one instance of a type and that type manages shared resources. A Singleton is a design pattern where the type creates an instance of itself and keeps that reference private. Access to the shared resources managed by that reference is abstracted through a static pubic interface. These static methods also provide thread safeness. The application using the Singleton is responsible for initializing and de-initializing the Singleton but never has direct access to the internals. It escaped me for some time how to implement a Singleton in Go because Go is not a traditional object oriented programming language and there are no static methods. I consider Go to be a light object oriented programming language. Yes it does have encapsulation and type member functions but it lacks inheritance and therefore traditional polymorphism. In all of the OOP languages I have ever used, I never used inheritance unless I wanted to implement polymorphism. With the way interfaces are implemented in Go there is no need for inheritance. Go took the best parts of OOP, left out the rest and gave us a better way to write polymorphic code. In Go we c [Next page]()