The author of the Tekla Open API ought to be hung, drawn and quartered. Here are some gripes I have with the API:

Example 1: Use Enumerations where required

Take a look at this:

We are required to type in a string. Why? This should be an enumeration. We could have Visual Studio helping us out with the auto-prompt. Moreover why are we passing in a value type by reference? Why isn’t the method simply returning the value type itself? I don’t like it.

Example 2: Why use an IEnumerator?

Take a look at this:

Why on earth are they giving me an enumerator? Why? What good reason is there?

Example 3: Revision Numbers?

I wanted to programmatically update some revision numbers for some drawings the other day. So I looked in the API. Quelle surprise: the property was not exposed. See here for the miniscule list of the exposed Drawing properties:

Example 4: Liskov-Substitution Violations

Suppose your friend asks you to bring a plate to a soiree you all are attending. Given the contract and the generality of it, you deem it appropriate to bring along a delicious Shepherd’s pie. Can you imagine the surprise you’d have if you found out that Pies were not allowed? If your friend says ‘bring a plate’ without reservation, are you not entitled to beleive that any dish will do? If there are secret rules as to what you can and can’t bring, despite the generality of the instruction, then you have what is called a Liskov-substitution violation.

See below. I wanted to pass in a GridLine reference - and I am entitled to pass in that object because a gridline IS A drawing object. But I can’t do it. There is a Liskov substitution violation. And that too we are passing in by reference, not by value. I can’t see a good reason why this is the case. Makes things messy.

Example 5: Common methods/functions missing

Suppose you want to get the vector of a particular gridline. Ordinarily you should be able to call such a common function directly. But with the Tekla API you have to go through considerable rigormorale just to get that vector. Look at this monstrosity:

Example 6: Ability to Pick Multiple Objects - Missing

• What if you wanted to pick multiple objects in a drawing? Can’t do it. The picker only exposes the ability to pick one object. Just one. Can you believe that?

Example 7: World Class Documentation

Take the InputItem.GetData method. It returns the data of the input item. Nice to know. What does it to? It returns a System.Object type. Again, brilliant. Much needed information for the developer.

Example 8: Look at this Beauty that I found: AlongLineOrWithLeaderLineAndParentObjectAlongPartPlacingType

Not sure what is going on with the naming of this type, but I found it hard to understand, even with the explanation (credit to the team for providing the documentation in the first place though). Were they smoking crack cocaine when the wrote this? Publicly exposed APIs are meant to be simple and easy to understand. The second you are using the words ‘or’ or the words ‘and’ then there is a problem there is something wrong with your design. Or to use the programming parlence: “you’ve most likely got the wrong abstraction”.

The Biggest Gripe of all…

…is the API doesn’t expose anything at all. There’s a lot of good stuff hidden away. I don’t like griping, but that’s enough for today.

We’ll look at some Tekla code in the next post.