Single Responsibility Principle
The name of
the principle says it all:
"One class should have
one and only one responsibility"
In other
words, you should write, change and maintain a class for only one purpose. If
it is model class then it should strictly represent only one actor/ entity.
This will give you the flexibility to make changes in future without worrying
the impacts of changes for another entity.
Similarly, If
you are writing service/manager class then it should contain only that part of
method calls and nothing else. Not even utility global functions related to
module. Better separate them in another globally accessible class file. This
will help in maintaining the class for that particular purpose, and you can
decide the visibility of class to specific module only.
Open Closed Principle
This is second important rule
which you should keep in mind while designing your application. It says:
"Software components should be open for extension, but closed for modification"
What does it mean?? It means
that your classes should be designed such a way that whenever fellow developer’s
wants to change the flow of control in specific conditions in application, all
they need to extend your class and overrides some functions and that’s it.
If other developers are not able
to design desired behavior due to constraints put by your class, then you
should reconsider changing your class. I do not mean here that anybody can
change the whole logic of your class, but he/she should be able to override the
options provided by software in unharmful way permitted by software.
For example, if you take a look
into any good framework like struts or spring, you will see that you cannot
change their core logic and request processing, BUT you modify the desired
application flow just by extending some classes and plugin them in
configuration files.
A great example of this in
real life is sitting in your pocket in the form of a smartphone. All such
phones have app stores and these app stores let you extend the base
functionality of the phone. Sure, it ships with the basics: camera operation,
actual calls, text messages, etc. But via the app store, you can extend the
phone's capabilities to allow you to manage your to-do list, play inane video
games, and even serve as a flashlight or wireless access point.
The mechanism that allows you to do this
is purely one of extension, however. It's not as though Apple, Google, and
Microsoft put the OS source code up on GitHub and invite you to dive in and
start building games and flashlight functionality. Rather, they make the core
phone functionality closed for modification and
they open
it to an extension.
Benefit or Open Closed
Design Principle:
1) Application will be more robust because we are not changing
already tested class.
2) Flexible because we can easily accommodate new requirements.
3) Easy to test and less error prone.
Liskov’s
Substitution Principle
It says:
"Derived types must be completely substitutable for their base types"
It means that the classes fellow
developer created by extending your class should be able to fit in application
without failure. I.e. if a fellow developer poorly extended some part of your
class and injected into framework/ application then it should not break the
application or should not throw fatal exceptions.
This can be insured by using
strictly following first rule. If your base class is doing one thing strictly,
the fellow developer will override only one feature incorrectly in worst case.
This can cause some errors in one area, but whole application will not do down.
The LSP says, basically, that
any child type of a parent type should be able to stand in for that parent
without things blowing up.
In other
words, if you have a class, Animal, with a MakeNoise() method, then any
subclass of Animal should reasonably implement MakeNoise(). Cats should meow,
dogs should bark, etc. What you wouldn't do is define a MuteMouse class that
throws IDontActuallyMakeNoiseException. This violates the LSP, and the argument
would be that this class has no business inheriting from Animal.
I is for Interface Segregation Principle
The Interface Segregation
Principle (ISP) says that you should favor many, smaller, client-specific
interfaces over one larger, more monolithic interface. In short, you don't want
to force clients to depend on things they don't actually need. Imagine your
code consuming some big, fat interface and having to re-compile/deploy with
annoying frequency because some method you don't even care about got a new
signature.
Clients should not be forced to implement unnecessary methods which they will not use"
Take an example. Developer Alex
created an interface
Reportable and added two methods generateExcel() and generatedPdf(). Now client ‘A’ wants to use this interface but he
intend to use reports only in PDF format and not in excel. Will he achieve the
functionality easily.
NO. He will have to implement
two methods, out of which one is extra burden put on him by designer of
software. Either he will implement another method or leave it blank. So are not
desired cases, right??
So what is the solution?
Solution is to create two interfaces by breaking the existing one. They should
be like
PdfReportable and ExcelReportable. This will give the flexibility to user to use only
required functionality only.
D is for
Dependency Inversion
The
Dependency Inversion Principle (DIP) encourages you to write code that depends
upon abstractions rather than upon concrete details. You can recognize this in
the code you read by looking for a class or method that takes something generic
like "Stream" and performs operations on it, as opposed to
instantiating a specific Filestream or Stringstream or whatever. This gives the
code in question a lot more flexibility -- you can swap in anything that
conforms to the Stream abstraction and it will still work.
To
visualize this in your day to day, go down to your local store and pay for
something with a credit card. The clerk doesn't examine your card and get out
the "Visa Machine" after seeing that your card is a Visa. He just
takes your card, whatever it is, and swipes it. Both you and the clerk depend
on the credit card abstraction without worrying about specifics.
References
https://team-coder.com/solid-principles/
http://blog.gauffin.org/2012/05/solid-principles-with-real-world-examples/
No comments:
Post a Comment