class UserNameTrimmer
class UserEmailLowercaser
class UserAgeValidator
class UserNormalizerCoordinator

interface PriceRule
class DefaultPriceRule implements PriceRule
class PriceRuleRegistry
class PriceRuleFactory

class Storage
class ReadOnlyStorage extends Storage:
    function write(data):
        throw unsupported_operation

interface CanGetName
interface CanSetName
interface CanValidateName
interface CanNormalizeName

interface ClockProvider
class SystemClockProvider implements ClockProvider
class ClockProviderFactory
class ClockProviderFactoryProvider

interface Thing
class AbstractThing implements Thing
class AbstractNamedThing extends AbstractThing
class ConfigurableNamedThing extends AbstractNamedThing
class RuntimeConfigurableNamedThing extends ConfigurableNamedThing
class UserRuntimeConfigurableNamedThing extends RuntimeConfigurableNamedThing

type Thing:
    name
    config

function run_thing(thing, runtime):
    use thing.name
    use thing.config
    use runtime

class Exporter
class CsvExporter extends Exporter
class CompressedCsvExporter extends CsvExporter
class EncryptedCompressedCsvExporter extends CompressedCsvExporter

exporter = compose(
    csv_format,
    compression,
    encryption,
)

exporter.export(data)

class UserName:
    value

class UserAge:
    value

class UserEmail:
    value

class User:
    name: UserName reference
    age: UserAge reference
    email: UserEmail reference

type User:
    name
    age
    email

interface UserFactory
class DefaultUserFactory implements UserFactory
class UserFactoryProvider
class UserFactoryProviderFactory

user = UserFactoryProviderFactory.create().provider().factory().create_user(data)

user = create_user(data)

function draw_frame(items):
    objects = items.map(item -> new DrawableItemWrapper(item))
    objects.each(object -> object.render())

function draw_frame(items):
    for each item in items:
        render item

# Poor patterns

Poor patterns include blindly applying SOLID, Uncle Bob-style “Clean Code”, or
old OOP patterns when they add ceremony, indirection, or hidden costs instead of
making the system simpler.

## What to look for

Look for code shaped by patterns such as:

- SOLID applied mechanically
- “Clean Code” rules applied mechanically
- deep type hierarchies
- reference types for everything
- ignoring memory and performance implications in the name of “maintainability”

## Why it matters

Patterns can make code worse when they add indirection, allocation, dispatch,
hierarchy, or conceptual weight without a real need.

Maintainability does not mean ignoring memory and performance implications.

Prefer composition over inheritance when behavior can be assembled directly instead of encoded in a type hierarchy.

## SOLID anti-patterns

SOLID concepts can be useful, but applied mechanically they often create slop.

### Single Responsibility Principle

Anti-pattern: splitting code until every tiny operation becomes a separate class, service, or function, even when the pieces do not make sense independently.

```text
class UserNameTrimmer
class UserEmailLowercaser
class UserAgeValidator
class UserNormalizerCoordinator
```

This may satisfy a narrow idea of “one responsibility” while making behavior harder to read as a whole.

### Open/Closed Principle

Anti-pattern: adding extension points, inheritance, plugins, or registries before there is a real need for variation.

```text
interface PriceRule
class DefaultPriceRule implements PriceRule
class PriceRuleRegistry
class PriceRuleFactory
```

This can make simple code harder to change because future flexibility was guessed too early.

### Liskov Substitution Principle

Anti-pattern: deep inheritance hierarchies where subclasses technically share a parent type but violate expectations through special cases, unsupported operations, or surprising overrides.

```text
class Storage
class ReadOnlyStorage extends Storage:
    function write(data):
        throw unsupported_operation
```

The type relationship claims substitutability, but the behavior does not support it.

### Interface Segregation Principle

Anti-pattern: creating many tiny interfaces that add names, files, dispatch, and navigation without reducing real coupling.

```text
interface CanGetName
interface CanSetName
interface CanValidateName
interface CanNormalizeName
```

Small interfaces are not automatically simple if they fragment one concept across many places.

### Dependency Inversion Principle

Anti-pattern: wrapping every direct dependency in an interface, adapter, provider, or factory even when there is only one implementation and no useful boundary.

```text
interface ClockProvider
class SystemClockProvider implements ClockProvider
class ClockProviderFactory
class ClockProviderFactoryProvider
```

This can replace a clear dependency with ceremony and indirection.

## Pseudo-code examples

### Bad: deep type hierarchy

```text
interface Thing
class AbstractThing implements Thing
class AbstractNamedThing extends AbstractThing
class ConfigurableNamedThing extends AbstractNamedThing
class RuntimeConfigurableNamedThing extends ConfigurableNamedThing
class UserRuntimeConfigurableNamedThing extends RuntimeConfigurableNamedThing
```

The hierarchy becomes the thing the reader must understand before understanding
the behavior.

### Better: flatter data and behavior

```text
type Thing:
    name
    config

function run_thing(thing, runtime):
    use thing.name
    use thing.config
    use runtime
```

Prefer a simpler shape when the hierarchy does not carry real value.

### Bad: inheritance for assembled behavior

```text
class Exporter
class CsvExporter extends Exporter
class CompressedCsvExporter extends CsvExporter
class EncryptedCompressedCsvExporter extends CompressedCsvExporter
```

The type hierarchy encodes combinations of behavior.

### Better: composition over inheritance

```text
exporter = compose(
    csv_format,
    compression,
    encryption,
)

exporter.export(data)
```

Assemble behavior directly when that is simpler than encoding combinations in subclasses.

### Bad: reference types for everything

```text
class UserName:
    value

class UserAge:
    value

class UserEmail:
    value

class User:
    name: UserName reference
    age: UserAge reference
    email: UserEmail reference
```

Reference types for everything can add allocation, navigation, and runtime cost
without improving the system.

### Better: use direct values when appropriate

```text
type User:
    name
    age
    email
```

Do not introduce reference-heavy structure unless it has a real purpose.

### Bad: ceremony in the name of maintainability

```text
interface UserFactory
class DefaultUserFactory implements UserFactory
class UserFactoryProvider
class UserFactoryProviderFactory

user = UserFactoryProviderFactory.create().provider().factory().create_user(data)
```

This may satisfy pattern rules while making the actual behavior harder to see.

### Better: direct construction when enough

```text
user = create_user(data)
```

Avoid pattern ceremony when direct code is simpler and sufficient.

### Bad: ignoring performance implications

```text
function draw_frame(items):
    objects = items.map(item -> new DrawableItemWrapper(item))
    objects.each(object -> object.render())
```

A maintainability argument is weak if the code creates avoidable memory or
performance costs in a hot path.

### Better: consider the runtime context

```text
function draw_frame(items):
    for each item in items:
        render item
```

When memory or performance matters, do not hide costs behind abstraction.