Years ago, a marketing campaign used the phrase "What happens in Vegas, stays in Vegas." When I teach object-oriented design for Java developers and I introduce the concept of encapsulation, I use a slightly modified version of Sin City's slogan. It's meant to emphasize the importance of the Agile principle concerning technical excellence when designing loosely coupled, highly cohesive classes (i.e., designing to interfaces). My version of the slogan goes like this, "What happens between the curly braces, stays in the curly braces." For those project managers, business analysts, or quality assurance people who don't understand what I just said, go find you favorite developer, schedule a pair programming session, and prepare to get your geek on.
If you think about the fundamental characteristics of an interface, it consists of the input, output, method name, and exception. Whether we're talking about the individual methods contained in a class or the aggregate collection of methods spanning multiple classes to make up an API, designing to an interface is core to achieving technical flexibility.
For example, if Joe TeamMember defined a method to calculate a shipping charge, he would specify the input, output, method, and optional exception. The input would be the weight defined as a float and zip code defined as an int; the output would be a float, specifying the dollar amount for shipping; the method would be called calculateShippingCharge; and the checked exception would be omitted. The method signature would look like this: public float calculateShippingCharge(float packageWeight, int zipCode) {/* What
happens between the curly braces, stays in the curly braces */}
Given this contract/interface, whoever volunteers (remember, we want to promote ownership in Agile teams) to implement this specification would be correct as long as they implement it without changing those interface characteristics. If multiple developers tackled the task, you'd find similarities within the implementation (the code between the curly braces), but you'd find some variance as well. Why? Because all developers solve problems differently, and that's where the beauty and necessity of designing to interfaces helps keep us safe by playing between those predefined guardrails.
If you're a technical lead or architect, focus on helping the team establish those clear contracts or interfaces. Don't micromanage them by telling them how to name their variables or what data type to use in the method. Instead, encourage them to focus on adhering to the contract and supporting the design. Allow them the flexibility to exercise their individual creativity to solving the problem. Remember, in addition to applying the KISS (Keep It Simple Silly) principle, you will also be promoting the Agile principle "Continuous attention to technical excellence and good design enhances agility."
Commenti