4 ms·
This brings up a burning question that I have been pondering for a while. I still don't get how to properly design good APIs. I have been programming but as a s
by east2west 14y ago
This brings up a burning question that I have been pondering for a while. I still don't get how to properly design good APIs. I have been programming but as a scientific research not as a professional developer, and I have found I cannot remember how to use my code a day after writing that code.
Take my current project as an example. I have some samples, each of which are observations along a sequence of non-overlapping segments. My objective is to extract observations over arbitrary intervals for all samples. So I have a segment defined as a pair of start and end position plus its observation, a sample as a vector of segments, and all samples as a dictionary of samples. There are various utility functions to make segments, collect samples, and scan individual samples. The problem is I have to remember all three levels of data structures to use this code. I wonder whether it is better to define an interface for those data structures as well so I just need to remember the interface. My objections to formal definition of interfaces is that everything is so simple and obvious and formal interfaces smack of overengineering.
I got to this point because in my previous projects I put every identifiable thing as a class and found too much coupling in classes and convoluted interfaces.
- joedoe55555 14y agoHi, I used to have a similar problem: seeing that when I do architectures they become difficult to maintain. Or difficult to talk about, to be honest, I don't understand your second paragraph :) What really helped me is the approach to program API-driven. Don't start with your algorithms but start with what kind of functions you probably need and what would be the easiest way to use them. (In fact this is not so far from this data-centric approach as the most basic functions of APIs are usually function to retrieve or modify data.) Try to read some good code from one of your favorite open-source projects. At some point some code may catch your attention because it's so simple and elegant. Why is it so elegant? Often because the underlying structures are just simple and made from common-sense. Don't over-engineer stuff, the simpler solution is often superior to the full-featured solution. And often you should ask yourself: do I really need this features currently to show some progresS? Shouldn't I not rather post-pone it?
- east2west 14y agoAll good advice. Right now I only write out major tasks and outlines of procedures to achieve them. Maybe I first should abstract out core data structures and operations on them. I will try that.
- sedachv 14y agoHow do you name things? From your text ("I have a segment defined as a pair of start and end position plus its observation, a sample as a vector of segments, and all samples as a dictionary of samples") it seems you have a lot of different names for different things. Decide what names are important and which ones aren't (the "vector" and "dictionary" probably aren't). Eric Evans wrote a big book called Domain-Driven Design about these things, but his advice basically boils down to this.
- east2west 14y agoI won't have time to read big books in foreseeable future, especially if they are not related to my core research areas. But I will try this and see what I can get out of it.