No announcement yet.

3 means to the same ends... opinions?

  • Filter
  • Time
  • Show
Clear All
new posts

  • 3 means to the same ends... opinions?

    Hi folks.

    I spent the day examining the way three separate commercial applications (that perform similar functions) expose a COM interface. I saw three completely different approaches:
    • OOP structure - A complete heirchy of collections and objects representing the database (and limited methods/properties for the application itself)
    • GUI encapsulation + OOP - methods/properties to fully automate/control the application (ie. just about every menu option) with a heirchy of collections/objects representing the database
    • Flat access/interface - a single interface containing methods to retrieve/alter any field in the database using named fields (on the active record). No OOP structure at all, limited options to automate/control the application.

    I'm trying to decide on an approach for my next application. I was wondering what thoughts you may have on these approaches - either from an implementation perspective or from a 3rd party perspective (ie. one who might be wanting to automate one of these applications).
    Bernard Ertl
    InterPlan Systems

  • #2
    Depends on the user.

    If you are creating a tool for others to use, then the market drives your feature set (interface options). Pick whatever works for your customers.

    If you are creating an end-user application, nobody will care "how" they will only care "that it works." In this case, pick whatever works for YOU.

    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]


    • #3
      I personally don't care much about which method is used, but more if it's stringent/logical implemented, i.e. similar functions/methods have similar names and if the documentation that comes with the interface is good.

      "Good" naming (similar functions have similar names, you know one, you know them all):
      - CustomerGetByName, CustomerGetInvoiceByIDCustomer
      - SupplierGetByName, SupplierGetInvoiceByIDSupplier

      - or -

      - GetCustomerByName, GetCustomerInvoiceByIDCustomer
      - GetSupplierByName, GetSupplierInvoiceByIDSupplier

      Although I prefer the former over the later, as long as a scheme is consequently implemented throughout an interface, it's all fine.

      "Bad" naming (similar functions differ great in name, you need to look up the functions more often in the docs)
      - CustomerGetByName, CustomerGetInvoiceByIDCustomer
      - GetSupplierFromName, SupplierInvoiceFromID
      Last edited by Knuth Konrad; 20 Nov 2008, 07:55 AM.