The document discusses principles for writing solid code, including the single responsibility principle, open-closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle. It emphasizes writing code that is human readable, maintainable, extensible, scalable, granular, and reusable. The principles of KISS (Keep It Simple Stupid), DRY (Don't Repeat Yourself), and YAGNI (You Aren't Gonna Need It) are also mentioned for writing clean code.
This document provides an overview of the SOLID principles of object-oriented design:
1. The Single Responsibility Principle states that a class should have one, and only one, reason to change. Having multiple responsibilities makes classes more complex and brittle.
2. The Open-Closed Principle states that software entities should be open for extension but closed for modification. New functionality should be added by extending existing classes rather than modifying them.
3. The Liskov Substitution Principle states that subclasses must be substitutable for their base classes. They should not break the expected behavior of the program.
4. The Interface Segregation Principle states that interfaces should be tailored to specific client needs
Becoming a better developer by using the SOLID design principlesKaterina Trajchevska
The document discusses the SOLID design principles for writing maintainable and extensible code. It defines each principle - Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. For each principle, it provides an explanation of what the principle means and how to apply it. It also warns that SOLID principles are guidelines, not rules, and to use common sense over rigidly following the principles. The overall goal of SOLID is to create code that is easy to maintain, extend and understand.
This document discusses the SOLID principles for clean code architecture. It explains each principle individually: single responsibility (a class should have one responsibility), open/closed (classes should be open for extension but closed for modification), Liskov substitution (functions using base classes must work with derived classes), interface segregation (split interfaces into smaller interfaces that are focused), and dependency inversion (high level modules shouldn't depend on low level modules). Following these principles helps produce code that is less fragile, more flexible, and easier to maintain and change over time.
Design principles are a matter of the utmost importance for the software development, but unfortunately by far not all developers are closely acquainted with them. In this presentation we cover the basics of the core design and development principles.
Design principles are a matter of the utmost importance for the software development, but unfortunately by far not all developers are closely acquainted with them. In this presentation we cover the basics of the core design and development principles.
SOLID is a mnemonic device for 5 design principles of object-oriented
programs (OOP) that result in readable, adaptable, and scalable code.
S - Single Responsibility Principle.
O - Open Closed Principle.
L - Liskov Substitution Principle.
I - Interface Segregation Principle.
D - Dependency Inversion Principle.
This document provides an overview of the SOLID principles of object-oriented design:
1. The Single Responsibility Principle states that a class should have one, and only one, reason to change. Having multiple responsibilities makes classes more complex and brittle.
2. The Open-Closed Principle states that software entities should be open for extension but closed for modification. New functionality should be added by extending existing classes rather than modifying them.
3. The Liskov Substitution Principle states that subclasses must be substitutable for their base classes. They should not break the expected behavior of the program.
4. The Interface Segregation Principle states that interfaces should be tailored to specific client needs
Becoming a better developer by using the SOLID design principlesKaterina Trajchevska
The document discusses the SOLID design principles for writing maintainable and extensible code. It defines each principle - Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. For each principle, it provides an explanation of what the principle means and how to apply it. It also warns that SOLID principles are guidelines, not rules, and to use common sense over rigidly following the principles. The overall goal of SOLID is to create code that is easy to maintain, extend and understand.
This document discusses the SOLID principles for clean code architecture. It explains each principle individually: single responsibility (a class should have one responsibility), open/closed (classes should be open for extension but closed for modification), Liskov substitution (functions using base classes must work with derived classes), interface segregation (split interfaces into smaller interfaces that are focused), and dependency inversion (high level modules shouldn't depend on low level modules). Following these principles helps produce code that is less fragile, more flexible, and easier to maintain and change over time.
Design principles are a matter of the utmost importance for the software development, but unfortunately by far not all developers are closely acquainted with them. In this presentation we cover the basics of the core design and development principles.
Design principles are a matter of the utmost importance for the software development, but unfortunately by far not all developers are closely acquainted with them. In this presentation we cover the basics of the core design and development principles.
SOLID is a mnemonic device for 5 design principles of object-oriented
programs (OOP) that result in readable, adaptable, and scalable code.
S - Single Responsibility Principle.
O - Open Closed Principle.
L - Liskov Substitution Principle.
I - Interface Segregation Principle.
D - Dependency Inversion Principle.
The document discusses the SOLID principles of object-oriented design, which are Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. It defines each principle, provides examples of how to apply it in code, and explains how following the principles can help create code that is loosely coupled, highly cohesive, reusable, and easily testable.
This document provides an overview of dependency injection and compares different dependency injection containers. It defines dependency injection as a technique where object couplings are bound at runtime by a container rather than at compile time. It describes different ways of implementing dependency injection, including constructor injection, property injection, and interface injection. The document also discusses benefits of dependency injection like loose coupling and increased testability. It then provides a performance comparison of various dependency injection containers and finds that DryIoc, LightInject, and SimpleInjector offer very good performance while supporting advanced features.
This document discusses test-driven development (TDD) using Rails, RSpec, and other tools. It notes benefits of TDD like creating solid, change-resilient code, self-testing software, and fewer bugs for customers. Principles like SOLID, dependency injection, and interface segregation are covered. Configuration files and commands for setting up RSpec for testing Rails applications are also listed.
PHP is undervalued in the world of web development. Yet, with the rise of PHP7, modern frameworks, and design principles, PHP has grown far beyond the basic scripting language it started as. In this presentation, we'll focus on what distinguishes a good PHP developer from a strong one. We'll learn how we can become better developers and make use of the SOLID design principles to deliver scalable and extendable solutions.
This document discusses the SOLID principles of good software design: Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. It explains the purpose of each principle, how to apply it, and why it is important for creating code that is loosely coupled, highly cohesive, and easy to evolve over time. Following these principles can help minimize design flaws and result in code that is simpler, more maintainable and easier to test.
This is a small recap of different SOLID principles.
The slides do not have much comments but if you follow the link, you will get all the examples and they are self explanatory.
Using the SOLID design principles to write code that's easier to understand, maintain and extend.
The slides from the SOLID speech at the CodeTalks 2018 in Hamburg.
Pavlo Zhdanov "Mastering solid and base principles for software design"LogeekNightUkraine
The document discusses SOLID principles and other principles of software design including single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion. It provides definitions and examples of each. The SOLID principles aim to create simple, modular, and understandable code by establishing best practices for class design. Additional design principles discussed ensure reusable, cohesive components with stable dependencies and abstractions.
Clean code is subjective and every developer has a personal take on it. There are some ideas that are considered best practice and what constitutes clean code within the industry and community, but there is no definitive distinction.
This document discusses the SOLID principles of object-oriented design. It introduces each principle - Single Responsibility Principle, Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. For each principle, it provides a brief definition and example to illustrate how to apply that principle to achieve high cohesion and loose coupling in software design. The overall message is that following SOLID principles can help software designs withstand changes over time by avoiding rigidity, fragility, immobility, and viscosity.
This document summarizes key principles for writing clean code as outlined in the book "Clean Code" by Robert C. Martin. It discusses ideas like writing code that is easy to read and understand through use of meaningful names, small functions that do one thing well, and avoiding duplication. It also covers principles for object-oriented design like encapsulation, organization for change, and separation of concerns. Testing philosophies like test-driven development and ensuring tests are fast, independent, repeatable, self-validating, and timely are also emphasized. The overall message is that writing clean code requires attention to structure, naming, formatting and testing to produce software that is simple, well-organized and a pleasure to maintain.
Learning solid principles using c#
S Single Responsibility Principle
O Open Closed Principle
L Liskovs Substitution Principle
I Interface Segregation Principle
D Dependency Inversion principle
Design Principle and Design Pattern examples on C# .NET Core.
(Note: Not all the contents are original, I copied some of them from online tutorials while learning and found great explanations. A great thanks to all for this information.)
The document discusses software design principles for managing complexity and change, including the Open-Closed Principle (OCP), Liskov Substitution Principle (LSP), Dependency Inversion Principle (DIP), and Interface Segregation Principle (ISP). These principles aim to create modules that are open for extension but closed for modification, with subclasses substitutable for their base classes. Dependencies should be on abstractions rather than concretions, and interfaces should be client-specific rather than general. Managing complexity means managing dependencies through high abstraction, single-responsibility classes, and other principles that promote designs that are clean, simple, and elegant.
This document discusses the SOLID principles of object-oriented design:
- The Single Responsibility Principle states that a class should have one, and only one, reason to change.
- The Open/Closed Principle specifies that software entities should be open for extension but closed for modification.
- The Liskov Substitution Principle dictates that subclasses should behave in the same way as their parent classes.
- The Interface Segregation Principle indicates that client classes should not depend on interfaces they do not use.
- The Dependency Inversion Principle asserts that high-level modules should not depend on low-level modules, but both should depend on abstractions.
The presentation provides examples of
This document discusses simplicity in software engineering. It provides quotes emphasizing the importance of simplicity from Steve Jobs and Edsger Dijkstra. It discusses factors like users, business needs, and financial constraints that influence simplicity. Programming languages that focus on simplicity tend to have lower bug density. Over-engineering can lead to unnecessary complexity, bugs, and difficulty maintaining code. Principles like KISS, YAGNI, DRY, and SOLID can help avoid over-engineering. Generalization techniques like macros, parameters, overloading, and libraries can increase simplicity if used properly but can also introduce unnecessary complexity.
Graspan: A Big Data System for Big Code AnalysisAftab Hussain
We built a disk-based parallel graph system, Graspan, that uses a novel edge-pair centric computation model to compute dynamic transitive closures on very large program graphs.
We implement context-sensitive pointer/alias and dataflow analyses on Graspan. An evaluation of these analyses on large codebases such as Linux shows that their Graspan implementations scale to millions of lines of code and are much simpler than their original implementations.
These analyses were used to augment the existing checkers; these augmented checkers found 132 new NULL pointer bugs and 1308 unnecessary NULL tests in Linux 4.4.0-rc5, PostgreSQL 8.3.9, and Apache httpd 2.2.18.
- Accepted in ASPLOS ‘17, Xi’an, China.
- Featured in the tutorial, Systemized Program Analyses: A Big Data Perspective on Static Analysis Scalability, ASPLOS ‘17.
- Invited for presentation at SoCal PLS ‘16.
- Invited for poster presentation at PLDI SRC ‘16.
The document discusses the SOLID principles of object-oriented design, which are Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. It defines each principle, provides examples of how to apply it in code, and explains how following the principles can help create code that is loosely coupled, highly cohesive, reusable, and easily testable.
This document provides an overview of dependency injection and compares different dependency injection containers. It defines dependency injection as a technique where object couplings are bound at runtime by a container rather than at compile time. It describes different ways of implementing dependency injection, including constructor injection, property injection, and interface injection. The document also discusses benefits of dependency injection like loose coupling and increased testability. It then provides a performance comparison of various dependency injection containers and finds that DryIoc, LightInject, and SimpleInjector offer very good performance while supporting advanced features.
This document discusses test-driven development (TDD) using Rails, RSpec, and other tools. It notes benefits of TDD like creating solid, change-resilient code, self-testing software, and fewer bugs for customers. Principles like SOLID, dependency injection, and interface segregation are covered. Configuration files and commands for setting up RSpec for testing Rails applications are also listed.
PHP is undervalued in the world of web development. Yet, with the rise of PHP7, modern frameworks, and design principles, PHP has grown far beyond the basic scripting language it started as. In this presentation, we'll focus on what distinguishes a good PHP developer from a strong one. We'll learn how we can become better developers and make use of the SOLID design principles to deliver scalable and extendable solutions.
This document discusses the SOLID principles of good software design: Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. It explains the purpose of each principle, how to apply it, and why it is important for creating code that is loosely coupled, highly cohesive, and easy to evolve over time. Following these principles can help minimize design flaws and result in code that is simpler, more maintainable and easier to test.
This is a small recap of different SOLID principles.
The slides do not have much comments but if you follow the link, you will get all the examples and they are self explanatory.
Using the SOLID design principles to write code that's easier to understand, maintain and extend.
The slides from the SOLID speech at the CodeTalks 2018 in Hamburg.
Pavlo Zhdanov "Mastering solid and base principles for software design"LogeekNightUkraine
The document discusses SOLID principles and other principles of software design including single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion. It provides definitions and examples of each. The SOLID principles aim to create simple, modular, and understandable code by establishing best practices for class design. Additional design principles discussed ensure reusable, cohesive components with stable dependencies and abstractions.
Clean code is subjective and every developer has a personal take on it. There are some ideas that are considered best practice and what constitutes clean code within the industry and community, but there is no definitive distinction.
This document discusses the SOLID principles of object-oriented design. It introduces each principle - Single Responsibility Principle, Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. For each principle, it provides a brief definition and example to illustrate how to apply that principle to achieve high cohesion and loose coupling in software design. The overall message is that following SOLID principles can help software designs withstand changes over time by avoiding rigidity, fragility, immobility, and viscosity.
This document summarizes key principles for writing clean code as outlined in the book "Clean Code" by Robert C. Martin. It discusses ideas like writing code that is easy to read and understand through use of meaningful names, small functions that do one thing well, and avoiding duplication. It also covers principles for object-oriented design like encapsulation, organization for change, and separation of concerns. Testing philosophies like test-driven development and ensuring tests are fast, independent, repeatable, self-validating, and timely are also emphasized. The overall message is that writing clean code requires attention to structure, naming, formatting and testing to produce software that is simple, well-organized and a pleasure to maintain.
Learning solid principles using c#
S Single Responsibility Principle
O Open Closed Principle
L Liskovs Substitution Principle
I Interface Segregation Principle
D Dependency Inversion principle
Design Principle and Design Pattern examples on C# .NET Core.
(Note: Not all the contents are original, I copied some of them from online tutorials while learning and found great explanations. A great thanks to all for this information.)
The document discusses software design principles for managing complexity and change, including the Open-Closed Principle (OCP), Liskov Substitution Principle (LSP), Dependency Inversion Principle (DIP), and Interface Segregation Principle (ISP). These principles aim to create modules that are open for extension but closed for modification, with subclasses substitutable for their base classes. Dependencies should be on abstractions rather than concretions, and interfaces should be client-specific rather than general. Managing complexity means managing dependencies through high abstraction, single-responsibility classes, and other principles that promote designs that are clean, simple, and elegant.
This document discusses the SOLID principles of object-oriented design:
- The Single Responsibility Principle states that a class should have one, and only one, reason to change.
- The Open/Closed Principle specifies that software entities should be open for extension but closed for modification.
- The Liskov Substitution Principle dictates that subclasses should behave in the same way as their parent classes.
- The Interface Segregation Principle indicates that client classes should not depend on interfaces they do not use.
- The Dependency Inversion Principle asserts that high-level modules should not depend on low-level modules, but both should depend on abstractions.
The presentation provides examples of
This document discusses simplicity in software engineering. It provides quotes emphasizing the importance of simplicity from Steve Jobs and Edsger Dijkstra. It discusses factors like users, business needs, and financial constraints that influence simplicity. Programming languages that focus on simplicity tend to have lower bug density. Over-engineering can lead to unnecessary complexity, bugs, and difficulty maintaining code. Principles like KISS, YAGNI, DRY, and SOLID can help avoid over-engineering. Generalization techniques like macros, parameters, overloading, and libraries can increase simplicity if used properly but can also introduce unnecessary complexity.
Graspan: A Big Data System for Big Code AnalysisAftab Hussain
We built a disk-based parallel graph system, Graspan, that uses a novel edge-pair centric computation model to compute dynamic transitive closures on very large program graphs.
We implement context-sensitive pointer/alias and dataflow analyses on Graspan. An evaluation of these analyses on large codebases such as Linux shows that their Graspan implementations scale to millions of lines of code and are much simpler than their original implementations.
These analyses were used to augment the existing checkers; these augmented checkers found 132 new NULL pointer bugs and 1308 unnecessary NULL tests in Linux 4.4.0-rc5, PostgreSQL 8.3.9, and Apache httpd 2.2.18.
- Accepted in ASPLOS ‘17, Xi’an, China.
- Featured in the tutorial, Systemized Program Analyses: A Big Data Perspective on Static Analysis Scalability, ASPLOS ‘17.
- Invited for presentation at SoCal PLS ‘16.
- Invited for poster presentation at PLDI SRC ‘16.
E-commerce Application Development Company.pdfHornet Dynamics
Your business can reach new heights with our assistance as we design solutions that are specifically appropriate for your goals and vision. Our eCommerce application solutions can digitally coordinate all retail operations processes to meet the demands of the marketplace while maintaining business continuity.
Zoom is a comprehensive platform designed to connect individuals and teams efficiently. With its user-friendly interface and powerful features, Zoom has become a go-to solution for virtual communication and collaboration. It offers a range of tools, including virtual meetings, team chat, VoIP phone systems, online whiteboards, and AI companions, to streamline workflows and enhance productivity.
DDS Security Version 1.2 was adopted in 2024. This revision strengthens support for long runnings systems adding new cryptographic algorithms, certificate revocation, and hardness against DoS attacks.
GraphSummit Paris - The art of the possible with Graph TechnologyNeo4j
Sudhir Hasbe, Chief Product Officer, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
Transform Your Communication with Cloud-Based IVR SolutionsTheSMSPoint
Discover the power of Cloud-Based IVR Solutions to streamline communication processes. Embrace scalability and cost-efficiency while enhancing customer experiences with features like automated call routing and voice recognition. Accessible from anywhere, these solutions integrate seamlessly with existing systems, providing real-time analytics for continuous improvement. Revolutionize your communication strategy today with Cloud-Based IVR Solutions. Learn more at: https://thesmspoint.com/channel/cloud-telephony
UI5con 2024 - Keynote: Latest News about UI5 and it’s EcosystemPeter Muessig
Learn about the latest innovations in and around OpenUI5/SAPUI5: UI5 Tooling, UI5 linter, UI5 Web Components, Web Components Integration, UI5 2.x, UI5 GenAI.
Recording:
https://www.youtube.com/live/MSdGLG2zLy8?si=INxBHTqkwHhxV5Ta&t=0
Hand Rolled Applicative User ValidationCode KataPhilip Schwarz
Could you use a simple piece of Scala validation code (granted, a very simplistic one too!) that you can rewrite, now and again, to refresh your basic understanding of Applicative operators <*>, <*, *>?
The goal is not to write perfect code showcasing validation, but rather, to provide a small, rough-and ready exercise to reinforce your muscle-memory.
Despite its grandiose-sounding title, this deck consists of just three slides showing the Scala 3 code to be rewritten whenever the details of the operators begin to fade away.
The code is my rough and ready translation of a Haskell user-validation program found in a book called Finding Success (and Failure) in Haskell - Fall in love with applicative functors.
What is Master Data Management by PiLog Groupaymanquadri279
PiLog Group's Master Data Record Manager (MDRM) is a sophisticated enterprise solution designed to ensure data accuracy, consistency, and governance across various business functions. MDRM integrates advanced data management technologies to cleanse, classify, and standardize master data, thereby enhancing data quality and operational efficiency.
Measures in SQL (SIGMOD 2024, Santiago, Chile)Julian Hyde
SQL has attained widespread adoption, but Business Intelligence tools still use their own higher level languages based upon a multidimensional paradigm. Composable calculations are what is missing from SQL, and we propose a new kind of column, called a measure, that attaches a calculation to a table. Like regular tables, tables with measures are composable and closed when used in queries.
SQL-with-measures has the power, conciseness and reusability of multidimensional languages but retains SQL semantics. Measure invocations can be expanded in place to simple, clear SQL.
To define the evaluation semantics for measures, we introduce context-sensitive expressions (a way to evaluate multidimensional expressions that is consistent with existing SQL semantics), a concept called evaluation context, and several operations for setting and modifying the evaluation context.
A talk at SIGMOD, June 9–15, 2024, Santiago, Chile
Authors: Julian Hyde (Google) and John Fremlin (Google)
https://doi.org/10.1145/3626246.3653374
Need for Speed: Removing speed bumps from your Symfony projects ⚡️Łukasz Chruściel
No one wants their application to drag like a car stuck in the slow lane! Yet it’s all too common to encounter bumpy, pothole-filled solutions that slow the speed of any application. Symfony apps are not an exception.
In this talk, I will take you for a spin around the performance racetrack. We’ll explore common pitfalls - those hidden potholes on your application that can cause unexpected slowdowns. Learn how to spot these performance bumps early, and more importantly, how to navigate around them to keep your application running at top speed.
We will focus in particular on tuning your engine at the application level, making the right adjustments to ensure that your system responds like a well-oiled, high-performance race car.
Microservice Teams - How the cloud changes the way we workSven Peters
A lot of technical challenges and complexity come with building a cloud-native and distributed architecture. The way we develop backend software has fundamentally changed in the last ten years. Managing a microservices architecture demands a lot of us to ensure observability and operational resiliency. But did you also change the way you run your development teams?
Sven will talk about Atlassian’s journey from a monolith to a multi-tenanted architecture and how it affected the way the engineering teams work. You will learn how we shifted to service ownership, moved to more autonomous teams (and its challenges), and established platform and enablement teams.
Software Engineering, Software Consulting, Tech Lead, Spring Boot, Spring Cloud, Spring Core, Spring JDBC, Spring Transaction, Spring MVC, OpenShift Cloud Platform, Kafka, REST, SOAP, LLD & HLD.
WhatsApp offers simple, reliable, and private messaging and calling services for free worldwide. With end-to-end encryption, your personal messages and calls are secure, ensuring only you and the recipient can access them. Enjoy voice and video calls to stay connected with loved ones or colleagues. Express yourself using stickers, GIFs, or by sharing moments on Status. WhatsApp Business enables global customer outreach, facilitating sales growth and relationship building through showcasing products and services. Stay connected effortlessly with group chats for planning outings with friends or staying updated on family conversations.
2. Always code as if the guy who ends up
maintaining your code will be a
violent psychopath
who knows where you live.
3.
4. Problems
• Does our code solves challenges and
business problems that it should
• Is our code human readable
• Is our code maintainable
• Is our code extensible, scalable
• Is our code granular and reusable
7. Open-close principle
System elements should be open for extension but closed
for modification
Lights can be dismantled without taking out an engine
8. Liskov substitution principle
Object of a derived class should be able to replace an object of the base class without
bringing any errors in the system or modifying the behavior of the base class
If it looks like a duck, and quack like a duck, but it needs batteries,
You probably have wrong level of abstraction
9. Interface segregation principle
Many specialized interfaces are better than one almighty.
A client should never be forced to implement an interface that it
doesn’t need or clients shouldn’t be forced to depend on methods
It’s not a good idea to mix electricity and water in one place
10. Dependency inversion principle
The high level module must not depend on the low level module.
Both modules should depend on abstractions.
Abstractions should not depend on details. Details should depend on
abstractions.
You don’t need to know how the engine is build to start it
12. KISS DRY YAGNI
YAGNI DRY
Don’t Repeat
Yourself
WET
We Enjoy Typing
Write Everything Twice
13. KISS DRY YAGNI
YAGNI DRY KISS
Keep It Simple Stupid
Keep It Simple, Stupid
Keep it Simple Silly
Keep It Short & Simple
Keep It Small & Simple
Keep It Simple
&Straightforward
Dlaczego rozmawiamy o solidzie?
Teoretyczne podstawy jezyka
paradygmaty języka i podstawy wzorcow projektowych
MSDN przyklady tak mowia.
Brak duzych przykladow – duzych systemow.
Architektura I utrzymanie system przez lata
Łatwo jest użyć wzorców do małych programów typu uniwersyteckiego, natomiast nie jest już tak prostą sprawą użycie ich w istniejących często bardzo dużych systemach, dodatkowo istniejące systemy zazwyczaj są pisane od wielu lat i nie zawsze są dobrze dostosowane do stosowania wzorców.
Problemy przed nami programistami I przed samym systemem.
Każdy kod który” został napisany jest już Legacy Code (nawet napisałam go ja 15 minut temu).
Czy nasz program rozwiązuje problem
Czy nasz kod jest czytelny dla człowieka
Czy nasz kod jest łatwo utrzymywalny
Czy nasz kod jest łatwo rozszerzalny w razie potrzeby
Czym granularność naszego kodu jest wystarczająca czy też może powinien być rozbity na mniejsze fragmenty i robić mniej rzeczy na raz.
Aby dobrze posługiwać się wzorcami trzeba je dobrze poznać.
SOLID stara sie odpowiedziec na te pytania, dac nam narzedzia do budowania lepszego oprogramowania.
SOLID to zasady zebrane i spisane, choć nie stworzone przez Roberta Martina zwanego wujkiem Bobem.
Gang czworga. Design patgerns 1994 wspierani
Przez booth’a tworce umla 1996
Wujek Bob jest bardzo charyzmatyczną i marketingową postacią przedstawiającą dobre praktyki programowania. Wart jest śledzenia. Jednak warto też nałożyć filtr ponieważ nie wszystko jest możliwe do zaimplementowania. A moim zdaniem najlepiej zastosować zasadę złotego środka czysty kod jest dobry jeśli nie przesadzimy z jego puryzmem.
S - Single responsibility principle
Zasada pojedynczej odpowiedzialności. Kasa nie powinna mieć więcej niż jeden powód do modyfikacji.
Kod powinien robić jedną rzecz, tylko jedną rzecz i robicie ją dobrze.
Jedna rzecz
= jest łatwiej zrozumiały,
= mniejsze prawdopodobienstwo koniecznosci modyfikacji
= mniej dotkliwe skutki uboczne modyfikacji
Nie zawsze jest wiadome i jasne czym jest "jedna rzecz"
(mówimy zarówno o poziomie projektu, modułu, klasy jak i metody).
Przykład - użytkownik
- "Wylicz podwyżkę"
- "Zmień dane osobowe"
Tutaj oczywiście mamy dwie różne odpowiedzialności, które potrafiliśmy łatwo zidentyfikować i nazwać.
Na bazie jednych pomysłów rodzą się kolejne.
Patrząc na zapis do bazy:
-aktualizacja danych, dodanie nowych danych i usuwanie danych
-odczyt danych z bazy danych . wiele wariantów sortowaniem wyszukiwanie, zawezanie zakresu
Tutaj ta teoretycznie jedna odpowiedzialności jaką jest operowanie danymi przechowywanymi podzielona jest na dwie niezależne od siebie części czyli dostęp typu odczyt oraz dostęp typu zmiana. Cała ta idea leży u podstaw CQRS.
Elementy systemu powinny być otwarte na rozszerzanie ale zamknięte na modyfikację.
jak to powinniśmy napisać kod raz i już nigdy do niego nie wrócić?
Nie powinniśmy go modyfikować za to możemy go rozszerzać?
Kazda modyfikacja moze wprowadzic bledy. W danej metodzie I zaleznosciach
Przyklad wysokiego poziomu
WordPress.
Wtyczki
Sredni poziom
Feacher toggling/ feacher switching
Niski poziom
String
Extension method
Wyjątki
1 Jeśli kod zawiera błędy to powinniśmy te błędy rozwiązać
2 Jeśli chcemy zrefaktoryzowac kod to możemy, o ile nie przedstawimy w ten sposób nowych błędów. Oczywiście refaktoryzację przedstawiamy tylko dlatego że nasz kod zaczyna łamać zasady SOLID.
3 Trochę kontrowersyjna zasada, ale możemy zmieniać kod jeśli nie przedstawimy w ten sposób nowych błędów a klienci naszego kodu nie odczują zmiany czyli że nie będą musieli dostosowywać się do zmian.
Single Responsibility I Open Close = podzial kodu, trochę burdel.
Zacznijmy sprzatac
Liskov substitution principle.
Zasada mówi że powinniśmy być w stanie zastąpić klasa dowolną subklasa tej klasy bez potrzeby dodatkowej modyfikacji kodu.
rozszerzenie i obostrzenie zasad dziedziczenia,
ponieważ wszędzie tam gdzie możemy użyć klasy bazowej możemy użyć też klasy dziedziczącej. Jezyk nie pozwoli nam inaczej (np na odwrot). Wiekszosc zasady Liskov daje nam jezyk out of the box. Jedyne co to exception…
Wymienne korzystanie z subklas.
Liskov dodatkowe zasady
1 Warunki wstępne nie mogą zostać wzmocnione przez podklasa
2 Warunki oczekiwane (wyjściowe) nie mogą zostać osłabione przez podklasa
3 zmienne które nie są zmieniane przez metodę w klasie bazowej nie mogą być również zmieniane przez metodę klasy dziedziczącej.
Klasa dziedzicząca nie może wprowadzać nowych typów: przykład exceptiony (nie może go zawęzić/wyspecjalizować. )
Wszystko to robimy ze względu na klientów naszego kodu, aby nie musieli oni modyfikować obsługi kontraktów na które się zobowiązaliśmy.
Pułapka źle wybranej abstrakcji.
Przykład kaczki
Latanie , karminie (exception w rubber duck)
Zly poziom abstrakcji
Ze zle wybranej abstrakcji latwiej jest wyjsc interfejsami – wystarczy pamietac o nie wyrzucaniu exceptionow.
Liskov jest praktycznie niepokazywalny – mozna pokazac tylko zlamanie tej zasady.
I - Interface segregation principle
Zasada segregacji interfejsów mówi że wiele specyficznych interfejsów jest lepsze niż jeden interfejs "robiący wszystko". Klienci nie powinni być zmuszani to implementacji metod których nie potrzebują.
Ratujemy kaczke interfejsami
Dzielimy interfejsy.
Latanie
Karmienie
Material…
Wybrnelismy ze zlej abstrakcji
Best – dobra abstrakcja i male interfejsy.
Mamy:
Male wyspecjalizowane klasy z interfejsami przygotowane na niemodyfikowanie tylko rozszerzanie. Dobra abstrakcja, wszystko gra.
DI żeby polaczy
W tym momencie mamy już bardzo małe wyspecjalizowane klasy które posiadają swoje jeszcze mniejsze wyspecjalizowane interfejsy wszystko to może być w wielu wersjach które możemy dowolnie wymieniać.
Aby wszystko teraz połączyć i nie zepsuć powinniśmy zastosować zasadę odwracania zależności.
D - Dependency inversion principle
Zasada odwróconej zależności mówi że moduły wysokiego poziomu nie powinny być zależne od modułów niskiego poziomu, oba poziomy modułów powinny być zależne od abstrakcj.
Oraz że abstrakcje nie powinny zależeć od detali to detale powinny być zależne od abstrakcji.
używanie abstrakcji w każdej interakcji pomiędzy modułami, klasami.
Zawsze powinniśmy polegać tylko na abstrakcji nie na konkretnej implementacji.
Przykład - samochód
nie potrzebujemy wiedzieć jak zbudować silnik ani jaki silnik jest w samochodzie, żeby móc go włączyć ponieważ wszystkie samochody maja interfejs stacyjki który zapewnia start silnika.
W praktyce do realizacji tej zasady używamy mechanizmu Dependency Injection oraz kontenerów,
wyręczają w inicjalizacji klas implementujących wymagane interfejsy.
Bardzo trudno jest stworzyć system który będzie spełniał wszystkie zasady SOLID.
Mimo że te dobre praktyki mają pomagać w tworzeniu niezawodnego, łatwo rozszerzalnego, testowalnego oprogramowania prawda jest taka że stosowanie zasad SOLID wymaga dużego nakładu pracy na którego często nie ma dostępnych wystarczających zasobów.
Kilka akronimow:
YAGNI – You Aint Gonna Need It.
Biznesowo i architektonicznie
Nie budowanie funkcjonalności które nie są nam potrzebne teraz.
plany długofalowe, ale nie teraz.
Tendencja programistow – teraz będzie taniej i lepiej.
Wynik:
Niepotrzebny koszt budowy,
Koszt utrzymania,
Kosz testow.
Zmiana wymagan = reimplementacja.
Piszmy więc tylko to czego potrzebujemy/ czego potrzebuje biznes.
Programistyczne.
patrzenie w tył czyli co zrobić z kodem po refaktoringu.
Tendencja programistów - "może się przydać".
W najlepszym wypadku = komentujemy kod.
W najgorszym wypadku = zostawiamy zombi kod który nie jest z niczym powiązany nie jest testowany niby jest martwy ale nadal żyje a w dodatku jest upchnięty w schowku z którego gdy go wypuścimy może nam tylko zjeść mózg.
Najlepiej wyrzucić.
Repozytorium pamięta
DRY
Don't Repeat Yourself.
biznesowo.
Każdy kawałek wiedzy w systemie powinien być reprezentowany/zaimplementowany tylko raz w całym systemie.
W kontekście biznesowym mówimy tylko i wyłącznie o funkcjonalnościach jako całości nie przejmujemy się powtorzeniem kodu. Oczywiście zrealizować pojedyńczą implementację możemy wybierając np. kompozycję ponad dziedziczenie, jednak nadal rozmawiamy o funkcjonalnościach.
Programistycznie
Leniwy programista pisze raz a potem uzywa.
Odwrotnością DRY jest WET które tłumaczy się na We Enjoy Typing albo Write Everything Twice.
Rozmawiamy nie tylko o powtarzającym się kodzie ale również powtarzających się operacjach które mogą być zautomatyzowane (jak DevOps)
KISS
Keep It Simple Stupid
Keep It Simple, Stupid
Keep it Simple Silly
Zmieniając położenie przecinka w podstawowym tłumaczeniu zmieniamy troszkę wydźwięk tego stwierdzenia. Jednak nie obrażając adresata stwierdzenia chcemy aby nasze rozwiązanie było głupio proste, maksymalnie uproszczone i zrozumiałe dla każdego.
tworzyć rozwiązania proste nie łatwe.
(bo nie warto robić rzeczy łatwych, ale dążenie do prostoty jest dążeniem do doskonałości)
Programistycznie
patrząc w przód
i wymyślając wspaniały mechanizm który będzie przygotowany na wszystkie ewentualności nieważne jaka jest podstawowa funkcjonalność.
gotowi na wszystko.
Z najlepszym przypadku jest to "tylko" over-enginering i kod tak piękny że nikt nie potrafi go zrozumieć - ale jest np. jednolinijkowy.
W najgorszym przypadku
Programisci się zapetlaja w DRY I KISS
I tworza frameworki.
Trudne w używaniu zrozumieniu i utrzymaniu.
KISS jest dążeniem do prostoty.
Zawsze pamiętajmy o zdrowym rozsądku i złotym środku