It seems a factory method
dfa
2009-06-18 14:32:56
Thank you after reading the article again i think you are right. My opinion is based on this part(http://en.wikipedia.org/wiki/Factory_method_pattern):public class ImageReaderFactory { public static ImageReader getImageReader(InputStream is) { int imageType = figureOutImageType(is); switch(imageType) { case ImageReaderFactory.GIF: return new GifReader(is); case ImageReaderFactory.JPEG: return new JpegReader(is); // etc. } }}
Richard
2009-06-18 14:58:50
+1
A:
This is the Factory pattern from the book "Design Patterns: Elements of Reusable Object-Oriented Software" by Gamma, Helm, Johnson and Vlissides.
Mark Lutton
2009-06-18 14:36:23
+1
A:
The BaseClass and SubClasses seem to me like having something as (pseudocode)
interface IDataProvider{
GetData();
}
class SubClass1 implements IDataProvider{
GetData(){
...
}
}
The instantiation strategies you use seem to work like a Factory. What you could do is to lay out rendering in some HTMLRenderingEngine or whatever (I'm not familiar with ABAP/BSP), just to have the presentation decoupled from the rest of the logic.
Juri
2009-06-18 14:37:12
Thank you for your tipp. Sadly i cant use the MVC approach because of some requirements. But i have implemented some html render methods to seperate the data retrieving and html building.
Richard
2009-06-18 15:03:33
MVC would be better, but you can also just create a separate class HTMLRenderer (call it as you want). This inherits from an interface called IHTMLRenderer which provides a method GetRenderedHTML(). In this way your base class contains just a dependency to the interface and you may still change your renderer or even attach different renderers. You understand my idea? This makes it more maintainable than having just a separate method in the same class.
Juri
2009-06-18 15:16:37
A:
Inheritance is fun, but should be used as a last resort. I'm not saying you can't do it the way you did--your solution is totally valid, but just to suggest an alternative...
What if you had "DataClass" in which you could set a processData object (or not). The processData object would actually be an interface with a single method "processData".
When you call getData, it might look something like this:
if(processDataObject == null)
return getInformation();
else
return processDataObject.processData(getInformation());
Heck, if you have a "passthrough" processData object defined that does nothing and use that as the default "processDataObject", then the entire getData method becomes:
return processDataObject.processData(getInformation());
This would allow dynamic creation of classes to do any type of processing you want--It will simplify things that you build on top of this design.
This style of design took me a while to come to terms with, and you may not like the idea of avoiding inheritance at first, I'm just asking you think about it. My use of inheritance is pretty rare these days, and when I use it, it's always in very shallow trees.
Bill K
2009-06-18 15:53:01
Mhh you mean i would have multiple processData Classes which implement the interface and have custome coding. And there is the DataClass which implements a Process Data Objekt, which i can dynamically inctantiate pretty much the same way as now?
Richard
2009-06-18 17:53:58