android开发人员要求_Android开发人员的坚实原则

android开发人员要求

Basically, SOLID is one of the most significant acronyms in the Object Oriented Programming concepts. Using SOLID principles in Android development could be helpful and effective to follow clean code principles. Therefore, if Android developers design and implement their codes without using structured design principles such as SOLID principles, they will create long-lasting problems, and probability of success for an application will be decreased in future. This essay aims to discuss the importance of SOLID principles for Android developers in designing and implementing a robust application.

基本上，SOLID是面向对象编程概念中最重要的缩写之一。 在Android开发中使用SOLID原则可能会有助于并有效地遵循简洁的代码原则。 因此，如果Android开发人员在不使用诸如SOLID原理之类的结构化设计原理的情况下设计和实现自己的代码，则会造成长期的问题，并且将来会降低应用程序成功的可能性。 本文旨在讨论SOLID原则对Android开发人员在设计和实现健壮的应用程序中的重要性。

SOLID的解释是什么？ (What is the definition of SOLID?)

SOLID is an acronym for five design principles in Object-Oriented software development intended to make software designs more understandable, flexible and maintainable. These five principles are described by Robert C. Martin. SOLID principles are briefly as follows:

SOLID是面向对象的软件开发中的五个设计原则的缩写，旨在使软件设计更易于理解，灵活和可维护。 Robert C. Martin描述了这五个原则。 SOLID原则简要如下：

• S — Single Responsibility Principle (known as SRP)

  S —单一职责原则(称为SRP)

• O — Open/Closed Principle

  O —打开/关闭原理

• L — Liskov’s Substitution Principle

  L -Liskov的替代原则

• I — Interface Segregation Principle

  I —接口隔离原理

• D — Dependency Inversion Principle

  D —依赖反转原理

为什么在软件开发中应该使用SOLID原理？ (Why should we use SOLID principles in software development?)

If developers design and implement their codes without using structured design principles such as SOLID principles, they will create long-lasting problems for other developers that will want to work on the project in future. So, the probability of success for this type of software will be diminished in future. This issues are commonly referred to Software Rot.

如果开发人员在不使用诸如SOLID原则之类的结构化设计原则的情况下设计和实现自己的代码，则将给其他将来希望从事该项目的开发人员带来长期的问题。 因此，将来这种类型的软件成功的可能性将降低。 此问题通常称为Software Rot。

Software Rot是什么意思？ (What is the meaning of Software Rot?)

Software Rot or Code Rot or Software Erosion is either a slow deterioration of software quality over time or its decreasing responsiveness, which will eventually lead to software becoming faulty, unusable, and in need of upgrade.

Software Rot或Code Rot或Software Erosion是软件质量随时间缓慢下降或响应速度下降，这最终将导致软件出现故障，无法使用并需要升级。

识别软件腐烂的一些迹象 (Some signs for identifying Software Rot)

1. Rigidity: small changes leads to rebuild the entire software.

   刚性 ：微小的变化将导致整个软件的重建。

2. Fragility: changes to one component causes other unrelated components to misbehave.

   易碎性 ：更改一个组件会导致其他不相关的组件出现异常。

3. Immobility: if a component cannot be used in another system, this component is considered as immobile. Immobility usually is caused by couplings and dependencies among various components.

   固定性 ：如果某个组件不能在另一个系统中使用，则该组件被视为固定性。 固定性通常是由各个组件之间的耦合和依赖性引起的。

4. Viscosity: when implementing and testing are difficult to perform, and also take a long time to execute.

4. 粘度 ：在实施和测试时难以执行，并且执行时间也较长。

单一责任原则(称为SRP) (Single Responsibility Principle (known as SRP))

The Single Responsibility Principle indicates that every class should have one and only one responsibility. In other words, If our class does more than one responsibility, we should split the functionalities and responsibilities in various classes. Therefore, this makes the class more robust.

单一责任原则表明，每个班级都应该承担一个责任，并且只有一个责任。 换句话说，如果我们的班级承担多个职责，那么我们应该将功能和职责划分为各个班级。 因此，这使类更强大。

For instance in below example, if the User class included the UserType class attributes and behaviors, it would not be a good design for this class because in this situation class has more than one responsibility. So, if we want to change any responsibility, we will probably have to change the other responsibilities.

例如，在下面的示例中，如果User类包含UserType类的属性和行为，则对于此类而言，这不是一个好的设计，因为在这种情况下，类承担的责任不只一个。 因此，如果我们要更改任何责任，则可能必须更改其他责任。

public class User{
    private String firstName;
    private String lastName;
    public String getFirstName(){        return firstName;
    }
    public void setFirstName(String firstName){        this.firstName = firstName;    }
    public String getLastName(){        return lastName;
    }
    public void setLastName(String lastName){        this.lastName = lastName;    }
}
public class UserType extends User{    private int selecting;
    public int getSelecting(){        return selecting;    }
    public void setSelecting(int selecting){        this.selecting = selecting;    }
    public boolean isSpecialUser(){        return selecting == 7;    }
}

开/关原则 (Open/Closed Principle)

In object-oriented concepts, the Open/Closed principle states “software entities such as classes, components, modules should be open for extension, but closed for modification”; that is, such an entity can allow its behavior to be extended without modifying its source code.

在面向对象的概念中，“开放/封闭”原则指出“软件实体，例如类，组件，模块，应开放以进行扩展，而封闭以进行修改”； 也就是说，这样的实体可以允许其行为得以扩展而无需修改其源代码。

Probably, these two parts of the Open/Closed principle appear to be contradictory, but if you correctly and accurately structure your classes and their dependencies, you can be able to add functionality without editing existing source code. In general, you achieve this principle by referring to Abstraction in Object-Oriented concepts for dependencies such as interfaces or abstract classes, rather than using concrete classes. Besides, functionality can be added by creating new classes that implement the interfaces. By using this approach, you can reduces the risk of new bugs to existing code, and it leads to more robust application. For instance the below classes could be changed to the second one by using this principle.

可能，“打开/关闭”原理的这两部分似乎是矛盾的，但是，如果正确正确地构造了类及其依赖项，则可以在不编辑现有源代码的情况下添加功能。 通常，通过在面向对象的概念中引用诸如接口或抽象类之类的依赖关系中的抽象来实现此原理，而不是使用具体类。 此外，可以通过创建实现接口的新类来添加功能。 通过使用这种方法，可以减少现有代码中出现新错误的风险，并可以使应用程序更强大。 例如，可以使用此原理将以下类更改为第二类。

public class Triangle{    public double base;
    public double height;}
public class Square{    public double side;
}
public class AreaCalculate{public double getTriangleArea(Triangle triangle){        return   area = (triangle.base * triangle.height)/2;
    }
    public double getSquareArea(Square square){        return   square.side * square.side;    }

After using this principle:

使用此原理后：

public interface Shape{    public double getArea();}
public class Triangle implements Shape{    double base;
    double height;    public double getArea(){        return (base * height)/2;
    }
}public class Square implements Shape{    public double side;   public double getArea(){        return side * side;    }
}
public class AreaCalculate{    public double getShapeArea(Shape shape){        return shape.getArea();    }
}

里斯科夫的替代原则 (Liskov’s Substitution Principle)

This principle indicates that parent classes should be easily substituted with their child classes without without changing the behavior of software. It means that a sub-class should override the methods from a parent class, which does not break the functionality of the parent class. For instance, in below example each Fragment wants to implement the Interface. Thus, you should handle the requirements and changes in their class. In short, in the main implementation we should never manage logic.

该原则表明，父类应轻松替换为其子类，而无需更改 软件的行为。 这意味着子类应覆盖父类的方法，这不会破坏父类的功能。 例如，在下面的示例中，每个Fragment都想实现接口。 因此，您应该处理类中的要求和更改。 简而言之，在主要实现中，我们永远不要管理逻辑。

public interface ClickListener{
    public void onClick();  }
  public class SampleFragment implements ClickListener{    @Override
    public void onClick(){      decrementClickCount();        //You should manage the logic here!          
    }
    public void decrementClickCount(){
    }    
  }
  public class TestFragment implements ClickListener{    @Override
    public void onClick(){        incrementClickCount();        //You should manage the logic here!
    }
    public void incrementClickCount(){
    }
  }
  public void onButtonClick(ClickListener clickListener){//Handling the changes and requirements here would be a wrong place     and an incorrect solution!     clickListener.onClick();  }

接口隔离原理 (Interface Segregation Principle)

The interface-segregation principle indicates Classes that implement interfaces, should not be forced to implement methods they do not use. This principle is related to the fact that a lot of specific interfaces are better than one general-purpose interface. In addition, this is the first principle, which is used in interface, all the previous principles applies on classes. For instance, If we have the below interface, it will force clients to implement onLongClick even if they don not need long press. Therefore, it can lead to overhead of unused methods. In a word, it could be helpful for ignoring the unused methods by having two separate interfaces

接口隔离原则指示实现接口的类，不应被强制实现其不使用的方法。 该原理与以下事实有关：许多特定接口比一个通用接口要好。 另外，这是第一个原则，它在接口中使用，所有先前的原则都适用于类。 例如，如果我们具有下面的界面，即使他们不需要长时间按下，它也将强制客户端实施onLongClick。 因此，这可能导致未使用方法的开销。 总之，通过具有两个单独的接口来忽略未使用的方法可能会有所帮助

public interface MyOnClickListener{    void onClick(View v);boolean onLongClick(View v);void onTouch(View v, MotionEvent event);}

After using this principle:

使用此原理后：

public interface OnClickListener{void onClick(View v);
}public interface OnLongClickListener{boolean onLongClick(View v);}public interface OnTouchListener{
    void onTouch(View v, MotionEvent event);}

依赖倒置原则 (Dependency Inversion Principle)

This principle suggests that high level modules should not depend on low level. So, both should depend on abstractions. Furthermore, abstraction should not depend on details. Details should depend upon abstractions.

该原理表明高级模块不应依赖于低级模块。 因此，两者都应依赖抽象。 此外，抽象不应依赖细节。 细节应取决于抽象。

In a word, classes should depend on abstraction, but not on concretion. For example, In below example a new abstraction layer is added through the IEngine Interface for removing the dependency between two classes.

一言以蔽之，类应该依赖于抽象而不是依赖于具体。 例如，在下面的示例中，通过IEngine接口添加了一个新的抽象层，以删除两个类之间的依赖关系。

public class Engine{ }
public class ToyCar{    Engine engine;
    ToyCar(){        Engine = new Engine();    }
}

After using this principle:

使用此原理后：

public interface IEngine{
}
public class Engine implements IEngine{    double capacity;
}
public class ToyCar{    IEngine iEngine;
    ToyCar(IEngine engine){        iEngine = engine;
    }
}

Another example in Android can be mentioned here is if we want to implement MVP design pattern, we need to keep reference of Presenter in our View. As a result, if we keep the Presenter concrete class object in View, it causes to tight coupling. Basically, we should create an interface for decoupling in this situation. Additionally, There are some popular libraries for implementing this principle in Android such as Dagger 2.

这里可以提到Android中的另一个示例，如果我们要实现MVP设计模式，则需要在View中保留Presenter的引用。 结果，如果将Presenter具体类对象保留在View中，则会导致紧密耦合。 基本上，在这种情况下，我们应该创建一个用于解耦的接口。 此外，还有一些流行的库可在Android中实现此原理，例如Dagger 2。

In conclusion, fundamentally, using SOLID principles in Android development could be helpful to follow clean code principles. Thus, if Android developers design and implement their codes without using structured design principles such as SOLID principles, they will create long-lasting problems, and probability of success for an application will be decreased in future. This essay aims to discussed the importance of SOLID principles for Android developers.

总之 ，从根本上讲，在Android开发中使用SOLID原则可能有助于遵循简洁的代码原则。 因此，如果Android开发人员在不使用诸如SOLID原理之类的结构化设计原理的情况下设计和实现自己的代码，则会造成长期的问题，并且将来会降低应用程序成功的可能性。 本文旨在讨论SOLID原则对Android开发人员的重要性。

翻译自: https://medium.com/kayvan-kaseb/the-solid-principles-for-android-developers-75fd4ca3ef84

android开发人员要求