Announcement

Collapse
No announcement yet.

3 means to the same ends... opinions?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Knuth Konrad
    replied
    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.

    Leave a comment:


  • Michael Mattias
    replied
    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

    Leave a comment:


  • Bern Ertl
    started a topic 3 means to the same ends... opinions?

    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).
Working...
X