Best Practice - BlitzCoder.net

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|126\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> C/C++/C#/Other -> Best Practice
Sun, 19 Apr 2009, 21:41
Scherererer	*Disclaimer: This is in the C section, but is open to best practice advice in any Object Oriented Language I have a class that works as an intermediary between two other classes, passing a value from one into the other. ClassA =pull> TransitionClass =push> ClassB pushing information from the TransitionClass to ClassB is not a problem and has already been implemented. However, the class needs to pull from ClassA, which could be one of many different classes (not on the same inheritance tree), and additionally (most importantly), could be attached to one of many different properties/fields of ClassA. If I only needed one field from each, I would have created an interface that all ClassA would have implemented, however that is not the case. So, what I have thought of doing, is using a pointer in the TransitionClass to point to the desired field as an object, since all I need is the ToString method. I think we can all agree that pointers = bad as far as OOP goes, as it is unsafe code, but I want to know all of your thoughts/suggestions maybe as to a different thing to do to solve this problem. as a note: I do not want ClassA to 'push' to the TransitionClass, nor do I want to give it any awareness thereof. -=-=- YouTube Twitter Computer Science Series: Logic (pt1) (part 2) (part 3) 2's Complement Mathematics: Basic Differential Calculus
Sun, 19 Apr 2009, 21:44
Scherererer	Another method I just thought of would be having a TransitionClassBinder, which would map values of a specified class to TransitionClass's, pushing it from ClassA to the TransitionClass, but then i would need to extend the TransitionClassBuilder for every type of "ClassA" that I encounter. ClassA =pull> TransitionClassBinder =push> TransitionClass =push> ClassB -=-=- YouTube Twitter Computer Science Series: Logic (pt1) (part 2) (part 3) 2's Complement Mathematics: Basic Differential Calculus
Sun, 19 Apr 2009, 23:17
JL235	Four variations on the idea of visiting class A and having it offer the value to you. Essentially instead of pulling the value from A, you instead visit it and A gives it to you. This moves the responsibility of handling the type and value information from the Transition class to A. The first is that the Transition class visits A in order to be given the value. Something along the lines of: public class Transition { // contents ommitted, these are standard accessor/mutators public void setValue(Object value); public Object getValue(); public void pass(A a, B b) { a.visit(this); b.passValue(getValue()); } } public interface Visitor { public abstract void visit(Transition t); } public class A implements Visitor { public void visit(Transition t) { t.setValue(getSomeValue()); } } --v I did something similar to this at work recently to connect together data display with data sources. You could also have it so it passes B into A directly connecting them, thus allowing A to pass the value itself in any way it feels to B. The Transition class then becomes just a middle man connecting them together, but doesn't actually do the passing. i.e. interface Receiver { public abstract void visit(B b); } class A1 implements Receiver { public void visit(B b) { /* set value to b / } } class A2 implements Receiver { public void visit(B b) { / set value to b / } } class A3 implements Receiver { public void visit(B b) { / set value to b / } } class Transition { void pass(Receiver a, B b) { a.visit(b); } } --v The binder idea is very similar, and so you could use that instead. I'd imagine it as something like: interface TransitionBinder { abstract void bind(Transition t); } class A { TransitionBinder getBinder(); } class Transition { void pass(A a, B b) { a.getBinder().bind(this); b.setValue(getValue()); } } --v Finally you could go further and use the full visitor pattern. The Transition class has an implemented method for each type that A might be. The Transition class visits A itself who then calls the correct method. This allows the Transition class to remain as the one who passes the information. i.e.interface Receiver { public abstract void visit(Transition t); } class A1 implements Receiver { public void visit(Transition t) { t.accept(this); } } class A2 implements Receiver { public void visit(Transition t) { t.accept(this); } } class A3 implements Receiver { public void visit(Transition t) { t.accept(this); } } class Transition { private B b; public void pass(Visitor a, B b) { this.b = b; a.visit(this); } public void accept(A1 a) { // A1 specific code here } public void accept(A2 a) { // A2 specific code here } public void accept(A3 a) { // A3 specific code here } } --v In this example the Transition class is the visitor. The A1, A2 and A3 accept methods can also be trivially pushed up into a Visitor interface which would allow multiple Transition sub-classes. The visitor pattern allows you to work around type ambiguity in order to access the object under it's specific type. The object a was given as an implementation of a very brief interface, but using it we can access the object a under it's specific type whilst still being 100% type safe* (i.e. I used no type casts to do it). The Visitor pattern is used a lot in parsers where each Visitor implements the different kinds of parsing sweeps (i.e. type check, optimizer, code generator, etc). It can also be used to abstract an algorithm away from the objects that would normally run the algorithm (so that it is now simpler to have multiple implementations of an algorithm). An extra 5th way would be to just cast an A sub-class the class you want. However to reduce how the lack of type safety I'd componatise this. i.e: public class Transition { private static final Map<Class<?>, Binder> BINDERS = new HashMap<Class<?>, Binder>(); static { BINDERS.put(A1.class, new BinderA1()); BINDERS.put(A2.class, new BinderA2()); BINDERS.put(A3.class, new BinderA3()); } public void pass(Object a, B b) { Binder binder = BINDERS.get(a.getClass()); if (binder == null) { throw RuntimeException(); } binder.pass(a, b); } } interface Binder { abstract void pass(Object a, B b); } class BinderA1 implements Binder { void pass(Object a, B b) { A1 a1 = (A1) a; // pass code here } } class BinderA2 implements Binder { void pass(Object a, B b) { A2 a2 = (A2) a; // pass code here } } class BinderA3 implements Binder { void pass(Object a, B b) { A3 a3 = (A3) a; // pass code here } } --v Binders for various classes can trivially be added and removed. The advantage this has over doing the cast in the Transition class is that the casting is now pushed out into it's own classes (maybe even it's own package) away from the rest of the code.
Sun, 19 Apr 2009, 23:56
Scherererer	part of the problem was that I needed to map possibly multiple values from a single object to multiple other fields, in a one-to-one translation. I ended up going with a type of binder implementation, which is requireing me to extend a base class several times, but the way I've built it I think suits the situation better. The data in ClassA is coming from an XML tree, and so the transition intermediary is now being stored in a tree-like fashion, and I was able to extend the TransitionBinder class from the Transition class in such a way that it is very easy to map multiple values and types of values to each other. I'll upload a class diagram: The XMLDataConsumer holds the root node of the type ValueBindingTreeNode, which is actually a GameValueBindingTreeNode usually, and then it contains Team nodes, player nodes (tba), and each one of those has other children which are of the more generic ValueBindingTreeNode type, because a team has a name, short name, score, etc., and an individual player can have a number, name, score, and depending on the sport even more specific information; all of these mapping to discrete fields in a separate set of classes. essentially, this "transition" class set is here to connect the "game" classes, which derive their info from xml, to the gui & exported files which require custom mapping of fields. -=-=- YouTube Twitter Computer Science Series: Logic (pt1) (part 2) (part 3) 2's Complement Mathematics: Basic Differential Calculus
Mon, 20 Apr 2009, 00:46
JL235	My first and third code suggestions don't allow passing a variable number of values from class A to B, but I don't see how the others (maybe requiring a little tweeking) don't allow this.
Mon, 20 Apr 2009, 07:22
Evil Roy Ferguso	You can do something like this in C++ -- I don't know if there's a Java-equivalent, though. (Change structs to classes if you want, I'm just too lazy to type public when we don't have private fields.) /* * Policy to get "My favorite field" from an arbitrary type. / template <typename T, typename U> struct MyFavoriteField { static U& get(T& v) { return v.myFavoriteField; } }; / * Transition class. */ template <typename TA, typename TB, typename FieldPolicy> struct Transition { // Applies the transition. void operator()(TA& a, TB& b) { b.whatever(FieldPolicy::get(a)); } }; // here's our transition object Transition< ClassA, ClassB, MyFavoriteField<ClassA, int> > myTransition; ClassA a; ClassB b; myTransition(a, b); --v This could be made more concise with template template parameters, but I'm hesitant to post any code involving those unless I have a compiler ready to test it with. Create new policies as necessary to access different/multiple fields from A (or any other type that has those fields, for that matter.)