![]() ![]() And to achieve that, start by making sure that your models do only what they are meant to do, and don’t concern themselves with what the app built around it does. Even for complicated applications, good model implementation can result in extremely expressive code. If you have models separated from the rest of your application logic, maintenance will be much easier, regardless of how complicated your application becomes. But readers following these examples realize, only after years, how counterproductive it is to have monolithic chunks of code in their project. They are not meant to teach software design. Examples like “let’s say we have this ORM X for our models, templating engine Y for our views and we will have controllers to manage it all” achieve nothing other than humongous controllers.Īlthough in defense of these books, the examples are meant to demonstrate the ease at which you can get started with their framework. ![]() But they also end up providing bad advice for beginners. These examples try to show what the framework has to offer. Model Is EverythingĪlmost every book about some new MVC (MVP, MVVM, or other M**) framework is littered with examples of bad code. Writing great code is an art, but some principles can always help give your development work the direction it needs to head towards to produce robust and maintainable software. ![]() Reusability - Because the code is not modular, code reuse is affected.īased on the previous example, the OrderProcessor now becomes an orchestrator, and its responsibilities Validate(), Save(), Notify() are split into their own classes.In this article, I will discuss how the Single Responsibility Principle and some techniques that revolve around it can give your code this very quality.Testability - It becomes more difficult to test the implementation.Coupling - Because of too many responsibilities, we have too many dependencies, leaving OrderProcessor in a fragile state in case changes are needed.No cohesion - There are different things in the same context of OrderProcessor.Problems we can identify with this implementation: Looking at the implementation above we can see the implementation of many responsibilities: Validate(), Save(), Notify(). Code is testable - because classes are specific and small, code can be thoroughly tested.Ī classic example of how to violate the Single Responsibility Principle:.Code is changed less frequently - in general, when requirements change, not every part of the application is going to change because the classes are more specific. ![]()
0 Comments
Leave a Reply. |