In this post I'm going to share two programming styles - one I switched to when I boarded the TDD train and the other one is I'm following currently.
I will write a small application using both styles. The job of this sample application is to parse the meetings from CSV format file and schedule them in a calendar.
Note: Code for this blog post is available at github.
POOP (Procedural OOP) - I switched to this style when I learned about automated unit testing (TDD) and frankly speaking I misunderstood TDD. While following this style I used to create interfaces for every class and inject them where ever they were needed and majority of interfaces or classes have just one public method. To my surprise I was not alone to follow this style and I will partly blame it on how the information about TDD was disseminated on internet. Following code shows how I will solve above problem using POOP style:
Please go to github to see unit tests. I have left them out to keep the post short. Some observations in above code-
OOP Style- This style is nothing new but is what I used to follow (minus some good practices; mostly recent ones) before I started practising TDD in my own style :). In this style I will solve the same problem as shown below:
I encourage you to look at the test, which I have excluded to keep the post focused. If you look at above code, you can observe that
I will write a small application using both styles. The job of this sample application is to parse the meetings from CSV format file and schedule them in a calendar.
Note: Code for this blog post is available at github.
POOP (Procedural OOP) - I switched to this style when I learned about automated unit testing (TDD) and frankly speaking I misunderstood TDD. While following this style I used to create interfaces for every class and inject them where ever they were needed and majority of interfaces or classes have just one public method. To my surprise I was not alone to follow this style and I will partly blame it on how the information about TDD was disseminated on internet. Following code shows how I will solve above problem using POOP style:
Please go to github to see unit tests. I have left them out to keep the post short. Some observations in above code-
- It does not seem OOP but POOP (Procedural Object Oriented Programming). Loads of procedures are scattered in different classes and behind interfaces.
- Loads of interfaces, which means loads of mocking/stubbing in tests.
- Does not promote cohesion. In future if I need to save the meeting information to CSV file, I will end writing other class- CsvMeetingSaver (something like that)
- Very little brain power is needed in identifying the classes/interfaces. Rule to name a class is- think of a functionality and suffixed it with 'er', class and interface will be ready in no time.
- Does not promote usage of any design pattern
- Promotes the design where classes are accepting large number dependencies in their constructors and the reason is that you have to bring all scattered functionalities together to implement a complete behaviour.
- ....
OOP Style- This style is nothing new but is what I used to follow (minus some good practices; mostly recent ones) before I started practising TDD in my own style :). In this style I will solve the same problem as shown below:
I encourage you to look at the test, which I have excluded to keep the post focused. If you look at above code, you can observe that
- Interfaces are sparingly created which means less mocking/stubbing in test code
- Tests are more behavioural and shielded from implementation of target class
- Cohesive, things which should be closer, are put together in a class
- Less code and less test
- Good encapsulation
- Need more brain power to identify the classes.
Gurmit seems god gifted with OOP knowledge and I can't still forget some of the best use of polymorphism I learned via his session almost a decade back in 2006.
ReplyDelete