2012-01-13 1 views
3

Я работаю над улучшением моей стратегии работы с классами и объектами.Стратегия программирования - как передать объекты в цепочку классов

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

пример: работа с объектом ZedGraph (примечание), это может быть не лучший пример, но он получит эту идею.

class Graphhandler 
{ 
    private ZedGraphControl ZGC; 
    private SubGraphController PortionofGraph; 

    public class GraphHandler(ZedGraphControl _ZGC) 
    { 
     ZGC = _ZGC; 
     initializeGraph(); 
    } 

    private void initializeGraph() 
    { 
     // notice I am putting the ZGC Object into another class 
     // and likely that ZGC object will go into another class 
     PortionofGraph = new SubGraphController(ZGC); 
    }   
}  

class SubGraphController 
{ 
    private ZedGraphControl ZGC; 
    private DeeperSubGraphController PortionofGraph; 

    public class SubGraphController(ZedGraphControl _ZGC) 
    { 
     ZGC = _ZGC; 
     initializeSubGraph(); 
    } 

    private void initializeSubGraph() 
    { 
     PortionofGraph = new DeeperSubGraphController(ZGC); 
     // is there a better way? 
    } 

} 

Есть ли лучший способ передать объект уровня yop через все эти вызовы, чтобы манипулировать данными?

ответ

3

Как правило, ответ заключается в передаче полностью сформированных зависимостей в ваши объекты. Например:

public GraphHandler(SubGraphController portionOfGraph) { 
    this.portionOfGraph = portionOfGraph; 
} 

public SubGraphController(DeeperSubGraphController portionOfGraph) { 
    this.portionOfGraph = portionOfGraph; 
} 


... 

var zedGraphControl = new ZedGraphControl(); 
var deeperSubGraphController = new DeeperSubGraphController(zedGraphControl); 
var subGraphController = new SubGraphController(deeperSubGraphController); 
var graphHandler = new GraphHandler(subGraphController); 

Вместо построения DeeperSubGraphController непосредственно в вас подграф контроллер. В настоящее время вы обычно организуете все это, используя инфраструктуру инъекций зависимостей.

(Смотри также: Dependency Injection Myth: Reference Passing)

+0

Да, я согласен с этим, но подход, который я дал, был бы лучше для упрощения работы над суб-частями. скажем, у вас есть 2 возможных результата графика, которые требуют много работы в коде для подпорций графа, хотите ли вы затем передать ZGC в цепочку просто на код? – Ashitakalax

+0

@ user970011, не могли бы вы привести пример? –

+0

Скажите, что у вас есть объект Graph, и с данными, которые вы указали. вы можете сделать граф графиком или гистограммой. каждый график имеет большой объем кода, чтобы настроить график так, как вам хотелось бы. Таким образом, вы создаете классы для обработки линейного графика и работы гистограммы. Чтобы все еще работать над этими объектами, вам все равно нужен доступ к этому основному объекту графа. – Ashitakalax

0

Вы можете попробовать использовать наследование в этом сценарии.

+0

поправьте меня, если я ошибаюсь, что я очень хорошо мог бы, но не то, что работа будет только на более высокие уровни классов? Я в основном интересуюсь более низким? – Ashitakalax

+0

Это больше похоже на обратный подход к проблеме, используя наследование. –

1

Вы можете взглянуть на Inversion Of Control (часто аббревиатура IoC).
Это в основном супер объект, который позволяет вам обращаться к другим объектам всякий раз, когда и где вам нужно.

0

Как различные контроллеры будут управлять графиком. Как правило, объекты передаются так, как вы это делали, - как аргументы метода. Если объект требует/использует другой объект (поскольку контролеры управляют графиками в вашем случае) по разным методам, они объявляются членами этого ссылочного объекта, как вы это делали. Если они необходимы для одного метода, они передаются конкретному методу объекта в качестве параметров.

Если существует более сложная схема управления графиками в определенном порядке, вы можете взглянуть на шаблон chain of responsibility.

Смежные вопросы