Is it feasible that we have a layer of API simply for the reason so that people in the team don't have to understand the actual implementation of the individual components each of us are working on? I had this thought because I started to find that some times when working a project with a team of people (I am new to working in a group), it is kind of difficult to know where to start from.We want to split a huge application into parts so that each of us can concentrate on our own part while at the end of the day, we still want these parts to all work together without having every member to know thoroughly about the actual implementation of every parts.But an API to me, usually serves as an interface for external developers to extend on or build new things from our work without having to go directly into the core part. Since we all working in a team, having an API for each components just for us to work among ourselves seems a little overkill and funny.So what is the usual practise when it comes to situations like this? Although I am using Java in my case, I think a correct practise for such situations work for projects of all languages, right?
In my API, how can I make knowing implementation details unnecessary?
design;api
Think of it this way: When a brand-spanking-new developer joins the team, you're going to assign him to a given area of the project. Wouldn't you like him to be able to get up to speed on that section of the project so he can complete his assignment, or do you want him to spend three months learning the whole massive edifice?Or from your side - suppose you spend a lot of time on another project and need to fix a bug, wouldn't you like to be able to limit the scope of your debugging efforts?(There is a method here, just hang on.)API stands for Application Programming Interface. Nothing in that name defines at what scope it is defined for. In my opinion, every class has an API. By always thinking about how the class would be used from elsewhere, you can make each class, package, web service, and so on easy to use and maintain.As you plot your design at first, you will see several large sections. For example, in a shopping application, you can break it down into Inventory, Billing, and Shipping. Each of those will have specific things they need to communicate with each other. Each of those in turn can be broken down further. You end up with a tree. The easiest to maintain applications do not communicate across branches in this tree in undefined ways, like using public fields, public statics and singletons. They only have to worry about the fields and objects they own, through those object's public interface: its API.Everything has an API. What you should be worrying about is whether or not that API is easy to use, maintainable, and testable, not whether you need one. A well-defined interface helps you limit the scope of feature additions, bug squashing, and everyone's learning curve.