The Object-Oriented Design Principles are the core of OOP programming, but I have seen most of the Java programmers chasing design patterns like Singleton pattern, Decorator pattern, or Observer pattern, and not putting enough attention on learning Object-oriented analysis and design. It's essential to learn the basics of Object-oriented programming like Abstraction, Encapsulation, Polymorphism, and Inheritance. But, at the same time, it's equally important to know object-oriented design principles. They will help you to create a clean and modular design, which would be easy to test, debug, and maintain in the future.
I have regularly seen Java programmers and developers of various experience level, who have either never heard about these OOP and SOLID design principle, or simply doesn't know what benefits a particular design principle offers and how to apply these design principle in coding.
I have regularly seen Java programmers and developers of various experience level, who have either never heard about these OOP and SOLID design principle, or simply doesn't know what benefits a particular design principle offers and how to apply these design principle in coding.
To do my part, I have jotted down all important object-oriented design principles and putting them here for quick reference. These will at least give you some idea about what they are and what benefits they offer.
I have not put examples, just to keep the article short, but you can find a lot of examples of these design principles in my blog; just use the search bar at the top of the page.
If you are not able to understand a design principle, you should try to do more than one example because sometimes we connect to another example or author better, but you must understand these design principles and learn how to use it in your code.
Another thing you can do is to join a comprehensive object-oriented design course like SOLID Principles of Object-Oriented Design by Steve Smith on Pluralsight. It has helped me a lot in my understanding and application of these principles.
I personally think each of these OOP and SOLID design principle needs an article to explain them clearly, and I will definitely try to do that here, but for now, just get yourself ready for a quick bike ride on design principle town :)
I have not put examples, just to keep the article short, but you can find a lot of examples of these design principles in my blog; just use the search bar at the top of the page.
If you are not able to understand a design principle, you should try to do more than one example because sometimes we connect to another example or author better, but you must understand these design principles and learn how to use it in your code.
Another thing you can do is to join a comprehensive object-oriented design course like SOLID Principles of Object-Oriented Design by Steve Smith on Pluralsight. It has helped me a lot in my understanding and application of these principles.
10 Object-Oriented and SOLID Desing Principles for Programmers
Though the best way of learning any design principle or pattern is a real-world example and understanding the consequences of violating that design principle, the subject of this article is Introducing Object-oriented design principles for Java Programmers, who are either not exposed to it or in the learning phase.
I personally think each of these OOP and SOLID design principle needs an article to explain them clearly, and I will definitely try to do that here, but for now, just get yourself ready for a quick bike ride on design principle town :)
1. DRY (Don't repeat yourself)
Our first object-oriented design principle is DRY, as the name suggests DRY (don't repeat yourself) means don't write duplicate code, instead use Abstraction to abstract common things in one place. If you have a block of code in more than two places, consider making it a separate method, or if you use a hard-coded value more than one time, make them public final constant.
The benefit of this Object-oriented design principle is in maintenance. It's important not to abuse it, duplication is not for code, but for functionality. It means if you used standard code to validate OrderID and SSN, it doesn’t mean they are the same, or they will remain the same in the future.
By using standard code for two different functionality or thing, you tightly couple them forever, and when your OrderId changes its format, your SSN validation code will break.
So beware of such coupling and just don’t combine anything which uses similar code but is not related. You can further check out Basics of Software Architecture & Design Patterns in Java course on Udemy to learn more about writing the right code and best practices to follow while designing a system.
The benefit of this Object-oriented design principle is in maintenance. It's important not to abuse it, duplication is not for code, but for functionality. It means if you used standard code to validate OrderID and SSN, it doesn’t mean they are the same, or they will remain the same in the future.
By using standard code for two different functionality or thing, you tightly couple them forever, and when your OrderId changes its format, your SSN validation code will break.
So beware of such coupling and just don’t combine anything which uses similar code but is not related. You can further check out Basics of Software Architecture & Design Patterns in Java course on Udemy to learn more about writing the right code and best practices to follow while designing a system.
2. Encapsulate What Changes
Only one thing is constant in the software field, and that is "Change," So encapsulate the code you expect or suspect to be changed in the future. The benefit of this OOP Design principle is that It's easy to test and maintain proper encapsulated code.
If you are coding in Java, then follow the principle of making variable and methods private by default and increasing access step by step, e.g. from private to protected and not public.
Several of the design patterns in Java uses Encapsulation, the Factory design pattern is one example of Encapsulation which encapsulates object creation code and provides flexibility to introduce a new product later with no impact on existing code.
Btw, if you are interested in learning more about design patterns in Java and Object-Oriented Programming, then you must check this Design Pattern Library course Pluralsight. It's one of the best collections of design patterns and advice on how to use them in the real world.
If you are coding in Java, then follow the principle of making variable and methods private by default and increasing access step by step, e.g. from private to protected and not public.
Several of the design patterns in Java uses Encapsulation, the Factory design pattern is one example of Encapsulation which encapsulates object creation code and provides flexibility to introduce a new product later with no impact on existing code.
Btw, if you are interested in learning more about design patterns in Java and Object-Oriented Programming, then you must check this Design Pattern Library course Pluralsight. It's one of the best collections of design patterns and advice on how to use them in the real world.
3. Open Closed Design Principle
Classes, methods, or functions should be Open for extension (new functionality) and Closed for modification. This is another beautiful SOLID design principle, which prevents someone from changing already tried and tested code.
Ideally, if you are adding new functionality only, then your code should be tested, and that's the goal of the Open Closed Design principle. By the way, the Open-Closed principle is "O" from the SOLID acronym.
Ideally, if you are adding new functionality only, then your code should be tested, and that's the goal of the Open Closed Design principle. By the way, the Open-Closed principle is "O" from the SOLID acronym.
4. Single Responsibility Principle (SRP)
Single Responsibility Principle is another SOLID design principle, and represent "S" on the SOLID acronym. As per SRP, there should not be more than one reason for a class to change, or a class should always handle single functionality.
If you put more than one functionality in one Class in Java, it introduces coupling between two functionality, and even if you change one feature, there is a chance you broke coupled functionality, which requires another round of testing to avoid any surprise on the production environment.
You can further see From 0 to 1: Design Patterns - 24 That Matter course on Udemy to learn about patterns that are based on this principle.
If you put more than one functionality in one Class in Java, it introduces coupling between two functionality, and even if you change one feature, there is a chance you broke coupled functionality, which requires another round of testing to avoid any surprise on the production environment.
You can further see From 0 to 1: Design Patterns - 24 That Matter course on Udemy to learn about patterns that are based on this principle.
5. Dependency Injection or Inversion principle
Don't ask for dependency; it will be provided to you by the framework. This has been very well implemented in Spring framework, the beauty of this design principle is that any class which is injected by DI framework is easy to test with the mock object and more comfortable to maintain because object creation code is centralized in the framework and client code is not littered with that.
There are multiple ways to implemented Dependency injection like using bytecode instrumentation, which some AOP (Aspect Oriented Programming) framework like AspectJ does or by using proxies just like used in Spring. See this example of the IOC and DI design pattern to learn more about this SOLID design principle. It represents "D" on the SOLID acronym.
There are multiple ways to implemented Dependency injection like using bytecode instrumentation, which some AOP (Aspect Oriented Programming) framework like AspectJ does or by using proxies just like used in Spring. See this example of the IOC and DI design pattern to learn more about this SOLID design principle. It represents "D" on the SOLID acronym.
6. Favor Composition over Inheritance
Always favor composition over inheritance, if possible. Some of you may argue this, but I found that Composition is the lot more flexible than Inheritance.
Composition allows changing the behavior of a class at run-time by setting property during run-time, and by using Interfaces to compose a class, we use polymorphism, which provides flexibility to replace with better implementation at any time.
Even Effective Java advise favoring composition over inheritance. See here to learn more about why your Composition is better than Inheritance for reusing code and functionality.
Composition allows changing the behavior of a class at run-time by setting property during run-time, and by using Interfaces to compose a class, we use polymorphism, which provides flexibility to replace with better implementation at any time.
Even Effective Java advise favoring composition over inheritance. See here to learn more about why your Composition is better than Inheritance for reusing code and functionality.
7. Liskov Substitution Principle (LSP)
According to the Liskov Substitution Principle, Subtypes must be substitutable for supertype, i.e. methods or functions which use superclass type must be able to work with the object of subclass without any issue".
LSP is closely related to the Single responsibility principle and Interface Segregation Principle. If a class has more functionality, than the subclass might not support some of the functionality and does violate LSP.
In order to follow LSP SOLID design principle, derived class or subclass must enhance functionality, but not reduce them. LSP represents "L" on the SOLID acronym. If you are interested in a more real-world example, then the SOLID Principles of Object-Oriented Design course on Pluarlsight is an excellent course to start with.
LSP is closely related to the Single responsibility principle and Interface Segregation Principle. If a class has more functionality, than the subclass might not support some of the functionality and does violate LSP.
In order to follow LSP SOLID design principle, derived class or subclass must enhance functionality, but not reduce them. LSP represents "L" on the SOLID acronym. If you are interested in a more real-world example, then the SOLID Principles of Object-Oriented Design course on Pluarlsight is an excellent course to start with.
Btw, you would need a Pluralsight membership to get access to this course, which costs around $29 per month or $299 annually (14% discount).
If you don't have Pluralsight membership, I encourage you to get one because it allows you to access their 5000+ online courses on all the latest topics like front-end and back-end development, machine learning, etc. It also includes interactive quizzes, exercises, and the most recent certification material.
It's more like Netflix for Software Developers, and Since learning is an integral part of our job, Plurlasight membership is a great way to stay ahead of your competition.
They also provide a 10-day free trial without any commitment, which is a great way to not just access this course for free but also to check the quality of courses before joining Pluralsight.
8. Interface Segregation Principle (ISP)
Interface Segregation Principle stats that a client should not implement an interface if it doesn't use that. This happens mostly when one interface contains more than one functionality, and the client only needs one functionality and no other.
Interface design is a tricky job because once you release your interface, you can not change it without breaking all implementation.
Another benefit of this design principle in Java is, the interface has the disadvantage of implementing all methods before any class can use it, so having single functionality means less method to implement. If you don't get the benefit of the interface in coding, then I suggest you read my blog post, the real usage of an interface in Java to learn more.
Interface design is a tricky job because once you release your interface, you can not change it without breaking all implementation.
Another benefit of this design principle in Java is, the interface has the disadvantage of implementing all methods before any class can use it, so having single functionality means less method to implement. If you don't get the benefit of the interface in coding, then I suggest you read my blog post, the real usage of an interface in Java to learn more.
9. Programming for Interface not implementation
Always program for the interface and not for application; this will lead to flexible code that can work with any new implementation of the interface.
So use interface type on variables, return types of method or argument type of methods in Java.
This has been advised in many Java books, including in Effective Java and Head First design pattern book.
So use interface type on variables, return types of method or argument type of methods in Java.
This has been advised in many Java books, including in Effective Java and Head First design pattern book.
10. Delegation principles
Don't do all stuff by yourself, delegate it to the respective class. Classical example of delegation design principle is equals() and hashCode() method in Java. In order to compare two objects for equality, we ask the class itself to make comparison instead of the Client class doing that check.
The key benefit of this design principle is no duplication of code and pretty easy to modify behavior. Event delegation is another example of this principle, where an event is delegated to handlers for handling.
The key benefit of this design principle is no duplication of code and pretty easy to modify behavior. Event delegation is another example of this principle, where an event is delegated to handlers for handling.
RFJ3RN
0 comments :
Post a Comment