Android – Architecture thinking (a) thinking before writing code

1. what are OOA, OOD, OOP?

  • 1.OOA: Object-Oriented Analysis (object oriented analysis)
    calls “abstractions” to analyze problems from an overall point of view, but “more concrete implementations”, that is, “focus on the whole”.
  • 2.OOD: Object-Oriented Design (object oriented design),
    is the transition link and specification of OOA, dealing with various dependencies, emphasizing the need to rely on abstractions rather than concrete implementations.
  • 3.OOP: Object, Oriented, Programmin (object oriented programming)
    uses encapsulation, inheritance, polymorphism to make the program “reusability, flexibility, extensibility”

2. how to make use of OOA, OOD, OOP

  • What does OOA Analysis analyze?
    object oriented analysis, analysis of the object, where the object comes from? From demand
  • How is OOD Design designed?
    object oriented design requires the association of these objects into a separate class, module, and system
  • OOP, Programming, abstract programming,
    , object oriented programming, encapsulation, inheritance, polymorphism, easy maintenance and easy expansion

Simply draw a map, and then review:

Android - Architecture thinking (a) thinking before writing code,
  • Do a good job of requirement analysis, system design, discard, copy, paste, lead the development process
  • Reasonable design of abstraction layer and low layer, reduce the dependence of the coupling
  • Peel cohesion complex code, so as to avoid changes in demand lead to the overall reconstruction and rewriting.
What exactly does Android - Architecture thinking (a) thinking before writing code

3. what should be done before writing code?

Think clearly about what is => discuss =&gt repeatedly with product discussions; split technology point => prioritize business; followed by UI => concrete implementation

  • First of all, I want to know exactly what kind of function the product wants, and whether this function is really important to the product, is there any way to enlarge this effect more?.
  • Discuss with the product, understand the requirements they want to express through the APP, translate them into real requirements, and draw the flow chart to confirm the product repeatedly.
  • Demand understanding is good, you can first split research related technical points. Do not rush to express this function, can not achieve, this effect takes time. Why don’t you make it better?
  • After a general understanding, the team together to discuss what specific implementation, who will achieve. (make sure everyone has an overall understanding of the code, not to maintain their own small modules, which is not conducive to growth, but also to the team)
  • UI is generally more frequent than business logic changes, so it’s best not to worry about drawing UI, as long as you have a rough UI framework. First, the business logic is perfect (network interaction, cache, click event, jump), and if there is a surplus, you can write unit test to test the correctness of the C layer or the P layer logic. No problem. Write the UI implementation again.
  • What about the rest of the implementation? If there are no ready-made code to use, you can split it into several task. First, you can string tasks through workflow, whether it’s a flowchart or a TODO pseudo code. Then search for the corresponding solution for each task.
  • All technical problems can not be unsolvable, as long as patience, we must find a solution. Don’t worry, don’t try to save trouble. Every problem you encounter is the ladder to your progress. If you can’t solve it, change a compromise solution!

4. what adds extra work and risk?

  • 1. copy and paste (without thinking) the code copied by
    is often something that is not understood, and the code may hide configurations that fail to be noticed, leading to the need for bug for a long time
  • 2., the code specification is poor (maintainability),
    naming specifications, not written comments, write, do not know what this code to do, it is difficult to maintain.
  • 3., light design (not considering multiplexing and decoupling)
    all code written in a class, ignoring the design principle, the extraction is not reasonable, resulting in a relatively cumbersome, difficult to understand and maintain later.