Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
SOLID Design Principles in Smalltalk coding
The SOLID in SOLID Design Principles is an acronym or mnemonic for five basic patterns of object oriented design.
The object-oriented nature of coding in Smalltalk makes it straightforward to apply each principle, providing a basic framework for designing new classes. This is especially useful when working on group projects and a standardized system for creation of classes and interaction between classes is needed and isn't immediately obvious.
The following definitions are obtained from wikipedia http://en.wikipedia.org/wiki/Solid_(object-oriented_design)
SRP : Single Responsibility Principle
- The notion that an object should have only a single responsibility.
- Basically, when designing a class, such as a User class, it only does one thing, such as holding data, or communicating with another class. When working with CRC cards, this means trying to make a class have only one stereotype, such as 'data holder'.
OCP : Open/Closed Principle
- The notion that “software entities … should be open for extension, but closed for modification”.
- Design a barebones framework first, where there is almost no functionality, but every class interacts completely with one another. Then, these classes can be extended with subclasses that add extra functionality to the system. The goal is to design the original framework such that it never needs to be modified.
LSP : Liskov Substitution Principle
- The notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”.
- Continuing on with the barebones framework, each subclass should be built such that they can act as their superclass in interactions with other classes. So if there were a System class which contains a list of Users, and there is a Guest class which is a subclass of the User class, it can be included in the System class's list and compared with other Users as though it were a User.
ISP : Interface Segregation Principle
- The notion that “many client specific interfaces are better than one general purpose interface.”
- Separate classes as much as possible, continuing on the 1st 3 principles, the goal is simplicity and separation of roles.
- This is most important in a team settings, where there is need for concurrent modification of classes, it is important to create multiple standardized interfaces so that classes are not tangled with one another, rendering it difficult to modify and merge work done between team members.
DIP : Dependency Inversion Principle
A problem that can occur in team projects is classes picking up method parameters & variables that are were defined after creation in subclasses. Doing this causes problems in all dependent classes & most probably a repeating cycle of debugging.
- The notion that one should “Depend upon Abstractions. Do not depend upon concretions.” Dependency injection is one method of following this principle.
- When designing a project in Smalltalk, it is important to make sure that data and information flows in one direction.
To avoid this it is important to make sure that high-level modules should not depend on low-level modules, but instead on abstractions. These abstractions do not depend on details, instead the details or complications should extend on the absrtactions.
Links to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu
- Index of Individual Cases last edited on 3 May 2011 at 12:46 pm by r52h48.res.gatech.edu