looking for a design pattern
-
I'm lookin for a design-pattern that match what I need: I have class A which should hold a collection of class B or its inehrited classes. class B should be able to run functions and access properties on A and A should be able to run functions and access properties on B. I've been suggested to pass reference of As properties to B opon construction, but I'm lookin for the design-pattern... anyone know of any design-pattern similar to this? Thanks alot :) NaNg.
-
I'm lookin for a design-pattern that match what I need: I have class A which should hold a collection of class B or its inehrited classes. class B should be able to run functions and access properties on A and A should be able to run functions and access properties on B. I've been suggested to pass reference of As properties to B opon construction, but I'm lookin for the design-pattern... anyone know of any design-pattern similar to this? Thanks alot :) NaNg.
That is the pattern, pass A to B in its constructor. Or make B an inner class of A so only A can create it and without A its creation will be impossible. Here is a snippet: A a = new A(); B b = a.CreateB(); public class A { ... public void CreateB() { A a = new A(this); return a; } ... public class B // Or other access depending on your needs { B(A a) { this.a = a; } } }
CodingYoshi Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07
-
That is the pattern, pass A to B in its constructor. Or make B an inner class of A so only A can create it and without A its creation will be impossible. Here is a snippet: A a = new A(); B b = a.CreateB(); public class A { ... public void CreateB() { A a = new A(this); return a; } ... public class B // Or other access depending on your needs { B(A a) { this.a = a; } } }
CodingYoshi Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07
-
the thing is - i was strongly advised not to hold the A class instance in Bs instance, someone told me it's bad design. What do you think? is it that bad of a design, could there be better? or this is the best option there is?
I don't think it is a bad design. Like I said in assemblies this will cause problems as Assembly A will depend on B to compile and B will depend on A to compile. This is a deadlock situation. With classes, I don't see the problem. You should try to minimize coupling but you can not avoid it altogether. .NET and Java API both have instances of classes within other classes. For example, DataSet.Tables, Table.Rows etc. People waste way too much time on design and design patterns. Patterns are suppose to make the construction easier and not introduce complications. The best design is the simplest design.
CodingYoshi Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07
-
I'm lookin for a design-pattern that match what I need: I have class A which should hold a collection of class B or its inehrited classes. class B should be able to run functions and access properties on A and A should be able to run functions and access properties on B. I've been suggested to pass reference of As properties to B opon construction, but I'm lookin for the design-pattern... anyone know of any design-pattern similar to this? Thanks alot :) NaNg.
I would say you are looking for the Composite pattern: http://en.wikipedia.org/wiki/Composite_pattern[^]. With this pattern the quick solution is to make class A the composite and class B an component. A more beautiful solution is to create an abstract Component class that just contains the functionality related to administering the tree data structure. You then create 2 implementations of this abstract class: - class B that just re-uses the methods of the abstract class and adds its own functionality, - class A that just re-uses the methods of the abstract class, but adds collection functionality and its own functionality. A very beautiful solution is to separate specification from implementation: - specify B's own functionality in an interface IB, - specify A's own functionality in an interface IA, - make an abstract class Component that contains child logic, - make an abstract class Composite that contains collection logic, - make a class B that inherits class Component and implements IB, - make a class A that inherits class Composite and implements IA. In the implementation of class B, you can now check, if the parent is of type IA, and then use the functionality of IA. In the implementation of class A, you can now check, if a child is of type IB, and then use the functionality of IB. You can even make interfaces for the Component and the Composite, if you go 100%. Hope above was a little helpful. Remember, you decide your design! Regards, Keld Ølykke