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.
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
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.
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
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
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
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.