- #VIOLATION OF SINGLE RESPONSIBILITY PRINCIPLE SOFTWARE#
- #VIOLATION OF SINGLE RESPONSIBILITY PRINCIPLE CODE#
Instead, as demonstrated in the good example, we have a high-level Greeter class that is instantiated with some Personality.
#VIOLATION OF SINGLE RESPONSIBILITY PRINCIPLE CODE#
We don't want to have to modify our existing, working code to add something new. Notice how in the bad example, any time we want to add a new style of greeting, we have to change the Greeter class to accept a new type of personality. I find the Strategy Pattern a great demonstration of the open/closed principle.
#VIOLATION OF SINGLE RESPONSIBILITY PRINCIPLE SOFTWARE#
Software entitites should be open for extension, but closed for modification They are also only passed attributes they need for example, BoardShaper objects are initialized with only a size (they don't need the whole board). The BoardShaper and BoardPresenter classes are similarly focused on specific tasks. It is entirely unconcerned with how those spots are being manipulated per the rules of Tic Tac Toe (rows, columns, diagonals) or displayed to the user (in a console, on the web, etc.). The only thing it is responsible for is knowing the values of its spots.
On the surface, everything seems legitimately related to a real-world Board object, but the Single Responsibility Principle tells us that this class is actually handling far too many responsibilities.Ĭonsider the Board class in the "good" example. This approach reminds me of models in many Rails apps. The bad example provides a generic Board class that does board-related things-it stores the values of spots on the board, returns the board's rows, and prints the board out to the screen. This example is derived from a Tic Tac Toe game. There should never be more than one reason for a class to change. Single Responsibility PrincipleĮvery class should have a single responsibility. Each example has a "good" and "bad" version to demonstrate adherence to and violation of the principle, respectively.īased on work originally found at. This repository contains examples of the five SOLID design principles of object-oriented programming.
0 kommentar(er)
