Поиск шаблона разработки для замены huuuge, если на типе объекта

Похоже, что Вы могли бы использовать C#. Я полагаю, что можно создать "дополнительные методы", которые присоединяют к уже установленным классам.

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

Затем Ваш метод "DoSomething" мог просто поиск, в котором передал делегат approprate типом объекта, и выполниться.

Реальный пример был бы более полезным. Если Вы просто изменяете реализацию метода для семейства связанных классов затем, как @Steven A. Lowe говорит, Вы являетесь лучшими от использования полиморфизма и использования отношений подкласса для этого. Если классы не участвуют в, "" отношения, то другие шаблоны как Посетитель могут быть более соответствующими.

Полиморфизм является ответом, куда базовый объект передается в. Однако это - значительно больше шаблона и семантической сложности, чем, возможно, Вы хотите.

Это потребует, чтобы Ваша функциональность шунтировалась так или иначе в производные классы и "виртуальную" функцию, которая будет реализована.

Я думаю, что это - больше вопроса для подхода Аспектно-ориентированного программирования.

Я хотел бы, чтобы Ваш метод DoSomething взял интерфейс ICanHaveSomethingDone в качестве своего параметра. Затем я определил бы интерфейс ICanHaveSomethinhgDone и получил бы из него подклассы (один для каждого объекта, который Вы хотели бы к DoSomething к), которые реализуют DoSomethingToMe, по-другому для каждого класса с реализацией. Каждый из них просто берет конструктора типа, к которому Вы хотите сделать что-то, так, чтобы, когда Вы идете для вызова DoSomething, Вы на самом деле вызвали Factory (очень простой, просто создав экземпляр Вашего класса ICanHaveSomethingDone от входного типа для создания экземпляра класса, который реализует метод DoSomethingToMe, и который имеет надлежащий код для основного объекта.

По существу думайте о нем этот путь; Вы определяете интерфейсный контракт, который Вы хотите, чтобы объекты параметра реализовали; и определение "художественного оформления" в форме подклассов Вашего объекта и Интерфейса, которые реализуют определенные реализации интерфейсного поведения (поэтому выполняющий контракт) для Вашего определенного класса. Этим способом можно сделать реализацию метода DoSomething для каждого класса абсолютно отдельной от источника тех классов.

Еще одна вещь это делает; это означает, что можно добавить новые типы во времени выполнения, если Вы превращаете свою фабрику в контейнер DI; путем введения в контейнер фабрики новых типов, к которым требуется смочь сделать что-то, пока у Вас есть реализация действия, требуется взять определенный как класс, полученный из интерфейса и из того класса, Вы хороши. Можно даже определить поведение во времени выполнения, не реализовывая производный класс при реализации полного подхода AOP; определение интерфейса, определение поведений на действиях и параметризация реализации производных классов для создания вместе во времени выполнения поведений, которые Вы хотите с объектом, в котором Вы являетесь передающими. Но это усложнило... :-)

Spring AOP является большим об этом материале, между прочим. Я читал на нем.

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