General Principles Flashcards
Explain Single Resp. Principle? Pros? Breaking/Following?
- Each class or method should only have a single responsibility, should only have one reason to change
- Creates more robust code, bc. changes are easier, easier to test, code for a certain responsibility is found in one place, making for easy access
- Break: class BankAccount that handles deposits and withdraws
- Follow: Split to two classes, BankDeposit and BankWithdraw
Open-Closed principle? Pros? Break/Follow?
- Modules should be open for extension, but closed for modification.
- Easy to add new functions without (heavy) code modification
- Break: Code with switch-statements that needs to be changed for every addition to program
- Follow: Write robust code, with intention to never need to changed
Explain Liskov Subs. Principle? Pros? Follow/Break?
- If B is a subtype to A, all instances of A should be replaceable with instances of B, without undesirable changes to the code. Subclasses should not change the behavior of superclasses
- Creates better inheritance hierarchy, and change supertypes out for subtypes without unexpected behavior
- Break: Square is a subclass to Rectangle. When using setWidth in Square, both Width and Height is changed, which won’t happen in Rectangle, thus breaking LSP
- Follow: Car inherits from Vehicle. Car has the same behavior as Vehicle, and we can expand the behavior with methods specific for Car
Interface Segregation Princ.? Pros? Break/Follow?
- Similar to SRP but for interfaces
- Creating smaller and more precise interfaces, clients do not need to implement methods that are never used. No need to rewrite the code when a function you are not using changes its signature. Should be thin!
- Break: Fat interface with many behaviors. Ex. “IGenerateReport” creates a pdf and excel-document, despite only wanting a pdf.
- Follow: Create “IReportPDF” and “IReportExcel”
Dependency Inversion Principle? Pros? Break/Follow?
- High-level modules should not depend on low-level modules. Should depend on abstraction. Abstractions should not depend on detail, detail should depend on abstraction
- Creates few and loose dependencies, all dependencies should be intentional. Creates code with low coupling and more flexibility
- Break: Superclass with strong dependencies with its Subclasses. Annoying to change code
- Follow: Subclasses are created to fit the superclasses. Superclasses does not need to be changed when we change/expand in the subclass.
Dependency Inversion Principle? Pros? Break/Follow?
- High-level modules should not depend on low-level modules. Should depend on abstraction. Abstractions should not depend on detail, detail should depend on abstraction
- Creates few and loose dependencies, all dependencies should be intentional. Creates code with low coupling and more flexibility
- Break: Superclass with strong dependencies with its Subclasses. Annoying to change code
- Follow: Subclasses are created to fit the superclasses. Superclasses does not need to be changed when we change/expand in the subclass.
Separation of Concerns? Pros? Break/Follow?
- Similar to SRP, but refers to modules. An example is MVC, where you separate to M, V, and C
- Makes it possible for multiple programmers to work on the code at once. Makes it more reusable, maintainable, reusable
- Break: Having a method that handles log-in for companies and private customers. Using MVC without being seperated.
- Follow: Creating two separate methods. Following MVC as it is intended
High Cohesion, Low Coupling? Pros? Explain Cohesion and Coupling! Break/Follow?
- Cohesion: Determines the “connections” in a module
- Coupling: How strongly dependant two modules are on each other
- High cohesion means that components in a module co-operate to solve its responsibility without the need for other modules
- Low coupling means that modules are (as much as possible) independent of each other
-Possible for code reuse
- Break: Class 1 and Class 2 have objects of each other. Method A in Class 1 refers to method B in Class 2, and vice versa
- Follow: Method A is only dependant on components in its own class to solve its tasks. Same for method B. IF NECESSARY only one class can hold objects of the other
Law of Demeter? Pros? Break/Follow?
- Avoids dependencies through a class should only know its “friends”, and the class should not call on methods from any other friends (friends, in this case, is classes?)
- Reduces coupling, more maintainable, reusable. Allows for adherence to other SOLID principles
-Break: objectA.getObjectB.getObjectC.doSomething()
-Follow: Methods acting on internal objects:
objectA.doSomething()
Composition over Inheritance? Pros? Break/Follow?
-Since I am part of group A8, I have no idea what composition is. (jk(?))
- Composition: A class that references one or more objects of other classes in instance variables. Has-A association between objects
- Inheritance: Basing an object or class upon its super-classes with a set of attributes and methods. Adheres to polymorphism and creates Is-A association
- Composition preferred: fewer dependencies, more robust, and more flexible. (More robust since subclasses can stop working if superclass is modified)
- Break: Focus on inheritance, rather than delegation(composition)
- Follow: Focus on delegation, rather than inheritance
Command-Query Separation? Pros? Break/Follow?
- Method should either return command or a query.
- Reduces the chance of unexpected behaviors
- Break: “.pop”-function modifies a list and returns a new list