![[Development Simply Put] How To Reconstruct String Sections From Concatenated...](https://cdn.slidesharecdn.com/ss_thumbnails/developmentsimplyputhowtoreconstructstringsectionsfromconcatenatedstringformat-130803161707-phpapp01-thumbnail.jpg?width=560&fit=bounds)
More Related Content
Similar to Intro To Software Architecture (20)
Recently uploaded (20)
Intro To Software Architecture
- 2. “I hear and I forget. I see and I remember. I do and I understand.” - Confucius
- 3. The Big 3 Follow these three simple rules for clean code.
- 4. Stay DRY Don’t Repeat Yourself
- 6. Keep It Super Simple Complexity is expensive. Less complexity = less bugs. Less complexity = easier to read and understand. Do the simplest thing that could possibly wor
- 7. YAGNI Trust in your ability to solve problems as they arise. Don't build something now that you _might_ need in the future. If you don't need it now, or it's not in the requirements, do not build it.
- 8. Good Rules of Thumb - Keep your class, variable and method names verbose – avoid uncommon abbreviations - Always think: “What am I actually doing?” – design your API the way you would want to use it. Tell your app to do something, don’t ask. - Keep flow paths to a minimum: remove unnecessary else statements whenever possible - Reduce complexity by keeping your indentations to one level ideally – forces you to extract behavior into more modular code
- 10. S: Single Responsibility Separation of concerns - Routing - Validation - Filtering - Logging - Formatting - Mapping - Notifications - Parsing - Object Creation - Rendering - Querying
- 12. O: Open/Close Principle Don’t add a basement to a finished house.
- 13. L: Liskov Substitution Principle In other words: Design To An Interface. Whopper and BigMac both implement the HamburgerInterface
- 14. I: Interface Segregation Principle Keep your interfaces small. By following this principle, you will implicitly follow the Open/Closed Principle, win-win Classes that implement interfaces should not be forced to implement methods that they do not use. Violation of this principle is a red flag that your interface is too big and should be broken down into smaller interfaces
- 15. D: Dependency Inversion Principle Communication between high level and low-level classes should be done through abstraction. In other words, reference interfaces and not concrete classes - File System - Database - 3rd Party Libraries - Mailing - Web Services - Configuration
- 18. Pattern Recognition Learning different frameworks helps you recognize common architecture patterns and which ideas consistently emerge as best practices.
- 19. Most problems can be solved with another layer of abstraction.
Editor's Notes
- #3: Remember that there is no easy path to experience. The best way to learn to develop is to simply develop, and to use best practices whenever possible. Learn from the mistakes of others. They are best practices for a reason. :) I've found that theory at night and practice during the day (or vice versa) is a good mix for keeping up with theory while putting it into practice.
- #4: If you ever copy a block of code and paste it somewhere else, sirens and alarms should sound. That could should be encapsulated for reuse.
- #5: If you ever copy a block of code and paste it somewhere else, sirens and alarms should sound. That could should be encapsulated for reuse.
- #6: If you ever copy a block of code and paste it somewhere else, sirens and alarms should sound. That could should be encapsulated for reuse.
- #7: If you ever copy a block of code and paste it somewhere else, sirens and alarms should sound. That could should be encapsulated for reuse.
- #8: Make code easy to change. Don’t try to anticipate _the way_ it will change. Avoid premature optimization. Any new feature has the cost of development time, testing time, support time, and maintenance time. Time spent on the feature is possibly lost completely if the feature is never needed or used. Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work correctly, even if it eventually is needed.
- #10: If you ever copy a block of code and paste it somewhere else, sirens and alarms should sound. That could should be encapsulated for reuse.
- #11: A class should have only one reason to be changed, one responsibility. Large methods and large classes are harder to read, comprehend, and reuse. Avoid The Blob anti-pattern – when you see methods or classes with more than one responsibility, refactor for clarification.
- #15: When to interface? As a rule of thumb, if there is a realistic chance you may switch implementation strategies, build an interface. For example, you may have
- #16: If you find yourself using the 'new' keyword to create objects outside of a factory method (whose single responsibility is to create new objects), you are violating this principle. Avoid the new keyword like the plague.
- #17: If you find yourself using the 'new' keyword to create objects outside of a factory method (whose single responsibility is to create new objects), you are violating this principle. Avoid the new keyword like the plague.
- #18: If you find yourself using the 'new' keyword to create objects outside of a factory method (whose single responsibility is to create new objects), you are violating this principle. Avoid the new keyword like the plague.
- #19: If you find yourself using the 'new' keyword to create objects outside of a factory method (whose single responsibility is to create new objects), you are violating this principle. Avoid the new keyword like the plague.