3 means to the same ends... opinions?

[Bern Ertl]

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

[Michael Mattias]

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

[Knuth Konrad]

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