Проблема в том, что поведение объекта может зависеть от его внутреннего состояния. Да, это проблема! Приведу парочку примеров на Java о том, что я имею в виду.

Вот пример хорошего класса, поведение которого относительно независимо от состояния объекта:

class Simple
{
  private int a = 0;

  public void add(int b)
  {
    a = a + b;
  }

  public int getA()
  {
    return a;
  }
}

Здесь метод "add" работает одинаково независимо от значения свойства "a". А вот пример похожего класса, где метод "add" ведёт себя более изощрённо, ориентируясь на значение "a".

class Difficult
{
  private int a = 0;

  public void add(int b)
  {
    if ((float)(a % 100) / 3 == (int)((a % 100) / 3) )
      a = a + b;
    else
      a = a - b;
  }

  public int getA()
  {
    return a;
  }
}

Я специально придумал некое сложное условие, в зависимости от которого меняется поведение в методе "add". На практике могут быть множество флагов и других свойств объекта, которые влияют на поведение объекта, делая его настолько различным, что уместить это в голове уже становится сложно. Класс ориентируется на некоторые свойства, которые сам же и изменяет. Такие непредсказуемые классы неизбежно ведут к ошибкам.

Вот другой пример на языке AS3:

class D
{
  var param1: boolean;
  var param2: boolean;

  function func1(...)
  {
    .........
      if (param2)
        param1 = abc;
      else
        param1 = xyz;
    .........
  }

  function func2(...)
  {
    .........
    if (param1 && asd)
      param2 = ...;
    ...........
  }
}

Тут парочка булевых свойств, которые зависят друг от друга и влияют на поведение. Уже непросто объяснить что там происходит.

Вот такое наблюдение. Что с этим делать пока не знаю. Пойду ещё почитаю Фаулера.

Вот подумалось, так что мысли сырые. А что если изобрести такой стиль программирования, где все объекты жили бы в реальном времени и обменивались сообщениями? Представьте себе стратежку типа Старкрафта. В ней юниты и здания - это программные объекты, которые друг с другом взаимодействуют и в итоге чего там строют. Так вот, если программные объекты представить в виде таких же юнитов, то для них можно будет писать функции жизни, а не реакции на события, как в традиционном ООП. Т.е. представлять себе процесс не виде алгоритма, а в виде взаимодействий объектов, как в реальной жизни.

В традиционном ООП есть корневой объект, который создает другие. Те в свою очередь создают ещё более другие и т.д. В предлагаемом подходе нет никаких внешних контролирующих алгоритмов. Это должна делать виртуальная машина, которая ведёт себя аналогично какой-нибудь стратежке, но с более широкими возможностями программирования юинтов-объектов.

Было бы интересно. Просто для фана, поиграться. А потом, глядишь, и выйдет чего.

UPDATE: всё это называется многоагентными системами. Программировать в них можно вот так например.

То что сейчас будет написано возможно противоречит каким-нибудь принципам "правильного" проектирования ПО, так что будьте осторожны ))

Предлагаемый подход родился в моей голове чтобы упростить доступ к объектам классов вида "синглетон". Кто не в курсе, знайте, что это классы с объектами в единственном экземпляре и временем жизни равным (или примерно равным) времени работы программы. Классический подход предлагает передавать их по цепочкам в виде параметров и хранить в объектах-клиентах посредством агрегации (в виде ссылок). Такой подход похож на прокладывание сетевых проводов, где устройства взаимодействуют лишь с соседями, прямо или косвенно соединёнными проводами. Прокладывать провода или же обеспечивать каждый раз передачу синглетона по иерархии геморно. Поэтому предлагается устроить нечто похожее на wifi-сети в проектируемой объектно-ориентированной системе. Сделать синглетоны доступными всем, посредством статической переменной (метода) - почему бы и нет?

Преимущества заключаются в том, что получить доступ к такому синглетону можно из любого другого класса без всяких параметров. Недостаток заключается в отсутствии контроля за состоянием синглетона, т.к. теперь кто угодно в любой момент времени может его изменить. Чтобы исправить этот недостаток, можно разрешить доступ к синглетону только тем классам, для кого он предназначен. Как же это сделать? В разных языках могут быть свои средства, но всегда можно явно прописать в синглетоне названия конкретных классов, а потом проверять их в методе получения синглетона. Можно также извратиться и сделать что-то вроде системы паролей в своей программе, если других языковых средств нет.

Выгода от этого подхода огромна! Нет гемору с параметрами и ссылками!
Подробности описал в этой статье.