J
jehugaleahsa
Hello:
I used to hate interfaces because I didn't know how to use them. I
used to think that interfaces were only a way to specify that a set of
classes further down the line would implement a method. Usually I
would just end up making an abstract class and forego having to
rewrite the same code over and over again. At most, I was using
interfaces for some form of Compositition.
I have learned now that that is one of the least useful uses of
interfaces. A far more useful use is to hide details from other layers
of code. For instance, your class may have a lot of public methods,
thanks to other interfaces, but you just want a particular section of
code to see your interface members. Well, in whatever method you have
returning your class, just return an interface. Now you code has less
coupling since one piece of code isn't messing with methods you wish
to hide.
Apparently this is a very, very common use of interfaces. It is an
easy way to treat the same class as multiple classes. Talk about
multiple personalities!
Now here is my dilemma. I wil some times want to give another layer an
instance of my interface instead of my entire class (I know it is the
same thing underneathe). However, later on down the line, I want them
to pass back to me their modified instance. The question is, is there
a way to get away from casting the interface to the full class in
order to store it with other similar classes?
In my scenario, I have an interface for composing my classes in a tree-
like structure. The classes work together to build an SQL query. I
have other interfaces for returning the properties of the tree
classes. For instance, a column might allow the user to change its
name. My interfaces that return properties *must not* have any details
about how the class is being stored in the composite structure. I have
a weak guarantee that a class that implements the one interface will
implement the other. I say "weak" because it is my responsibility to
remember to give every class both.
Right now I have just centralized where I cast from one interface to
the other. I am not a big fan of casting though. Is there a better way
to allow an object to be passed in and out of methods without needing
to cast into another interface when it returns?
One idea I had was to store the object first and then return the
interface. However, I am not guaranteed where the object will end up
in the structure (it is up to the user of my class). I could write
"AddAndReturnColumn()", etc methods to all my structures, but that
seems like a lot of effort.
Any brilliant ideas?
I used to hate interfaces because I didn't know how to use them. I
used to think that interfaces were only a way to specify that a set of
classes further down the line would implement a method. Usually I
would just end up making an abstract class and forego having to
rewrite the same code over and over again. At most, I was using
interfaces for some form of Compositition.
I have learned now that that is one of the least useful uses of
interfaces. A far more useful use is to hide details from other layers
of code. For instance, your class may have a lot of public methods,
thanks to other interfaces, but you just want a particular section of
code to see your interface members. Well, in whatever method you have
returning your class, just return an interface. Now you code has less
coupling since one piece of code isn't messing with methods you wish
to hide.
Apparently this is a very, very common use of interfaces. It is an
easy way to treat the same class as multiple classes. Talk about
multiple personalities!
Now here is my dilemma. I wil some times want to give another layer an
instance of my interface instead of my entire class (I know it is the
same thing underneathe). However, later on down the line, I want them
to pass back to me their modified instance. The question is, is there
a way to get away from casting the interface to the full class in
order to store it with other similar classes?
In my scenario, I have an interface for composing my classes in a tree-
like structure. The classes work together to build an SQL query. I
have other interfaces for returning the properties of the tree
classes. For instance, a column might allow the user to change its
name. My interfaces that return properties *must not* have any details
about how the class is being stored in the composite structure. I have
a weak guarantee that a class that implements the one interface will
implement the other. I say "weak" because it is my responsibility to
remember to give every class both.
Right now I have just centralized where I cast from one interface to
the other. I am not a big fan of casting though. Is there a better way
to allow an object to be passed in and out of methods without needing
to cast into another interface when it returns?
One idea I had was to store the object first and then return the
interface. However, I am not guaranteed where the object will end up
in the structure (it is up to the user of my class). I could write
"AddAndReturnColumn()", etc methods to all my structures, but that
seems like a lot of effort.
Any brilliant ideas?