![]() This allows us to share multiple properties among the DataModels and eliminate redundancy. For instance, models like Videos or PDFs are subtypes of Content and can be substituted seamlessly in the code. ![]() Multiple reasons for change indicate more tightly-coupled designs that are more rigid and harder to maintain. The SRP dictates that classes should have only a single reason to change. We strictly follow the Open Closed Principle and its extension Liskov's Substitution Principle throughout our DataModels. The Single Responsibility Principle (SRP) is one of five design principles of the SOLID design framework for object-oriented software design. Liskov's Substitution Principle (Liskov, 1994) For a deeper dive into our multi-threading strategy, see implementation section for more details. We find this principle particularly useful as we can maintain a same set of multi-threading strategy and Queue throughout the code base. Refreshing can be done easily with passing lambda or Closures to the extension without any other code needed. As an example, we abstracted the reloading and refreshing logic out of all ViewControllers and put them into an Extension named refresher(). We have made substantial effort to separate responsibility among multiple modules in our application. Single Responsibility Principle (DeMarco, 1979) This gives us confidence when working on our code and helps us to work together as a team with multiple development branches on the same code base. In other words, modifications to views would in no way break our API, and similarly otherwise. We can group sections of similar actions on DataModels together in the MainController, and ensure there is little to no coupling among these three parts. In fact, the best way to detect a dependency is to see if : new keyword is used static methods are used, which may be accessing any other resource (e.g. This violates the single responsibility principle. Our team adopted the MVC architecture mainly because of its high cohesion and low coupling. Also, Circle class has an additional responsibility of instantiating printer objects. Meanwhile, daemon Refresher workers keep track of the Model changes and update them with the X5Learn backend when suitable. With the main logic implemented in the MainController, it dispatch changes to relevant Models, which will then be reflected in Views eventually. User interactions are captured through GestureRecognisers and Actions in various ViewControllers and then delegate to the MainController. Models include UserModel, ChannelModel, VideoModel, WikiModel and many others,Įach holding information and buffered data from X5GON Backend.ĭata updates are made from ViewControllers to Views. Generally speaking, this architecture adopts the classic Model-View-Controller (MVC) pattern (Reenskaug and Coplien, 2009). This section introduces the design of the mobile application.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |