• High-level modules should not depend on low-level modules. Both should depend on abstractions.
• Abstractions should not depend on details. Details should depend on abstractions.
• components should depend on abstraction.

module need to manage high-level functionality with zero implementation details this allows the module to be used for any type of application and for all modules inside the application.

• Example:

we have an existing system which sends notifications to users by email

public class Email{public void sendMail(){// send mail 
}
}public class Notification{private Email _email;public Notification(){_email = new Email();
}public void promotionalNotification(){_email.sendMail(); …

• Developers shouldn’t be forced to depend upon interfaces that they don’t use.
• Example:

public interface someInterface{public int methodOne(){
// Do something}public int methodTwo(){
// Do somthing diffrent}}

if you want to implement this Interface

public someClass implements someInterface{public int methodOne(){
// logic to do something}public int methodTwo(){
}}

and only need to overwrite one method only why you forced to overwrite the other method and left it empty.

we solve this problem by creating two separate interfaces, every interface has only relevant methods.

public interface someInterface{public int methodOne(){
// Do…

• A subclass should behave in such a way that it will not cause problems when used instead of the superclass.
• LSP is a definition of a subtyping relation, called strong behavioral subtyping.
• if S is a subtype of T, then objects of type T may be replaced with objects of type S without altering the desirable properties of the program.
• Example:

Bad Example of LSP:

public class Bird{
 public void fly(){}
}
public class Duck extends Bird{}

The duck can fly because it is a bird, But what about this:

public class Ostrich extends Bird{}

Ostrich is a bird, But…

• Software entities should be open for extension but closed for modification.
• The OCP states that the behaviors of the system can be extended without having to modify its existing implementation.
• New features should be implemented using the new code, but not by changing the existing code.
• reduces the risk of breaking the existing implementation code.

if simple extensions to the requirements force massive changes to the software, then the architecture of that software is bad, and a good software architecture would reduce the amount of changed code to the barest minimum. Ideally, zero.

• build the classes in a way that…

• A class should have only one reason to change.
• this means that a class should not be loaded with multiple responsibilities and a single responsibility should not be spread across multiple classes or mixed with other responsibilities.
• The reason is that the more changes requested in the future, the more changes the class needs to apply.
• Example:

One of the most common User Experience (UX) issues in the Mobile Development track, is when you have input filed and the user finishes typing inside it and need to close the keyboard to continue with another thing, he/she can’t do simply with tapping out of input instead he/she forced to press back button, and this work against UX principles, you need to make using of your application done with familiar behavior for users, not forcing them to follow your rules this increase useability of your application.

use-case with Dart/Flutter

If you have TextFiled or any input with some decorations like that:

as in the previous part, we discussed the rules of choosing names for variables, functions, class ...etc, let us take another step to something more important which is Functions, Function is the basic building block and the core of any system.

But first Let’s give an example to show the concepts that will be discussed. If you have a haystack and needle inside it, and you have to extract the needle from it, which case will need fewer efforts and time?