Software Engineering + SOLID

What is the Dependency Inversion Principle?

High level modules should not depend on low-level modules, but should depend on abstraction. Depend upon abstractions, do not depend upon concretions. High-level modules, which provide complex logic, should be easily reusable and unaffected by changes in low-level modules, which provide utility features.

I in SOLID?

Interface Segregation Principle

What is Open / Closed principle?

Prefer extension over modification A class should be easily extendable without modifying the class itself. "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Plan-driven processes

Processes where all of the process activities are planned in advance and progress is measured against this plan.

Pros and cons of the Waterfall Model

Pros: - Easily manageable process. - Probably the most effective model, if you know the requirements. - Extensive documentation. Cons: - Inflexible partitioning of the project into distinct stages. - Difficult to respond to changing customer requirements. - Feedback on system performance available very late and changes can be very expensive.

Real name of Open / Closed principle?

The Open for Extension Closed for Modification Principle

How do you spot the lack of use of the Open / Closed principle?

- Generally, the code will mention types, and use if/else to check through them. - In this case, customer is defined with a type, and it only supports 2 types (0 and everything else). To add functionality, we have to modify the code, rather than simply write a new class.

How do you spot the lack of use of the Single Responsibility Principle?

- If a class can do too many things, or things that seem unrelated, probably Single Responsibility is broken. - Here, Customer is both in charge of dealing with the Database, as well as logging. Too different responsibilities. How to fix - Separate the functionality into different classes. - Now, file logging is handled by the FileLogger class

How do you spot the lack of use of the Interface Segregation Principle?

- If a class implements an interface, but just throws an exception when trying to call one of it's methods, it is usually Liskov. - In this case, both our machines implement the ICoffeeMachine interface, but they need to throw exceptions because they can't implement the entire interface. How to fix - Split the interface up into smaller interfaces that inherit from the same interface - In this example, ICoffeeMachine has become three interfaces, one still called ICoffeeMachine, and the other two inherits from it.

How do you spot the lack of use of the Dependency Inversion Principle?

- The class in question will contain something (like a logger or a context) which is initialized by the class itself, rather than given as an argument in the constructor. - This is this example, the FileLogger is the offender. How to fix - To fix it, take the class in question as an argument in the constructor. - Here, our BetterCustomer now takes an ILogger as an argument, allowing us to easily substitute it with another logger for testing purposes.

What does FURPS+ stand for?

**F**unctionality Capability (Size & Generality of Feature Set), Reusability (Compatibility, Interoperability, Portability), Security (Safety & Exploitability) **U**sability (UX) Human Factors, Aesthetics, Consistency, Documentation, Responsiveness **R**eliability Availability (Failure Frequency (Robustness/Durability/Resilience), Failure Extent & Time-Length (Recoverability/Survivability)), Predictability (Stability), Accuracy (Frequency/Severity of Error) **P**erformance Speed, Efficiency, Resource Consumption (power, ram, cache, etc.), Throughput, Capacity, Scalability **S**upportability (Serviceability, Maintainability, Sustainability, Repair Speed) Testability, Flexibility (Modifiability, Configurability, Adaptability, Extensibility, Modularity), Installability, Localizability **+**: Implementation, Interface, Operations, Packaging, Legal

When is it good use the Waterfall Model?

- Appropriate when the requirements are wellunderstood. - Short, clearly definable projects (e.g. maintenance). - Very large, complex system development, that requires extensive documentation, safety critical systems.

LSP can be violated because of the following:

- Preconditions cannot be strengthened in a subtype. - Postconditions cannot be weakened in a subtype. - Invariants of the supertype must be preserved in a subtype. - History constraint (the "history rule"). Objects are regarded as being modifiable only through their methods (encapsulation). Because subtypes may introduce methods that are not present in the supertype, the introduction of these methods may allow state changes in the subtype that are not permissible in the supertype. The history constraint prohibits this. A violation of this constraint can be exemplified by defining a mutable point as a subtype of an immutable point. This is a violation of the history constraint, because in the history of the immutable point, the state is always the same after creation, so it cannot include the history of a mutable point in general.

What happens if you don't use the Single Responisibility Principle?

- might need to update the dependencies or recompile the dependent classes even though they are not directly affected by your change - You need to change your class more often, and each change is more complicated, has more side-effects, and requires a lot more work than it should have.

What is the Single Responsibility Principle?

A class should only have one, and only one, reason to change. A class should have only a single responsibility. Don't put functions that change for different reasons in the same class

What is the Interface Segregation Principle?

A client should not be forced to use an interface, if it doesn't need it Many client-specific interfaces are better than one general-purpose interface. Classes that implements an interface should not be forced to implement methods that they don't use.

Waterfall Model

A series of steps in which a software system trickles down from analysis to design to implementation. Requirements -> Design -> Implementation -> Verification -> Maintenance

How do you spot the lack of use of the Liskov Substitution Principle?

A superclass will have some method that makes no sense to have for one of the subclasses. In this case, it makes no sense that a student needs to be able to grade assignments. How to fix - Split the super class into 2 classes where one inherits from the other. - In the former example, we make a Grader abstract class, which inherits from Person, and move the GradeAssignments method into our new Grader. Professor now inherits from Grader, while Student still only inherits from Person

What does CRIVF stand for?

Confusing - difficult to understand Rigidity - difficult to change: To make a modification, you need "touch" a lot of other stuff. Immobility - inability to reuse software from other projects or from parts of the same project: The software does more than what you need. The desirable parts of the code are so tightly coupled to the undesirable ones that you cannot use the desirable parts somewhere else. Viscosity - viscosity of design & viscosity of the environment: There are several ways to make changes, to preserve the design, others do not, and when design preserving methods are harder to employ than the hacks, then the viscosity of design is high. Fragility - tendency of the software to break in many places every time it is changed: You change something somewhere, and it breaks the software in unexpected areas that are entirely unrelated to the change you made.

D in SOLID?

Dependency Inversion Principle

What should you ask yourself if you wanna know if you code is not bad?

Does the code have adequate safe guards against invalid data? Is the code readable by a human? Is it maintainable? Can the code be easily extended when needs change? Is this code secure? Does the code do too much? Should I break it down into smaller pieces?

What is FURPS+?

FURPS is an acronym representing a model for classifying software quality attributes (functional and non-functional requirements)

The four inherent properties (Frederick P. Brooks, Jr.)

Invisibility: Software is invisible and unvisualisable. Changeability: It is pure thought stuff - infinitely malleable. All successful software gets changed. New requirements by users. Conformity: Software must conform to other software through many different interfaces: there are no underlying principles that binds these interfaces together in a uniform matter. Complexity: Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). A program has a great number of states.

What is CRIVF?

It is the 5 symptoms of bad software / code

L in SOLID?

Liskov Substitution Principle

The four activities withing software engineering

Modeling activity Problem-solving activity Knowledge acquisition activity Rationale-driven activity.

O in SOLID?

Open/Closed Principle

S in SOLID?

Single Responsibility Principle

What is Software engineering?

Software engineering is an engineering discipline that is concerned with all aspects of software production. Software engineers should adopt a systematic approach to their work and use appropriate tools, techniques and methodologies depending on the problem to be solved, the development constraints, and the resources available.

The Activities common to all software processes

Specification / Requirements engineering Design and implementation Validation / Testing Evolution / Maintenance

What is Liskov Substitution Principle?

The parent class should be able to refer child objects seamlessly during runtime polymorphism or Children should generally behave like their parents Derived classes should be usable through the base class interface, without the need for the user to know the difference Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. (See polymorphism). By commiting to this principle you also adhere to the Open / close principle. If an object of type S can be substituted in all the places where an object of type T is expected, then S is a subtype of T.

No silver bullet (Frederick P. Brooks, Jr.)

There exist (and it is very unlikely that there will be any) no single solution in software engineering that can solve the inherent complexities of developing software, no single solution to increase the productivity manyfold.

Post-conditions (Liskov Substitution Principle)

They are the things that must be true after the method is complete. The method tells clients "this is what I promise to do for you". Invariants are the things that are always true and won't change. The method tells clients "if this was true before you called me, I promise it'll still be true when I'm done".

Pre-conditions (Liskov Substitution Principle)

They are the things that must be true before a method is called. The method tells clients "this is what I expect from you".

What is the purpose of the Interface Segregation Principle?

To reduce the side effects and frequency of required changes by splitting the software into multiple, independent parts. It's tempting to add a new method to an existing interface even though it implements a different responsibility and would be better separated in a new interface. → interface pollution, → bloated interfaces that contain methods implementing several responsibilities.