Hello all im not sure if the topic is right but what im trying to do is goes like this : i have Custom Data Structure this custom data structure have basic methods and have no logic some thing like this :
now say i like to add some logic and some methods to this data structure
BUT ( and here is my problem ) i like to make this addition plug ( i have no other way to describe it )
that is add some kind of class that will extend this class and will add me more possibilities to my data Structures
here im extending the MyStructMethod_1 with MyStruct class but i know its not the right way do to it i just dont know
how to do it , so i have this:
and from my Main code i could
refer to my MyStruct like this ( again i know it will not work its only so show what i mean )
MyStruct ms = new MyStruct();
as you can see im referring to my MyStruct with the methods i defined in the sub class
then i could make many plugble subclass that will extend my MyStruct .
From your description it is not entirely clear what you are trying to accomplish. Nonetheless, you may want an abstract class as the root. This assumes that the root class (MyStruct in this case) is never created directly, only subclasses are created. Another possibility is that the methods could be encapsulated in an interface, the implementation of which is left completely to the (sub)classes. An abstract class example:
Hello and thanks for the reply i will try to explain my self again ( English is not my native luggage also ...) my porpoise is to separate the methods and the logic from my main Data Structure i will like to have main class that is MyStruct , and every where from my code i will refers to this data structure as "MyStruct " not something else BUT here is my main problem .. i need to find away to add or substract methods from this class . not extend from it using inheritance . with additinal class's .
here is another scenario : say i have application that uses my Data Structure now this application can interact with different applications so if my application interact with application A1 every where in application A1 code they will use "MyStruct" Data Structure with methods that are relevant only to application A1 and these methods need to sit on some class that some how extends "MyStruct" this can be with application B1 , C1 and so on and every where it will be referred as "MyStruct" not something else as the class that extends it .
Whether you define an interface or a (abstract) class, how anything outside the object sees it is a function of the reference type to the object. That is if you have a class that implements an interface then the object may be referred to as the class or as the interface, in the first case all public methods will be visible, in the second case the methods defined in the interface will be visible. So you could have:
So external code may "know" MyClass as an instance of IntfOne, some may "know" it as an instance of IntfTwo and some may "know" is as an instance of MyClass. Having said all this, I'm still not sure it is what you are looking for. You may want to look at a Decorator or a dynamic proxy design pattern but these are more complex and my suspicion is that the problem may be solved without those.
I had a situation where I was receiving structs like yours as parameters. They had no behavior methods at all, only getters and setters. They were generated from a model and we could not modify them.
So we put the behavior in separate objects. This is not the best OO but it can work. So my code wound up something like
StructPlusBehavior could extend Struct if you like. That would let you pass StructPlusBehavior to methods that expect Struct. It would override all the getters and setters to pass through to its private instance of Struct which it got in the constructor.
You have lots of options. For example, it's not necessary to extend Struct. You could make an AllBehavior object that doesn't even hold a Struct. And in my case I could receive any number of subclasses of Struct so I had to create the right StructPlusBehavior object to match the parameter.
Does that sound useful? [ November 15, 2006: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi