Please enable JavaScript.
Coggle requires JavaScript to display documents.
PRINCIPLES - Coggle Diagram
PRINCIPLES
SOLID
Single Responsability
Definition:
A class should only have one responsibility. Furthermore, it should only have one reason to change
-
Example:
Uma classe que é reponsável apenas pelos metodos e atribuitos relacionados apenas a seus objetos, outros detalhes como standard out, devem ser implementados em outra classe.
Open-Close
Definition:
classes should be open for extension, but closed for modification. In doing so, we stop ourselves from modifying existing code and causing potential new bugs
-
Example:
Ao inves de usar classes fazer modificações, utilizar interfaces implementar as novas modificações nas subclasse.
Liskov Substitution
Definition:
if class A is a subtype of class B, then we should be able to replace B with A without disrupting the behavior of our program.
-
Example:
BAsicamente os filhos podem ser utilizandos onde os objetos da superclasse também são aceitos...um exemplo seria a instanciação de uma collection com uma subcollection, Set<Integer> sets = HashSet<Integer>(); ou coisa do tipo. Assim esse objeto poderá servier de argumento para qualquer paramento que aceite um tipo Set.
Interface Segregation
-
Benefits:
By doing so, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them
Example:
Por exemplo um cargo de cuidador de urso poderia definir uma interface com 3 methods/atividades, porem esse cargo poderia ser quebrado em 3 subfunções, uma pessoa pra lavar o uso, outra alimentar e outra careciar o bicho...na segregação dessa interface, poderiamos definir novas funções, cada uma podem implementar um conjunto das atividades.
Dependency Inversion
Definition:
Refers to the decoupling of software modules. This way, instead of high-level modules depending on low-level modules, both will depend on abstractions.
-
Example:
Ao inves de utilizar o constructor new, utilizar um pattern, como o factory para criar os objetos. Também poderiamos utilizar uma interface para generalizar uma categoria de objetos, ao invés de um em especifico.
Utilizar interfaces como dependencias ao inves de classes concretas. Fazer uso de objects factories
Example2:
Ao inves de:
public constructor(){ monitor = new Monitor() }
Fazer:
public constructor(Monitor monitor){ this.monitor = monitor }, além disso, estariamos cumprindo com o principio de Liskov acima