├── .github └── FUNDING.yml ├── .gitignore └── README.md /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | github: [iluwatar] 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | dist 2 | node_modules 3 | 4 | # MacOS - General 5 | .DS_Store 6 | .AppleDouble 7 | .LSOverride 8 | 9 | # MacOS - Icon must end with two \r 10 | Icon 11 | 12 | 13 | # MacOS - Thumbnails 14 | ._* 15 | 16 | # MacOS - Files that might appear in the root of a volume 17 | .DocumentRevisions-V100 18 | .fseventsd 19 | .Spotlight-V100 20 | .TemporaryItems 21 | .Trashes 22 | .VolumeIcon.icns 23 | .com.apple.timemachine.donotpresent 24 | 25 | # MacOS - Directories potentially created on remote AFP share 26 | .AppleDB 27 | .AppleDesktop 28 | Network Trash Folder 29 | Temporary Items 30 | .apdisk 31 | 32 | # IntelliJ IDEA 33 | .idea/ 34 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Essential Java Design Principles for Developers" 3 | shortTitle: Java Design Principles 4 | description: "Discover the key principles behind effective Java design patterns. This page provides clear insights into the theory and practice of Java design principles for better software development." 5 | language: en 6 | --- 7 | 8 | ## Introduction to Programming Principles 9 | 10 | There are certain universal laws and principles in software development that guide architects, programmers, and anyone needing to design software. This page lists quite a few of those principles, although it's far from complete. This page is a fork of [programming-principles repository by Lars Kappert](https://github.com/webpro/programming-principles), who has done most of the work collecting the material. 11 | 12 | ## KISS 13 | 14 | Most systems work best if they are kept simple rather than made complex. 15 | 16 | Why 17 | 18 | - Less code takes less time to write, has less bugs, and is easier to modify. 19 | - Simplicity is the ultimate sophistication. 20 | - It seems that perfection is reached not when there is nothing left to add, but 21 | when there is nothing left to take away. 22 | 23 | Resources 24 | 25 | - [KISS principle](https://en.wikipedia.org/wiki/KISS_principle) 26 | - [Keep It Simple Stupid (KISS)](http://principles-wiki.net/principles:keep_it_simple_stupid) 27 | 28 | ## YAGNI 29 | 30 | YAGNI stands for "you aren't gonna need it": don't implement something until it 31 | is necessary. 32 | 33 | Why 34 | 35 | - Any work that's only used for a feature that's needed tomorrow, means losing 36 | effort from features that need to be done for the current iteration. 37 | - It leads to code bloat; the software becomes larger and more complicated. 38 | 39 | How 40 | 41 | - Always implement things when you actually need them, never when you just 42 | foresee that you need them. 43 | 44 | Resources 45 | 46 | - [You Arent Gonna Need It](http://c2.com/xp/YouArentGonnaNeedIt.html) 47 | - [You’re NOT gonna need it!](https://ronjeffries.com/xprog/articles/practices/pracnotneed/) 48 | - [You aren't gonna need it](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) 49 | 50 | ## Do The Simplest Thing That Could Possibly Work 51 | 52 | Why 53 | 54 | - Real progress against the real problem is maximized if we just work on what 55 | the problem really is. 56 | 57 | How 58 | 59 | - Ask yourself: "What is the simplest thing that could possibly work?" 60 | 61 | Resources 62 | 63 | - [Do The Simplest Thing That Could Possibly Work](http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html) 64 | 65 | ## Separation of Concerns 66 | 67 | Separation of concerns is a design principle for separating a computer program 68 | into distinct sections, such that each section addresses a separate concern. For 69 | example the business logic of the application is a concern and the user 70 | interface is another concern. Changing the user interface should not require 71 | changes to business logic and vice versa. 72 | 73 | Quoting [Edsger W. Dijkstra](https://en.wikipedia.org/wiki/Edsger_W._Dijkstra) 74 | (1974): 75 | 76 | > It is what I sometimes have called "the separation of concerns", which, even 77 | > if not perfectly possible, is yet the only available technique for effective 78 | > ordering of one's thoughts, that I know of. This is what I mean by "focusing 79 | > one's attention upon some aspect": it does not mean ignoring the other 80 | > aspects, it is just doing justice to the fact that from this aspect's point of 81 | > view, the other is irrelevant. 82 | 83 | Why 84 | 85 | - Simplify development and maintenance of software applications. 86 | - When concerns are well-separated, individual sections can be reused, as well 87 | as developed and updated independently. 88 | 89 | How 90 | 91 | - Break program functionality into separate modules that overlap as little as 92 | possible. 93 | 94 | Resources 95 | 96 | - [Separation of Concerns](https://en.wikipedia.org/wiki/Separation_of_concerns) 97 | 98 | ## Keep things DRY 99 | 100 | Every piece of knowledge must have a single, unambiguous, authoritative 101 | representation within a system. 102 | 103 | Each significant piece of functionality in a program should be implemented in 104 | just one place in the source code. Where similar functions are carried out by 105 | distinct pieces of code, it is generally beneficial to combine them into one by 106 | abstracting out the varying parts. 107 | 108 | Why 109 | 110 | - Duplication (inadvertent or purposeful duplication) can lead to maintenance 111 | nightmares, poor factoring, and logical contradictions. 112 | - A modification of any single element of a system does not require a change in 113 | other logically unrelated elements. 114 | - Additionally, elements that are logically related all change predictably and 115 | uniformly, and are thus kept in sync. 116 | 117 | How 118 | 119 | - Put business rules, long expressions, if statements, math formulas, metadata, 120 | etc. in only one place. 121 | - Identify the single, definitive source of every piece of knowledge used in 122 | your system, and then use that source to generate applicable instances of that 123 | knowledge (code, documentation, tests, etc). 124 | - Apply the 125 | [Rule of three](). 126 | 127 | Resources 128 | 129 | - [Dont Repeat Yourself](http://wiki.c2.com/?DontRepeatYourself) 130 | - [Don't repeat yourself](https://en.wikipedia.org/wiki/Don't_repeat_yourself) 131 | - [DRY Principle: Its Benefit and Cost with Examples](https://thevaluable.dev/dry-principle-cost-benefit-example/) 132 | 133 | Related 134 | 135 | - [Abstraction principle]() 136 | - [Once And Only Once](http://wiki.c2.com/?OnceAndOnlyOnce) is a subset of DRY 137 | (also referred to as the goal of refactoring). 138 | - [Single Source of Truth](https://en.wikipedia.org/wiki/Single_Source_of_Truth) 139 | - A violation of DRY is [WET](http://thedailywtf.com/articles/The-WET-Cart) 140 | (Write Everything Twice) 141 | - [Be careful with the code metric "duplicated lines"](https://rachelcarmena.github.io/2018/02/27/duplication-you-are-welcome.html) 142 | 143 | ## Code For The Maintainer 144 | 145 | Why 146 | 147 | - Maintenance is by far the most expensive phase of any project. 148 | 149 | How 150 | 151 | - _Be_ the maintainer. 152 | - Always code as if the person who ends up maintaining your code is a violent 153 | psychopath who knows where you live. 154 | - Always code and comment in such a way that if someone a few notches junior 155 | picks up the code, they will take pleasure in reading and learning from it. 156 | - [Don't make me think](http://www.sensible.com/dmmt.html). 157 | - Use the 158 | [Principle of Least Astonishment](https://en.wikipedia.org/wiki/Principle_of_least_astonishment). 159 | 160 | Resources 161 | 162 | - [Code For The Maintainer](http://wiki.c2.com/?CodeForTheMaintainer) 163 | - [The Noble Art of Maintenance Programming](https://blog.codinghorror.com/the-noble-art-of-maintenance-programming/) 164 | 165 | ## Avoid Premature Optimization 166 | 167 | Quoting [Donald Knuth](https://en.wikiquote.org/wiki/Donald_Knuth): 168 | 169 | > Programmers waste enormous amounts of time thinking about, or worrying about, 170 | > the speed of noncritical parts of their programs, and these attempts at 171 | > efficiency actually have a strong negative impact when debugging and 172 | > maintenance are considered. We should forget about small efficiencies, say 173 | > about 97% of the time: premature optimization is the root of all evil. Yet we 174 | > should not pass up our opportunities in that critical 3%. 175 | 176 | Understanding what is and isn’t "premature" is critical of course. 177 | 178 | Why 179 | 180 | - It is unknown upfront where the bottlenecks will be. 181 | - After optimization, it might be harder to read and thus maintain. 182 | 183 | How 184 | 185 | - [Make It Work Make It Right Make It Fast](http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast) 186 | - Don't optimize until you need to, and only after profiling you discover a 187 | bottleneck optimise that. 188 | 189 | Resources 190 | 191 | - [Program optimization](https://en.wikipedia.org/wiki/Program_optimization) 192 | - [Premature Optimization](http://wiki.c2.com/?PrematureOptimization) 193 | 194 | ## Minimise Coupling 195 | 196 | Coupling between modules/components is their degree of mutual interdependence; 197 | lower coupling is better. In other words, coupling is the probability that code 198 | unit "B" will "break" after an unknown change to code unit "A". 199 | 200 | Why 201 | 202 | - A change in one module usually forces a ripple effect of changes in other 203 | modules. 204 | - Assembly of modules might require more effort and/or time due to the increased 205 | inter-module dependency. 206 | - A particular module might be harder to reuse and/or test because dependent 207 | modules must be included. 208 | - Developers might be afraid to change code because they aren't sure what might 209 | be affected. 210 | 211 | How 212 | 213 | - Eliminate, minimise, and reduce complexity of necessary relationships. 214 | - By hiding implementation details, coupling is reduced. 215 | - Apply the [Law of Demeter](#law-of-demeter). 216 | 217 | Resources 218 | 219 | - [Coupling]() 220 | - [Coupling And Cohesion](http://wiki.c2.com/?CouplingAndCohesion) 221 | 222 | ## Law of Demeter 223 | 224 | Don't talk to strangers. 225 | 226 | Why 227 | 228 | - It usually tightens coupling 229 | - It might reveal too much implementation details 230 | 231 | How 232 | 233 | A method of an object may only call methods of: 234 | 235 | 1. The object itself. 236 | 2. An argument of the method. 237 | 3. Any object created within the method. 238 | 4. Any direct properties/fields of the object. 239 | 240 | Resources 241 | 242 | - [Law of Demeter](https://en.wikipedia.org/wiki/Law_of_Demeter) 243 | - [The Law of Demeter Is Not A Dot Counting Exercise](https://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx/) 244 | 245 | ## Composition Over Inheritance 246 | 247 | Why 248 | 249 | - Less coupling between classes. 250 | - Using inheritance, subclasses easily make assumptions, and break LSP. 251 | 252 | How 253 | 254 | - Test for LSP (substitutability) to decide when to inherit. 255 | - Compose when there is a "has a" (or "uses a") relationship, inherit when "is 256 | a". 257 | 258 | Resources 259 | 260 | - [Favor Composition Over Inheritance](https://blogs.msdn.microsoft.com/thalesc/2012/09/05/favor-composition-over-inheritance/) 261 | 262 | ## Orthogonality 263 | 264 | > The basic idea of orthogonality is that things that are not related 265 | > conceptually should not be related in the system. 266 | 267 | Source: [Be Orthogonal](https://www.artima.com/intv/dry3.html) 268 | 269 | > It is associated with simplicity; the more orthogonal the design, the fewer 270 | > exceptions. This makes it easier to learn, read and write programs in a 271 | > programming language. The meaning of an orthogonal feature is independent of 272 | > context; the key parameters are symmetry and consistency. 273 | 274 | Source: 275 | [Orthogonality]() 276 | 277 | ## Robustness Principle 278 | 279 | > Be conservative in what you do, be liberal in what you accept from others 280 | 281 | Collaborating services depend on each others interfaces. Often the interfaces 282 | need to evolve causing the other end to receive unspecified data. A naive 283 | implementation refuses to collaborate if the received data does not strictly 284 | follow the specification. A more sophisticated implementation will still work 285 | ignoring the data it does not recognize. 286 | 287 | Why 288 | 289 | - In order to be able to evolve services you need to ensure that a provider can 290 | make changes to support new demands while causing minimal breakage to their 291 | existing clients. 292 | 293 | How 294 | 295 | - Code that sends commands or data to other machines (or to other programs on 296 | the same machine) should conform completely to the specifications, but code 297 | that receives input should accept non-conformant input as long as the meaning 298 | is clear. 299 | 300 | Resources 301 | 302 | - [Robustness Principle in Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle) 303 | - [Tolerant Reader](https://martinfowler.com/bliki/TolerantReader.html) 304 | 305 | ## Inversion of Control 306 | 307 | Inversion of Control is also known as the Hollywood Principle, "Don't call us, 308 | we'll call you". It is a design principle in which custom-written portions of a 309 | computer program receive the flow of control from a generic framework. Inversion 310 | of control carries the strong connotation that the reusable code and the 311 | problem-specific code are developed independently even though they operate 312 | together in an application. 313 | 314 | Why 315 | 316 | - Inversion of control is used to increase modularity of the program and make it 317 | extensible. 318 | - To decouple the execution of a task from implementation. 319 | - To focus a module on the task it is designed for. 320 | - To free modules from assumptions about how other systems do what they do and 321 | instead rely on contracts. 322 | - To prevent side effects when replacing a module. 323 | 324 | How 325 | 326 | - Using Factory pattern 327 | - Using Service Locator pattern 328 | - Using Dependency Injection 329 | - Using contextualized lookup 330 | - Using Template Method pattern 331 | - Using Strategy pattern 332 | 333 | Resources 334 | 335 | - [Inversion of Control in Wikipedia](https://en.wikipedia.org/wiki/Inversion_of_control) 336 | - [Inversion of Control Containers and the Dependency Injection pattern](https://www.martinfowler.com/articles/injection.html) 337 | 338 | ## Maximise Cohesion 339 | 340 | Cohesion of a single module/component is the degree to which its 341 | responsibilities form a meaningful unit; higher cohesion is better. 342 | 343 | Why 344 | 345 | - Increased difficulty in understanding modules. 346 | - Increased difficulty in maintaining a system, because logical changes in the 347 | domain affect multiple modules, and because changes in one module require 348 | changes in related modules. 349 | - Increased difficulty in reusing a module because most applications won’t need 350 | the random set of operations provided by a module. 351 | 352 | How 353 | 354 | - Group related functionalities sharing a single responsibility (e.g. in a 355 | class). 356 | 357 | Resources 358 | 359 | - [Cohesion]() 360 | - [Coupling And Cohesion](http://wiki.c2.com/?CouplingAndCohesion) 361 | 362 | ## Liskov Substitution Principle 363 | 364 | The LSP is all about expected behavior of objects: 365 | 366 | > Objects in a program should be replaceable with instances of their subtypes 367 | > without altering the correctness of that program. 368 | 369 | Resources 370 | 371 | - [Liskov substitution principle](https://en.wikipedia.org/wiki/Liskov_substitution_principle) 372 | - [Liskov Substitution Principle](http://www.blackwasp.co.uk/lsp.aspx) 373 | 374 | ## Open/Closed Principle 375 | 376 | Software entities (e.g. classes) should be open for extension, but closed for 377 | modification. I.e. such an entity can allow its behavior to be modified without 378 | altering its source code. 379 | 380 | Why 381 | 382 | - Improve maintainability and stability by minimizing changes to existing code. 383 | 384 | How 385 | 386 | - Write classes that can be extended (as opposed to classes that can be 387 | modified). 388 | - Expose only the moving parts that need to change, hide everything else. 389 | 390 | Resources 391 | 392 | - [Open Closed Principle](https://en.wikipedia.org/wiki/Open/closed_principle) 393 | - [The Open Closed Principle](https://blog.cleancoder.com/uncle-bob/2014/05/12/TheOpenClosedPrinciple.html) 394 | 395 | ## Single Responsibility Principle 396 | 397 | A class should never have more than one reason to change. 398 | 399 | Long version: Every class should have a single responsibility, and that 400 | responsibility should be entirely encapsulated by the class. Responsibility can 401 | be defined as a reason to change, so a class or module should have one, and only 402 | one, reason to change. 403 | 404 | Why 405 | 406 | - Maintainability: changes should be necessary only in one module or class. 407 | 408 | How 409 | 410 | - Apply [Curly's Law](#curlys-law). 411 | 412 | Resources 413 | 414 | - [Single responsibility principle](https://en.wikipedia.org/wiki/Single_responsibility_principle) 415 | 416 | ## Hide Implementation Details 417 | 418 | A software module hides information (i.e. implementation details) by providing 419 | an interface, and not leak any unnecessary information. 420 | 421 | Why 422 | 423 | - When the implementation changes, the interface clients are using does not have 424 | to change. 425 | 426 | How 427 | 428 | - Minimize accessibility of classes and members. 429 | - Don’t expose member data in public. 430 | - Avoid putting private implementation details into a class’s interface. 431 | - Decrease coupling to hide more implementation details. 432 | 433 | Resources 434 | 435 | - [Information hiding](https://en.wikipedia.org/wiki/Information_hiding) 436 | 437 | ## Curly's Law 438 | 439 | Curly's Law is about choosing a single, clearly defined goal for any particular 440 | bit of code: Do One Thing. 441 | 442 | - [Curly's Law: Do One Thing](https://blog.codinghorror.com/curlys-law-do-one-thing/) 443 | - [The Rule of One or Curly’s Law](http://grsmentor.com/blog/the-rule-of-one-or-curlys-law/) 444 | 445 | ## Encapsulate What Changes 446 | 447 | A good design identifies the hotspots that are most likely to change and 448 | encapsulates them behind an API. When an anticipated change then occurs, the 449 | modifications are kept local. 450 | 451 | Why 452 | 453 | - To minimize required modifications when a change occurs 454 | 455 | How 456 | 457 | - Encapsulate the concept that varies behind an API 458 | - Possibly separate the varying concept into its own module 459 | 460 | Resources 461 | 462 | - [Encapsulate the Concept that Varies](http://principles-wiki.net/principles:encapsulate_the_concept_that_varies) 463 | - [Encapsulate What Varies](https://blogs.msdn.microsoft.com/steverowe/2007/12/26/encapsulate-what-varies/) 464 | - [Information hiding](https://en.wikipedia.org/wiki/Information_hiding) 465 | 466 | ## Interface Segregation Principle 467 | 468 | Reduce fat interfaces into multiple smaller and more specific client specific 469 | interfaces. An interface should be more dependent on the code that calls it than 470 | the code that implements it. 471 | 472 | Why 473 | 474 | - If a class implements methods that are not needed the caller needs to know 475 | about the method implementation of that class. For example if a class 476 | implements a method but simply throws then the caller will need to know that 477 | this method shouldn't actually be called. 478 | 479 | How 480 | 481 | - Avoid fat interfaces. Classes should never have to implement methods that 482 | violate the 483 | [Single responsibility principle](#single-responsibility-principle). 484 | 485 | Resources 486 | 487 | - [Interface segregation principle](https://en.wikipedia.org/wiki/Interface_segregation_principle) 488 | 489 | ## Boy-Scout Rule 490 | 491 | The Boy Scouts of America have a simple rule that we can apply to our 492 | profession: "Leave the campground cleaner than you found it". The boy-scout rule 493 | states that we should always leave the code cleaner than we found it. 494 | 495 | Why 496 | 497 | - When making changes to an existing codebase the code quality tends to degrade, 498 | accumulating technical debt. Following the boyscout rule, we should mind the 499 | quality with each commit. Technical debt is resisted by continuous 500 | refactoring, no matter how small. 501 | 502 | How 503 | 504 | - With each commit make sure it does not degrade the codebase quality. 505 | - Any time someone sees some code that isn't as clear as it should be, they 506 | should take the opportunity to fix it right there and then. 507 | 508 | Resources 509 | 510 | - [Opportunistic Refactoring](https://martinfowler.com/bliki/OpportunisticRefactoring.html) 511 | 512 | ## Command Query Separation 513 | 514 | The Command Query Separation principle states that each method should be either 515 | a command that performs an action or a query that returns data to the caller but 516 | not both. Asking a question should not modify the answer. 517 | 518 | With this principle applied the programmer can code with much more confidence. 519 | The query methods can be used anywhere and in any order since they do not mutate 520 | the state. With commands one has to be more careful. 521 | 522 | Why 523 | 524 | - By clearly separating methods into queries and commands the programmer can 525 | code with additional confidence without knowing each method's implementation 526 | details. 527 | 528 | How 529 | 530 | - Implement each method as either a query or a command 531 | - Apply naming convention to method names that implies whether the method is a 532 | query or a command 533 | 534 | Resources 535 | 536 | - [Command Query Separation in Wikipedia](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation) 537 | - [Command Query Separation by Martin Fowler](https://martinfowler.com/bliki/CommandQuerySeparation.html) 538 | 539 | ## Murphy's Law 540 | 541 | > Anything that can go wrong will go wrong. 542 | 543 | It seems to be a universal law that when there is even the smallest possibility of something going wrong, it eventually will go wrong. It makes total sense when we think about probabilities and an infinite amount of trials. The law also applies to software development. 544 | 545 | Resources 546 | 547 | - [Murphy's law in Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law) 548 | 549 | ## Brooks's Law 550 | 551 | > Adding manpower to a late software project makes it later. 552 | 553 | The law is related to software project management and was introduced by Fred Brooks in his famous book 'The Mythical Man-Month'. The essence of the law is that adding new developers to a software project does not make them productive immediately but conversely takes time from the other team members due to communication overhead. 554 | 555 | Resources 556 | 557 | - [Brooks's law in Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law) 558 | 559 | ## Linus's Law 560 | 561 | > Given enough eyeballs, all bugs are shallow. 562 | 563 | The law is originating from the book 'The Cathedral and the Bazaar' by Eric S. Raymond and was named in honor of the famous Finnish inventor of Linux operating system, Linus Torvalds. It's basically a praise to software reviewing process where multiple developers inspect the piece of code before it's accepted and merged. 564 | 565 | Resources 566 | 567 | - [Linus's law in Wikipedia](https://en.wikipedia.org/wiki/Linus%27s_law) 568 | --------------------------------------------------------------------------------