Features
Features:

Product Tour >

Edraw AI >

Paid Plans:

Individuals >

Business >

Eduaction >
Resources
Blog

History

How-tos & Tips

Discovery

Biography

Business Analysis

Examples

AI concept Map

Free AI Mind Map Generator

Onenote Mind Map

Bcg Matrix Examples

Nike Marketing Strategy

Unilever SWOT Analysis

Make Mind Maps in Google Docs

Guide

FAQs

What's New

Resource Center
Templates
All Templates

Brain Storming Templates

Strategy and Planning Templates

Project Management Templates

Product Management Templates

Human Resources Templates

Agile Workflow Templates

Marketing Templates

Education Templates

Fun and Games Templates

User Gallery
Download
Pricing
Enterprise

MindMap Gallery The Art of Software Framework Design

The Art of Software Framework Design

When we want to impart knowledge to others about the art of software framework design, it will be difficult to convince them to accept our knowledge because they have no experience similar to ours.

Edited at 2024-04-10 17:25:12

PlotWizard

Recent works View more works>>

The Art of Software Framework Design

PlotWizard

Recent works View more works>>

Recommended to you
Outline

The Art of Software Framework Design

Preface

"Once the API is released, it will facilitate our eternal coexistence"

When we want to impart knowledge to others, it will be difficult to convince them to accept our knowledge because they have no experience similar to ours.

Theory and Reasons

"Art" or "Engineering"

Important uniqueness of API: Consistency

How is there consistency within the group?

Perfect teamwork

shared vision

public term

P2 A year later, I confirmed this guess. Because Netbeans is an open source project, there is an API that attracts external developers. At the beginning, this external code contributor mainly did some bug fixing work. Later, he began to be responsible for a sub-project alone and designed related APIs. The person who was originally responsible for designing this API said that he found that the API of this sub-project was getting worse and worse, but he couldn't find the reason and hoped that I could help. He said: He doesn't like these new APIs very much, and he doesn't want to integrate them into the projects he is responsible for. But he also couldn't tell what the problem was with these new APIs. Finally, he said that these new APIs seemed inconsistent with his original vision. I once said something similar to him. By my standards, the API he wrote is inconsistent with the idea of NetBeans' API!

methodology

rationalism

Empiricism

No emotion

Shallow understanding

The extent of understanding something is limited to knowing how to use it

deep understanding

Grasp the principles and laws behind something

Most of the time "shallow understanding" is enough

selective cluelessness

Some content requires in-depth understanding

The threadless principle of application development

Try to allow the relevant personnel who are ultimately responsible for the integration to do a good job in the integration without having to understand the system in depth.

Object: people

Criteria for evaluating the quality of APIs

Why?

We want to be able to "threadless" assemble large building blocks into applications

what?

Method, class, field signature

File (unix pipe)

Environment variables and command line options

Text information (toString)

protocol

Behavior

The most important way to judge compatibility is "normal operation", but this is determined by the specific internal implementation.

null return value

globalization

…

Quality

understandability

Pathways for communication between designers and developers

The importance of examples

consistency

Lower the learning curve

stay compatible

visibility

Provide a "portal" to find the solutions you need

Based on actual or expected goals and tasks

Users don't care about specific classes

Simple tasks should have simple solutions

ordinary user

extended user

protect investment

Think more about users

Changing goals

backwards compatible

Source code compatible

Binary compatible

Functionally compatible

easy to miss

Attitude, “good bosses” don’t complain about customers

The importance of use case orientation

Example

what should I do

Scenes

You should do this first and then that

API Design Review (Excellent API Rules)

Use case driven API design

When designing an API, it is necessary to conduct an abstract analysis based on some specific scenarios and understanding of the API, and finally provide a design

API design consistency

APIs are often completed by multiple designers, but the entire team must be able to maintain some basic principles of "best practices". No matter how well-designed an interface is, as long as it violates the consistency of the entire team, we would rather settle for the second best.

Simple and clear API

Simple and common tasks should be easier to handle. If you design based on a use case-driven approach, you can easily verify whether these APIs can complete those important use cases through scenarios that can be easily implemented.

less is more

The functions provided by an API to the outside world should only include the functions described in the use cases. This avoids discrepancies between required functionality and what is actually provided.

Support improvements

The library must be continuously maintained. Even if new needs arise or the original author leaves, this class library will not be abandoned.

Design practice

Only make public what you want to make public

Easy to add, difficult to remove

When releasing the first version, remove unnecessary content

Methods over fields

Except for static and final declared basic types, string constants, enumerations and immutable objects, no other fields should be exposed.

Factory methods are better than functions

The return value of a factory method is not necessarily an instance of the declared type, but can be an instance of a subclass

The object returned each time is not necessarily a newly created object, it can be cached

Synchronization control, unified processing of code before and after creating an object

Make everything immutable

If you don't want to have subclasses, you should make them non-inheritable

Avoid abusing setter methods

Never declare setter methods in formal APIs unless necessary

setEnable

May be context sensitive

isEnable judgment makes setEnable meaningless

Expose functionality through friend methods whenever possible

Java's default package access method, internal class

Give object creators more rights

access permission

Avoid exposing deep inheritance

code reuse

Function reuse

"Inheritance" is not used to change specific behaviors, but to add some additional actions

If you inherit a class just to switch the execution path of certain methods, then this approach should be avoided

Recommendation: avoid deep inheritance, define program interfaces, and let users implement these interfaces

Program towards interfaces rather than implementations

Separation of abstract definition (interface) and implementation

cooperate

Make it clear to API users: when using APIs, you should follow correct principles. If you need to use an API, you must abide by the principles of the API and do not break it.

Clearly explain the requirements of the API, define corresponding use cases, and help API designers implement such APIs.

Protected methods cannot be removed, resulting in modification by subclasses

Adding an abstract method to an interface will force its non-abstract subclasses to implement the method

Modular architecture

Object-oriented doesn't avoid spaghetti programming

The purpose of modularization: to achieve loose coupling of various components

Modular architecture separates specification from implementation

In the module where the specification is located, there will be at least a small "entry"

dependency injection

Spring

Netbean lookup

Expand

P111 In 2001, we submitted a topic called "Component Positioning and Cooperation" to the JavaOne conference. The content in this topic is somewhat related to this chapter. We believe that the content involved in this topic is important for all modular programs. . However, the organizing committee of the JavaOne conference at that time may simply think that the name of the topic is not cool enough, or maybe because they feel that the word component is overused, and the word "component" includes almost everything imaginable. , so the issue was not accepted. Until 2006, my colleague Tim Boudreau and I submitted a similar topic called "Patterns of Discovery Injection and Dependency Injection in Modular Architectures". Sure enough, as we expected, the topic was accepted by the organizing committee. This means that you must find terms that are close to your target audience in order to impress them. Once they heard the word "dependency injection", their hearts were struck. Just like the word API, an appropriate name facilitates communication. For users, the easier it is for them to understand the word API, the easier it is for them to accept API-related content.

In fact, there are a few more words: architecture, pattern

When designing an API, differentiate between its target user groups

API

Can be added but not removed

Called by others to complete certain functions

final class

cohesive, self-contained

SPI

Service Provider Interface

Can be removed but not added

For others to extend API functionality

interface

Avoid mixing the two

Reasonably decompose the API

API

SPI

Classification of NetBeans

Core API

Support API

Core SPI

Support SPI

Organize your API structure according to the different needs of your user groups

Keep testability in mind

Mock object

Provide Mock objects for the API

Test code is part of the specification

Good tools make API design easier

wizard

Let customers get started as soon as possible

The first goal of the project is to quickly bring it to market

Each important technology in NetBeans has a corresponding wizard to establish the initial basic framework.

Compatibility test suite

For SPI users and API implementers

Collaborate with other APIs

Use third-party APIs with caution

packaging mode

Expose only abstract content

The more exposed, the less room there is for evolution.

Strengthen API consistency

Agents and Portfolios

Avoid API misuse

There needs to be consistency between all levels.

Some contents of the specific runtime of the API

“Notorious” – Instead of complaining about users, it’s better to change your attitude

"Guardian" - automated testing

Synchronization and deadlock

Correctly and appropriately describe its threading model

Pitfalls in Java Monitors

Inheritance affects synchronized

For public APIs, external methods cannot be declared as synchronized.

Java synchronization and deadlocks with pitfalls everywhere

declarative programming

Basic idea: Instead of letting API users tell the program step by step what to do, they only need to tell the program their results, and then let the API do the work.

NetBeans Lookup implementation requires only simple XML description and does not require user registration or logout.

self-descriptive

daily life

Real life is full of changing factors, and theoretical things cannot be applied unchanged in life. Not only do you need to know what works and what doesn’t work, but you also need to know how to work in order to do so

Extreme opinions are harmful rather than helpful

API required

is beautiful

is correct

If ease of use is sacrificed for correctness, more problems may arise

Mercurial and SVN

Keep it simple

is high performance

Absolutely compatible

is symmetrical

Contradictions in API design

contradictory

Wiki definition: "Belief in two conflicting views simultaneously without realizing that they are contradictory"

Safety department

Aircraft security

Developers complain about things like reviews, programming standards, etc. all the time. But API guardians need to stay alert at all times, otherwise problems may arise due to a small oversight. On the other hand, it's not just a minor problem, it at least shows that the work you're doing is really useful.

minority report

Improve API

Teamwork

Conduct code reviews before submitting code

Convince developers to provide documentation for their APIs

Backward reasoning

before writing code

Overview

FAQ

A conscientious monitor

Tools monitor all changes that require attention

If you don’t have tools, you need someone who is “all-knowing and all-powerful”

Receive API patches

Only take good advice

Develop requirements

The requirements cannot be too complicated

Use competition games to improve API design skills

Provided for download by www.xmindchina.net