Software Design Principles

[MUSIC] 0:00 Now that we have Hibernate up and running in our application, 0:04 we could certainly continue down this path and finish the app so 0:08 that all functionality is present from the perspective of the user. 0:11 We could autowire a SessionFactory into the GIF controller as well, and for both 0:15 controllers implement all of the Hibernate operations in the controller classes. 0:20 But there would still be some glaring problems with that. 0:24 What if we wanted to use unit test to test just the controller or 0:29 just the Hibernate functionality? 0:34 This would be impossible since those two components are now woven together in our 0:36 source code, which is also known as being tightly coupled. 0:41 Or what if we wanted to provide the same Hibernate functionality to a Giflib API 0:44 that we're writing which helps power a native Android or iOS app? 0:50 Right now, all that functionality is woven together with our web app functionality, 0:54 which is written specifically to serve HTML. 0:59 Again, too tightly coupled. 1:02 Another practical concern is the idea of another developer joining our team 1:04 to fine-tune Hibernate so 1:09 that its queries are efficient and our application is speedy. 1:10 Unfortunately that developer is going to have to sift through 1:14 all of our web-specific code in the controllers. 1:18 The considerations we're making now have to do with software design, 1:22 which we'll refer to here as the organization of our application in 1:25 the placement of code into classes, the placement of classes into packages, and 1:29 the relationships among all our classes. 1:34 While developing applications, we want to maximize the following, 1:38 maintainability, extensibility, reusability, and testability. 1:43 Out of these needs arise the principles of first, the separation of concerns, 1:47 where each layer, which could be a package or jar file, performs specific duties. 1:53 For example, the controller layer intercepts and routes URI requests. 1:59 And a data access layer interacts with our database via Hibernate. 2:04 Next is the single responsibility principle, 2:08 where each class addresses a single concern. 2:11 For example, the CategoryController intercepts URI requests to 2:15 resources related to categories, makes simple calls to fetch or alter data, 2:19 then serves the appropriate HTML template or routes the request to another URI. 2:24 Currently we're violating this in our application, 2:30 where the CategoryController handles URI requests and interacts with Hibernate. 2:32 Think of the single responsibility principle like the separation of concerns 2:38 within application layers. 2:42 Finally we have the principle of loose coupling, 2:44 which means that each object can act with little knowledge of other objects. 2:48 For example, we use interfaces to generalize functionality and 2:52 define fields with interfaces. 2:57 The implementation is provided or injected elsewhere. 2:59 We saw this in our definition of a data source. 3:04 As far as Spring is concerned, we have only leverage the java.sql.DataSource 3:06 interface even though the actual object returned by that method 3:11 will be a BasicDataSource provided by the Apache DBCP library. 3:15 In this case, Spring acts with no knowledge of its implementation, but 3:21 only expects the implementation to have implemented java.sql.DataSource. 3:26 If you haven't seen these principles yet, 3:33 expect to see them come up often as you gain more development experience. 3:35 These are principles that every software team is interested in implementing. 3:40 So building a strong foundation of knowledge in them and 3:43 having the practice to back that up with is going to be a great asset for you. 3:47 Next, we'll look at how these principles will apply to our Spring web apps. 3:52