Software Engineering

  1. Cohesion
    Cohesion is a measure of how strongly-related the functionality expressed by the source code of a software module is.

    Modules with High Cohesion Low Coupling is perfered
  2. Inversion of Control (IoC)
    • Inversion of Control, or IoC, is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is
    • inverted in comparison to procedural programming.

    • Benefits:
    • 1. Removes dependencies from code
    • 2. Isolates Code --makes unit testing smoother.

    • Example:
    • http://joelabrahamsson.com/entry/inversion-of-control-introduction-with-examples-in-dotnet
  3. What is Single Responsibility Principle and why is it important
    Single Responsibility Principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.

    responsibility is defined as a reason to change, and concludes that a class or module should have one, and only one, reason to change.

    • As an example, consider a module that compiles and prints a report.
    • Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These
    • two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.

    The reason Single Responsibility Principle is important to keep a class focused on a single concern is that it makes the class more robust.
  4. Dependency Injection Pattern
    • Dependency Injection Pattern form of Inversion of COntrol.
    • Architecture links the components rather than the components linking themselves. Another words giving objects its instance variables.

    • Basic idea of Dependency Injection Pattern is you should isolate the implementation of an object from the construction of objects on
    • which it depends

    • Ex:
    • 1) Constructor Injection - pass in the variable into constructor (usually an Interface)
    • 2) Setter Injection - use properies to inject dependenies
    • 3) Interface-based injection- Use Common interface to inject dependecy. Such as another object such as a Service Locator. Service locator is an object that knows how to get hold of tghe services the application might need.
    • Benfits: Loosely coupled, reusable, testable object in software design. Add flexibility to codebasse for future changes. Removes dependencies that obstruct reuse in code.

    Drawback: Could become troublsome if there are too many instances and many dependencies need to be addressed
  5. Factory Method Pattern
    Define an interface for creating an object, but let sublasses decide which class to instantiate. Factory Method lets a class defer instantiation to the subclass

    Creation Pattern.

    • Pros:
    • 1) introduces loose coupling instead of tight coupling in the applicatioin
    • 2) It provides customization hooks. When the objects are created directly inside the class it's hard to replace them by objects which extend their functionality. If a factory is used instead to create a family of
    • objects the customized objects can easily replace the original objects, configuring the factory to create them

    • Cons:
    • 1) Refactoring existing code to use factories break existing clients.
    • 2)since the pattern relies on using a private constructor, the class
    • cannot be extended. Any subclass must invoke the inherited constructor,
    • but this cannot be done if that constructor is private
    • 3)do extend the class (e.g., by making the constructor protected—this is
    • risky but feasible), the subclass must provide its own re-implementation
    • of all factory methods with exactly the same signatures. For example,
    • if class StrangeComplex extends Complex, then unless StrangeComplex
    • provides its own version of all factory methods, the call
    • StrangeComplex.fromPolar(1, pi) will yield an instance of Complex (the superclass) rather than the expected instance of the subclass.
Author
Tbernstein
ID
69941
Card Set
Software Engineering
Description
Software Engineering terms
Updated