Цитата(Pita @ 18.3.2009, 01:11 ) | | -Mikle-, а можно ли узнать в чем подход неправильный?? |
Правил нет, но есть рекомендации. При создании архитектуры, необходимо стремиться к уменьшению зависимостей классов друг от друга. Особенно это касается нижестоящих в структуре классов. Исключение могут составлять так называемые nested (ближние) классы (типы). В твоем (я так понимаю тестовом) примере, класс cl находится на одном уровне с формой, а в структуре - ниже нее, так как форма создает этот класс. В таком случае, нормально то, что класс формы знает о существовании cl, но cl не должен быть привязан к форме прямой связью, иначе пропадает смысл его создания как отдельного класса. Ведь его нальзя будет использовать с другими формами. Если все же необходимо вынести код работающий с твоей конкретной формой (или неким классом) в отдельный класс, но этот код должен быть связан с кодом вышестоящего класса (такие задачи встречаются), то в таких случаях класс объявляют внутри вышестоящего класса с конструктором, принимающем ссылку на вышестоящий класс. Зачастую его использование ограничено извне и его делают private.
| Код | public class SomeClass { // nested type private class SomeClassHelper { public SomeClassHelper(SomeClass owner) { _owner = owner; }
SomeClass _owner;
public void Test() { _owner. ....... ; } }
public SomeClass() { myHelper = new SomeClassHelper(this); }
SomeClassHelper myHelper; }
|
При этом, все поля класса SomeClass (даже private) будут доступны внутри класса SomeClassHelper по ссылке _owner.
Однако, если класс будет работать с более общим базовым типом (Control, IList, .... ), то тогда есть резон сделать его самостоятельным, то есть вынести его наружу, так как его использование не зависит от конкретного его создателя. То есть он сможет работать и с формой, и с кнопкой, и с панелью.
Существует несклоько подходов по связыванию классов между собой. Конкретный подход выбирается исходя из конкретной задачи.
События хороши тогда, когда необходимо оповестить внешний класс, о тех или иных событиях происходящих внутри класса, не вдаваясь в подробности того, кто имеено, какой именно и как именно класс будет реагировать на них, и будет ли вобще таковой обработчик.
Интерфейсы это вообще универсальный механизм, позволяющий описать конкретные методы, события и свойства, без необходимости их конкретной реализации. Один класс, может наследовать любое кол-во интерфейсов.
Абстрактные классы тоже позволяют описать конкретный интерфейс без его реализации, но в отличие от интерфейсов, абстрактные классы могут содержать некую реализацию. Множественное наследование абстрактных классов (да и вообще классов) в .NET не допускается.
Поэтому я и сказал, что подход в корне не верный, так как это
Цитата(Pita @ 17.3.2009, 22:45 ) | public static void fun() { //Вот тут надо вызвать treeView1.Nodes.Add(newNode); }
|
напрямую пытается использовать treeView1 конкретной твоей Form1 (ключевое слово static в объевлении метода, я списываю на опечатку). Даже если ты передашь ссылку на форму, то все равно будет неверный подход, так как Form1 будет зависеть от cl и cl будет зависеть от Form1. То есть они не смогут существовать раздельно, а значит нет необходимости разделять их код по разным классам.
Может возникнуть задача, когда некоторые ф-ии должны быть доступны везде. Тогда объявляют статический класс и статические методы. Например:
| Код | public static ImageHelper { public static Stream GetStream(Image image) { MemoryStream ms = new MemoryStream(); image.Save(ms); ms.Seek(0, SeekOrigin.Begin); return ms; }
public static byte[] GetArray(Image image) { return ((MemoryStream)GetStream(image)).ToArray(); } }
|
|