Please enable JavaScript.
Coggle requires JavaScript to display documents.
DesignPrinciples - Coggle Diagram
DesignPrinciples
Code Smells
-
Duplication
when you have blocks of code that are similar, but have slight differences. These blocks of code appear in multiple places in your software
Long method
Having a long method can sometimes indicate that there is more occurring in that method than should be. Or it's more complex than it needs to be
-
Too small classes
Getter, setter data classes
Data clumps are groups of data appearing together in the instance variables of a class, or parameters to methods
-
-
Divergent Change
The divergent change code smells occur when you have to change a class in many different ways for many different reason
Large classes, and poor separation of concerns with too many responsibility
Shotgun Surgery
A change in one place requires you to fix many other areas of the code as a result. This could happen when you're trying to add a feature, adjust code, fix bugs or change algorithms. Ideally, you want your changes to be localized
Feature envy occurs when you've got a method that is more interested in the details of a class other than the one that it's in
If it seems like two methods or classes are always talking to one another and should be together, chances are they probably should
inappropriate intimacy
So, a method in one class calls methods of the other and vice versa. Should these classes be so closely coupled? Probably not. Likely, there should be some way to remove this cycle. To remove this cycle, you can factor out methods that both classes use into another class. This might free up some of the close communication. At the very least, you should be able to make it, so that the communication only occurs one way.
-
-
Switch Statements
Try to use polymorphism, and then based on the class called, the method will be picked up rather than putting if else statements
Speculative generality occurs when you make a superclass, interface or code that is not needed at the time, but you think you may use it someday
-
Open/Closed
-
Reusable
Reusable code, means that you don't need to reimplement something that's already been done
This principle states, that classes should be open for extension, but closed to change
Closed
Tested, encapsulated and stable
-
Open/Closed Principle is a concept that, helps keep a system stable, by closing classes to changes, and allows the system to open for extension through the use of inheritance, or interfaces.
Dependency Inversion
change the referencing of concrete classes from being direct to indirect,
generalize the behaviors of your concrete classes into abstract classes and interfaces,
have client classes interact with your system through a generalization rather than directly with concrete resources
-
Least Knowledge
The Law of Demeter. The underlying idea of this law is that classes should know about and interact with as few other classes as possible.
First rule, states that a method, M, in an object, O, can call on any other method within O itself
method, M, can call the methods of any parameter, P
method, M, can call a method, N, of an object, I, if I is instantiated within M.
any method, M, in object, O, can invoke methods of any type of object that is a direct component of O
The Law of Demeter appears to be a complicated and abstract concept, but all the rules come down to the principle that you should not allow a method to access another method by reaching through an object. This means that a method should not invoke methods of any object that is not local
These objects should be passed in through a parameter or they should be instantiated within a method, or they should be an instance variables
Returned objects must be of the same type as: those declared in the method parameter, those declared and instantiated locally in the method, or those declared in instance variables of the class that encapsulates the method
According to this design principle, a method, M, of an object should only call other methods if they are:
- encapsulated within the same object,
- encapsulated within an object that is in the parameters of M,
- encapsulated within an object that is instantiated inside of M, or
- encapsulated within an object that is reference in an instance variable of the class for M
Composing Objects
that aggregation and delegation offer less coupling than inheritance. Since the compose classes don't share attributes or implementations of behaviors, they are more independent of each other
-
-
The biggest drawback of composition is that you must provide implementations for all behavior without the benefit of inheritance to share code. This means that you night have very similar implementations across classes.
Liskov
any subclass can stand in for its base class. Because of inheritance, a subclass is expected to have the same characteristics and behave in the same way.
If a class, S, is a subtype of a class, B, then S can be used to replace all instances of B without changing the behaviors of a program.
method cannot be "strengthened", a subclass cannot add more conditions to determine if a method should be called
The condition of the program after the execution of a method cannot be "weakened" by a subclass. This means that the subclass should cause the state of the program to be in the same state as the base class after a method call. Subclasses are allowed to "strengthen" the postcondition of a program. For example, if the base class sets an alarm for a specific date, the subclass must do the same, but the result can be more precise by setting the specific hour as well
Invariant conditions that exist in the base class, must also remain invariant in the subclass. Since invariant conditions are expected to be immutable, the subclass should not change them as it may cause a side effect in the behaviours of the base class or the program.
-
Interface Segregation
a class should not be forced to depend on methods it does not use. This means that any classes that implement an interface should not have dummy implementations of any methods defined in the interface. Instead, you should split large interfaces into smaller generalizations.
-
interfaces should be split up in such a way that it can properly describe the separate functionalities of your system
Refactoring
Refactoring is the process of making changes to your code so that the external behaviors of the code are not change, but the internal structure is improved. This is done by making small, incremental changes to code structure and testing frequently to make sure these changes have not altered the behavior of the code