1
Q
Explain Single Resp. Principle? Pros? Breaking/Following?
A
- 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
2
Q
Open-Closed principle? Pros? Break/Follow?
A
- 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
3
Q
Explain Liskov Subs. Principle? Pros? Follow/Break?
A
- 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
4
Q
Interface Segregation Princ.? Pros? Break/Follow?
A
- 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”
5
Q
Dependency Inversion Principle? Pros? Break/Follow?
A
- 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.
5
Q
Dependency Inversion Principle? Pros? Break/Follow?
A
- 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.
6
Q
Separation of Concerns? Pros? Break/Follow?
A
- 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
7
Q
High Cohesion, Low Coupling? Pros? Explain Cohesion and Coupling! Break/Follow?
A
- 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
8
Q
Law of Demeter? Pros? Break/Follow?
A
- 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()
9
Q
Composition over Inheritance? Pros? Break/Follow?
A
-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
10
Q
Command-Query Separation? Pros? Break/Follow?
A
- 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
TDA 552 - OOP
flashcards
Decks in class (5)
# Cards
