How would you OO this? - Forum - OpenEdge Development - Progress Community
 Forum

How would you OO this?

This question is not answered

Hi,

Having a super class

fi.cls (financial instituion)

subclassed by

bank1.cls
bank2.cls

...

would you do dynamic-new() or do this (could be lengthy depends on how many banks)?

def var bk as class fi.
case bank:
  when "bank1" then
     bk = new bank1().
  when "bank2" then
     bk = new bank2().
...
end case.


bank1, bank2... may have different methods/properties. would you dynamic-invoke()?


or how would you do it differently?

TIA!

All Replies
  • A CASE statement is one way of doing it.  I’ve also seen code that builds a string from “bank1” + some package (“app.banking.”) and then does a dynamic-new. You could also keep a JSON file or other config with with a mapping from a logical name to a class (type) name.
     
    { “app.banking.interfaces.bank”: {
                    “bank1”: “app.banking.bank1”,
                    “bank2”: “extensions.bank2”,
                    “bank3”: “app.banking.bank3”
      }
    }
     
    If you do follow such an approach I STRONGLY recommend using interfaces pervasively in your code; it’ll make the calling code much cleaner.  There are some approaches outlined in this presentation I did a couple of years ago:  http://pugchallenge.org/downloads2015/417_Composing_Complex_Applications.pdf  .
     
    In addition to that, you can look at a Service Manager component (see a spec at github.com/.../v1_0 ); this turns all of the above into its own component.
     
    hth
  • Thank you for the ideas!

  • why does each bank need its own separate class ???

  • He did say that the different banks had different methods or properties, but I have to confess to being suspicious myself.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Even without separate methods or properties, there is a very common feature he is probably using from the world of OO called "polymorphism".  That is where a given method signature can be overridden to behave in a slightly different way for each derived class.  IE. Each bank may have slightly different method implementations that extend upon common/reusable code that is inherited from base (super) classes.

    Peter's suggestion to use interfaces provides some additional advantages that are similar to polymorphism.  The introduction of interfaces would allow bank classes to share their common method signatures WITHOUT actually requiring them to share any implementation code (eg inherited from a common base class).  This provides a greater level of decoupling between clients that use IBank and the implementations of IBank.

  • All of which is true ... when *necessary*.  I am questioning whether it is genuinely useful for different banks.  Subclassing is an important tool, but shouldn't be over used.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • This line, bank1, bank2... may have different methods/properties. Do you mean to say that you will need to make calls to different methods and properties for each bank, or are you just stating that your bank classes have other methods and properties? If it is the former, I think using case statements will be cleaner.

  • If you are looking at a situation where:

    - bank1 has feature A & B

    - bank2 has feature A & C

    - bank3 has feature B & C

    - etc...

    or something similar you may want to have a look at the decoration pattern: .

    It's a bit hard to get you head around the first time, but it's quite powerful. In a lot of cases decoration is a lot better than (far fetched) inheritance.

  • bronco

    If you are looking at a situation where:

    - bank1 has feature A & B

    - bank2 has feature A & C

    - bank3 has feature B & C

    - etc...

    or something similar you may want to have a look at the decoration pattern:

    Decorator pattern - Wikipedia

    en.wikipedia.org
    In

    .

    It's a bit hard to get you head around the first time, but it's quite powerful. In a lot of cases decoration is a lot better than (far fetched) inheritance.

    This pattern unfortunately will not help him condense his code. I think he is trying to eliminate repetitively similar code.

  • Well, depending on what the OP wants exactly I would say that decorating your class with features is definitely helping reducing repetitive code. You isolate code (feature A, feature B etc) in separate classes and add them to whatever bank needs that particular feature.