Announcement

Collapse
No announcement yet.

3 means to the same ends... opinions?

Collapse
X
 
  • 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.

    MCM
    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #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, 08:55 AM.

      Comment

      Working...
      X