17
IS YOUR CODE SOLID ENOUGH? PART 1 : JUMP START BY BUYUNG BAHARI

Is your code SOLID enough?

  • Upload
    sarccom

  • View
    36

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Is your code SOLID enough?

IS YOUR CODE SOLID ENOUGH?

PART 1 : JUMP START

BY BUYUNG BAHARI

Page 2: Is your code SOLID enough?

WHAT IS SOLID?• The acronym SOLID stands for Single Responsibility Principle, Open-Closed

Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle

• SOLID is a set of software design principles that can be used in conjunction with object-oriented programming and design. Robert C. Martin introduced the underlying concepts of SOLID in 1995 with his 11 commandments of object-oriented programming (OOP). Michael Feathers coined the acronym SOLID in the early 2000s as a mnemonic device for remembering the first five concepts.

Page 3: Is your code SOLID enough?

WHAT IS THE SOLID PURPOSE?

• Because SOLID is a set of design principles, it does not teach people how to program. Instead, SOLID principles help programmers write better code

• The goal is code will be more robust and usable

Page 4: Is your code SOLID enough?

WHY SOLID?

• The answer to “Why SOLID?” is simply that SOLID principles produce better code

• SOLID principles to counteract developers habits of writing code containing thousands of lines and numerous methods or functions in a class

Page 5: Is your code SOLID enough?

WHY SOLID?• Dirty code detector.

• Does the code implement a design pattern?• Adopting a design pattern in your code or program is not compulsory

• Use your best judgment to decide whether or not you want to implement patterns

• Patterns provide an extra, coated layer to your program so that you can write robustly with little chance of falling.

• Is the code tightly coupled?• In software engineering, coupling is the manner and degree of interdependence between software

modules; a measure of how closely connected two routines or modules are

• This means your application or software is tightly coupled, which means your code qualifies as dirty code

Page 6: Is your code SOLID enough?

WHY SOLID?

• Dirty code detector.• Is the code testable?

• Advantages the code is testable• It reduces the reworking time needed due to any unrecovered issue.

• It provides ability-testing code within code.

• It reduces the time needed for debugging code—with the help of test-driven development (TDD) we can easily and quickly locate problems.

• It allows for easy determination of whether or not recent changes or refactoring broke the code.

• Writing tests may be unpleasant and time-consuming, but tests are important

• TDD helps us to improve code quality and draw our focus to the main purpose of our task

Page 7: Is your code SOLID enough?

WHY SOLID?• Dirty code detector.

• Is the code human readable?

• Because your code will be read by humans, it should be meaningful code.

• In order to make your method name meaningful, don’t hesitate to use a long name such as Is ValidForCharactersOnly

• Visit your code and see if you can read it. If not, that means you are writing bad code.

• Is the code duplicated?

• Create a Common class if you can’t decide where to place your common code

• avoid and remove any redundant code

• It’s a good idea to visit your code many times, and in different ways, in order to check for redundancy

• For example, you can write Console.WriteLine("SOLID Principles Succinctly!"); instead of System.Console.WriteLine("SOLID Principles Succinctly!"); if you have already added ‘namespace.’ In this case, ‘System’ is redundant and can be removed.

Page 8: Is your code SOLID enough?

WHY SOLID?

• Dirty code detector.• Is the code too lengthy to understand?

• Avoid writing lengthy code.

• A function can be hard to understand if it contains thousands of lines.

• Lengthy code caused hard to understand especially for new Developers.

• We can mark our code as bad code if we are writing lengthy functions or methods when we could instead break them into small and meaningful functions.

Page 9: Is your code SOLID enough?
Page 10: Is your code SOLID enough?
Page 11: Is your code SOLID enough?

SOLID UNDERSTANDING• SOLID is a set of design principles, and these principles help a programmer write better code

Page 12: Is your code SOLID enough?

SOLID UNDERSTANDINGDESIGN PATTERNS VS. DESIGN PRINCIPLES

Page 13: Is your code SOLID enough?

SOLID UNDERSTANDINGDESIGN PATTERNS VS. DESIGN PRINCIPLES

Page 14: Is your code SOLID enough?

SOLID UNDERSTANDINGPRINCIPLES OF OBJECT-ORIENTED DESIGN (OOD)

Robert C. Martin introduced the underlying concepts of SOLID in 1995 with his 11 commandments of object-oriented programming (OOP).

Page 15: Is your code SOLID enough?

SOLID UNDERSTANDINGPRINCIPLES OF OBJECT-ORIENTED DESIGN (OOD)

Page 16: Is your code SOLID enough?

SOLID UNDERSTANDING• SOLID principles are neither laws nor rules—they are principles intended to help us to write neat code. By following

SOLID principles, our code can be easily extended and maintained

• Single Responsibility Principle

• A class should have only one responsibility. Let’s say our class is responsible for saving data. That means it should not also be responsible for retrieving data or any other tasks.

• Open-Closed Principle

• Once a class has been written, it should not allow anyone to make changes. No one should be able to go back and amend the class code in order to implement new functionalities.

• Liskov Substitution Principle

• A dependent object should be able to use any object of type parent object.

• Interface Segregation Principle

• A smaller interface is recommended. If an interface has one method, there will be only one place to change if we need to change the code. However, in the case of interfaces with more methods, there might be more reasons for change.

• Dependency Inversion Principle

• Put simply, this addresses loose coupling. With the help of DIP, we can write code that does not depend upon concrete classes.

Page 17: Is your code SOLID enough?

THANK YOU

TO BE CONTINUE….. IS YOUR CODE SOLID ENOUGH?PART 2 : Single Responsibility Principle