general responsibility assignment software patterns

System Design Tutorial
What is System Design
System Design Life Cycle
High Level Design HLD
Low Level Design LLD
Design Patterns
UML Diagrams
System Design Interview Guide
Crack System Design Round
System Design Bootcamp
System Design Interview Questions
Microservices
Scalability
Object-Oriented Analysis and Design(OOAD)
OOAD Full Form
Object Oriented Analysis in Object Oriented Analysis & Design
Object Oriented Paradigm in Object Oriented Analysis & Design(OOAD)
Object Oriented System | Object Oriented Analysis & Design
Object Model | Object Oriented Analysis & Design
Object Oriented Principles in OOAD
What are the Object Oriented Analysis and Design(OOAD) Phases?
Booch Methodology in Object-Oriented Analysis and Design(OOAD)

GRASP Design Principles in OOAD

Aggregation in OOAD
Unified Process in OOAD

In Object-Oriented Analysis and Design (OOAD) , General Responsibility Assignment Software Patterns (GRASP) play a crucial role in designing effective and maintainable software systems. GRASP offers a set of guidelines to aid developers in assigning responsibilities to classes and objects in a way that promotes low coupling, high cohesion, and overall robustness. By understanding and applying GRASP principles, developers can create software solutions that are flexible, scalable, and easier to maintain over time.

Important Topics for GRASP Design Principles in OOAD

What are GRASP Principles?

Importance in ooad, grasp principles and their examples, benefits of grasp, challenges of grasp.

GRASP, which stands for General Responsibility Assignment Software Patterns, includes several principles that guide the allocation of responsibilities in object-oriented design. These principles include:

Creator: Assign the responsibility of creating instances of a class to the class that has the most knowledge about when and how to create them.
Information Expert: Assign a responsibility to the class that has the necessary information to fulfill it, promoting high cohesion and minimizing coupling.
Low Coupling: Aim for classes to have minimal dependencies on each other, facilitating easier maintenance and flexibility in the system.
High Cohesion: Ensure that the responsibilities within a class are closely related and focused, enhancing readability, maintainability, and reusability.
Controller: Assign the responsibility of handling system events or coordinating activities to a controller class, promoting centralized control and avoiding cluttered classes.
Pure Fabrication: Introduce new classes to fulfill responsibilities without violating cohesion and coupling principles, promoting cleaner and more maintainable designs.
Indirection: Use intermediaries or abstractions to decouple classes and promote flexibility in design.
Polymorphism: Utilize inheritance and interfaces to enable multiple implementations of behaviors, allowing for flexible and extensible systems.

By applying these GRASP principles, developers can create object-oriented designs that are robust, maintainable, and adaptable to changing requirements.

In Object-Oriented Analysis and Design (OOAD), GRASP principles hold significant importance as they provide a framework for designing systems with clarity, flexibility, and maintainability. Here’s why they are essential:

Clarity of Design: GRASP principles help in organizing classes and responsibilities in a way that makes the design more understandable. Clear responsibilities assigned to classes make it easier for developers to comprehend the system’s architecture.
Low Coupling, High Cohesion: GRASP encourages low coupling between classes, meaning that classes are less dependent on each other. This leads to more modular and reusable code. Additionally, high cohesion ensures that each class has a clear and focused purpose, making the system easier to maintain and modify.
Flexible Design: By following GRASP principles such as Indirection and Polymorphism, the design becomes more flexible and adaptable to changes. Indirection allows for the introduction of intermediaries, which can simplify complex interactions, while Polymorphism enables the use of multiple implementations for behaviors, facilitating extensibility.
Scalability : GRASP principles contribute to the scalability of the system by promoting a design that can accommodate future changes and enhancements without significant refactoring. This scalability is vital as systems evolve and grow over time.
Ease of Maintenance: With clear responsibilities assigned to classes and well-defined relationships between them, maintaining the system becomes more straightforward. Developers can quickly identify where changes need to be made and can do so without inadvertently affecting other parts of the system.

General Responsibility Assignment Software Patterns (GRASP) are a set of guidelines used in Object-Oriented Analysis and Design (OOAD) to assign responsibilities to classes and objects effectively. Let’s explore each principle in depth with an example scenario:

Assign the responsibility for creating instances of a class to the class itself or to a related factory class.

For Example:

Consider a scenario where you are designing a system for managing a library. In this system, when a new book is added to the library, a `Book` object needs to be created. The responsibility for creating `Book` objects should lie with a class like `Library` or a separate `BookFactory` class. This ensures that the logic for creating `Book` objects is centralized and encapsulated, making it easier to manage.

2. Information Expert

Assign a responsibility to the class that has the necessary information to fulfill it.

Continuing with the library management system, when a user wants to borrow a book, the responsibility of checking if the book is available should lie with the `Book` class itself. The `Book` class contains information about its availability and can perform the necessary checks without needing to rely on other classes. This promotes high cohesion and reduces coupling between classes.

3. Low Coupling

Aim for classes to have minimal dependencies on each other.

In the library management system, suppose there is a `LibraryCatalog` class responsible for managing the catalog of books. Instead of directly accessing the `Book` class to check availability, the `LibraryCatalog` class can rely on an interface, such as `Searchable`, implemented by `Book`. This way, `LibraryCatalog` remains loosely coupled with `Book`, allowing for easier maintenance and changes.

4. High Cohesion

Ensure that responsibilities within a class are closely related and focused.

In the library management system, the `Book` class should have cohesive responsibilities related to managing book details, such as title, author, and availability. Responsibilities unrelated to book management, such as user authentication, should be handled by separate classes. This ensures that each class is focused on a specific aspect of the system, promoting clarity and maintainability.

5. Controller

Assign the responsibility of handling system events or coordinating activities to a controller class.

In a web application for a library, when a user requests to borrow a book, the responsibility of handling this request and coordinating the necessary actions should lie with a `BorrowBookController` class. This controller class would interact with other classes, such as `Book`, `User`, and `Library`, to facilitate the borrowing process. By centralizing control logic in a controller class, the system becomes more organized and easier to manage.

6. Pure Fabrication

Introduce new classes to fulfill responsibilities without violating cohesion and coupling principles.

Suppose the library management system needs to send email notifications to users when they borrow or return books. Instead of adding email sending logic directly to the `Book` or `User` classes, a separate `NotificationService` class can be created. This `NotificationService` class acts as a pure fabrication responsible for sending email notifications, maintaining low coupling and high cohesion in the system.

7. Indirection

Use intermediaries or abstractions to decouple classes and promote flexibility in design.

In the library management system, if multiple classes need to access book information, an `BookRepository` interface can be introduced. Classes that need access to book data can depend on the `BookRepository` interface rather than directly on the `Book` class. This allows for flexibility in how book information is retrieved, facilitating easier changes and adaptations in the future.

8. Polymorphism

Utilize inheritance and interfaces to enable multiple implementations of behaviors.

Continuing with the library management system, suppose there are different types of books, such as `FictionBook` and `NonFictionBook`, each with its own borrowing rules. By defining a common interface, `Book`, and implementing it in the `FictionBook` and `NonFictionBook` classes, polymorphism allows the borrowing process to be handled uniformly regardless of the book type. This promotes code reuse and simplifies the handling of different book types within the system.

GRASP (General Responsibility Assignment Software Patterns) offers several benefits in Object-Oriented Analysis and Design (OOAD), contributing to the development of robust and maintainable software systems such as:

Clarity and Understandability: GRASP principles provide a clear and structured approach to assigning responsibilities to classes and objects. This clarity enhances the overall understandability of the system’s design, making it easier for developers to grasp the architecture and functionality.
Flexibility and Adaptability: By adhering to GRASP principles such as Low Coupling, High Cohesion, and Polymorphism, designs become more flexible and adaptable to changes in requirements. The modular and loosely coupled nature of the system allows for easier modification and extension without causing widespread ripple effects.
Promotion of Best Practices: GRASP encapsulates best practices and design guidelines derived from years of experience in software engineering. By following these principles, developers can ensure that their designs adhere to industry standards and best practices, leading to higher-quality software.
Maintainability and Scalability : GRASP promotes designs that are easier to maintain and scale. Clear responsibilities assigned to classes and objects facilitate maintenance activities such as debugging, refactoring, and adding new features. Additionally, the modular nature of GRASP designs allows for seamless scalability as the system grows and evolves over time.
Enhanced Reusability: GRASP principles encourage the creation of classes and objects with well-defined responsibilities and interfaces. This promotes code reusability, as components can be easily reused in different parts of the system or in entirely new projects, leading to increased productivity and reduced development time.

While GRASP (General Responsibility Assignment Software Patterns) offers numerous benefits, it also presents some challenges that developers may encounter during the design and implementation phases of software development:

Complexity: Applying GRASP principles effectively requires a deep understanding of object-oriented design concepts and practices. For developers who are new to these principles or lack experience in OOAD, grasping and implementing GRASP patterns can be challenging, leading to potential design complexities and errors.
Subjectivity: Determining the most appropriate responsibility assignment for classes and objects can be subjective and open to interpretation. Different developers may have varying perspectives on how to apply GRASP principles to a given problem, which can result in inconsistencies or disagreements within a development team.
Trade-offs: While GRASP aims to promote desirable design qualities such as low coupling, high cohesion, and flexibility, achieving these qualities often involves making trade-offs. For example, optimizing for low coupling may increase the complexity of communication between classes, while optimizing for high cohesion may lead to larger and more tightly coupled classes.
Context Sensitivity: GRASP principles are not one-size-fits-all solutions and must be adapted to the specific context of each software project. What works well for one project may not be suitable for another, depending on factors such as project size, domain complexity, team expertise, and development constraints.
Maintenance Overhead: While GRASP designs aim to enhance maintainability, poorly applied patterns or overly complex designs can actually increase maintenance overhead. Developers may struggle to understand and modify intricate designs, leading to higher costs and effort associated with maintenance tasks.

Please Login to comment...

OOAD - Object Oriented Analysis and Design
System Design
How to Delete Whatsapp Business Account?
Discord vs Zoom: Select The Efficienct One for Virtual Meetings?
Otter AI vs Dragon Speech Recognition: Which is the best AI Transcription Tool?
Google Messages To Let You Send Multiple Photos
30 OOPs Interview Questions and Answers (2024)

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

GRASP - General Responsibility Assignment Software Patterns Explained

Introduction

I recently noticed that a lot of attention is paid to SOLID principles. And this is very good thing because it is the total basis of Object-Oriented Design (OOD) and programming. For developers of object-oriented languages, knowledge of the SOLID principles is a requirement for writing code which is characterized by good quality. There are a lot of articles and courses on these rules, so if you do not know them yet, learn them as soon as possible.

On the other hand, there is another, less well-known set of rules regarding object-oriented programming. It’s called GRASP - General Responsibility Assignment Software Patterns (or Principles). There are far fewer materials on the Internet about this topic, so I decided to bring it closer because I think the principles described in it are as important as the SOLID principles.

Disclaimer : This post is inspired and based on awesome Craig Larman’s book: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development . Although the last edition was released in 2004, according to me, the book is still up-to-date and explains perfectly how to design systems using object-oriented languages. It’s hard to find the better book about this subject, believe me. It is not book about UML , but you can learn UML from it because it is good explained too. Must-have for each developer, period.

The Responsibility in Software

Responsibility in software is a very important concept and not only concerns classes but also modules and entire systems. Thinking in terms of responsibilities is popular way to think about design of the software. We can always ask questions like:

What is the responsibility of this class/module/component/system?
Is it responsible for this or is it responsible for that ?
Is Single Responsibility Principle violated in this particular context?

But to answer these kind of questions we should ask one, more fundamental question: what does it mean that something is responsible in the context of the software?

Doing and Knowing

As it is proposed by Rebecca Wirfs-Brock in Object Design: Roles, Responsibilities, and Collaborations book and her RDD approach a responsibility is:

An obligation to perform a task or know information

As we see from this definition we have here a clear distinction between behavior (doing) and data (knowing) .

Doing responsibility of an object is seen as:

a) doing something itself - create an object, process data, do some computation/calculation b) initiate and coordinate actions with other objects

Knowing responsibility of an object can be defined as:

a) private and public object data b) related objects references c) things it can derive

Let’s see an example:

If you want more information about responsibilities in software and dig into Responsibility-Driven Design you can read it directly from Rebecca’s Wirfs-Brock book or this PDF .

Ok, now we know what the responsibility in context of software is. Let’s see how to assign this responsibility using GRASP .

GRASP is set of exactly 9 G eneral R esponsibility A ssignment S oftware P atterns. As I wrote above assignment of object responsibilities is one of the key skill of OOD . Every programmer and designer should be familiar with these patterns and what is more important - know how to apply them in everyday work (by the way - the same assumptions should apply to SOLID principles).

This is the list of 9 GRASP patterns (sometimes called principles but please, do not focus on naming here):

Information Expert
Low Coupling
High Cohesion
Indirection
Polymorphism
Pure Fabrication
Protected Variations

NOTE : All Problem/Solution paragraphas are quotes from Craig Larman’s book. I decided that it would be best to stick to the original.

1. Information Expert

Problem: What is a basic principle by which to assign responsibilities to objects? Solution: Assign a responsibility to the class that has the information needed to fulfill it.

In following example Customer class has references to all customer Orders so it is natural candidate to take responsibility of calculating total value of orders:

This is the most basic principle, because the truth is - if we do not have the data we need, we would not be able to meet the requirement and assign responsibility anyway.

Problem: Who creates object A?

Solution: Assign class B the responsibility to create object A if one of these is true (more is better):

B contains or compositely aggregates A
B records A
B closely uses A
B has the initializing data for A

Going back to the example:

As you can see above Customer class compositely aggregates Orders (there is no Order without Customer), records Orders, closely uses Orders and has initializing data passed by method parameters. Ideal candidate for “Order Creator”. :)

3. Controller

Problem: What first object beyond the UI layer receives and coordinates “controls” a system operation?

Solution: Assign the responsibility to an object representing one of these choices:

Represents the overall “system”, “root object”, device that the software is running within, or a major subsystem (these are all variations of a facade controller)
Represents a use case scenario within which the system operation occurs (a use case or session controller)

This principle implementation depends on high level design of our system but general we need always define object which orchestrate our business transaction processing. At first glance, it would seem that the MVC Controller in Web applications/API’s is a great example here (even the name is the same) but for me it is not true. Of course it receives input but it shouldn’t coordinate a system operation - it should delegate it to separate service or Command Handler:

4. Low Coupling

Problem: How to reduce the impact of change ? How to support low dependency and increased reuse ?

Solution: Assign responsibilities so that (unnecessary) coupling remains low. Use this principle to evaluate alternatives.

Coupling is a measure how one element is related to another. The higher the coupling, the greater the dependence of one element to the another.

Low coupling means our objects are more independent and isolated. If something is isolated we can change it not worrying that we have to change something else or wheter we would break something (see Shotgun Surgery ). Use of SOLID principles are great way to keep coupling low. As you see in example above between CustomerOrdersController and AddCustomerOrderCommandHandler coupling remains low - they need only agree on command object structure. This low coupling is possible thanks to Indirection pattern which is described later.

5. High Cohesion

Problem: How to keep objects focused, understandable, manageable and as a side effect support Low Coupling? Solution: Assign a responsibility so that cohesion remains high. Use this to evaluate alternatives.

Cohesion is a measure how strongly all responsibilities of the element are related. In other words, what is the degree to which the parts inside a element belong together.

Classes with low cohesion have unrelated data and/or unrelated behaviors. For example, the Customer class has high cohesion because now it does only one thing - manage the Orders . If I would add to this class management of product prices responsibility, cohesion of this class would drop significantly because price list is not directly related to Customer itself.

6. Indirection

Problem: Where to assign a responsibility to avoid direct coupling between two or more things?

Solution: Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled.

This is where Mediator Pattern comes in to play. Instead of direct coupling:

We can use the mediator object and mediate between objects:

One note here. Indirection supports low coupling but reduces readability and reasoning about the whole system. You don’t know which class handles the command from the Controller definition. This is the trade-off to take into consideration.

7. Polymorphism

Problem: How handle alternatives based on type?

Solution: When related alternatives or behaviors vary by type (class), assingn responsibility for the behavior (using polymorphi operations) to the types for which the behavior varies.

Polymorphism is fundamental principle of Object-Oriented Design. In this context, principle is strongly connected with (among others) Strategy Pattern .

As it was presented above constructor of Customer class takes ICustomerUniquenessChecker interface as parameter:

We can provide there different implementations of this interface depending on the requirements. In general, this is very useful approach when we have in our systems different algorithms that have the same input and output (in terms of structure).

8. Pure Fabrication

Problem: What object should have the responsibility, when you do not want to viloate High Cohesion and Low Coupling but solutions offered by other principles are not appopriate?

Solution: Assign a highly cohesive set of responsibilites to an artifical or convenience class that does not represent a problem domain concept .

Sometimes it is realy hard to figure it out where responsibility should be placed. This is why in Domain-Driven Design there is a concept of Domain Service . Domain Services hold logic which are not related with one, particular Entity .

For example, in e-commerce systems we often have need to convert one currency to another. Sometimes it is hard to say where this behavior should be placed so the best option is to create new class and interface:

This way we support both High Cohesion (we are only converting currencies) and Low Coupling (client classes are only dependent to IForeignExchange interface). Additionally, this class is reusable and easy to maintain.

9. Protected Variations

Problem: How to design objects, subsystems and systems so that the variations or instability in these elements does not have an undesirable impact on other elements?

Solution: Identify points of predicted variation or instability, assign responsibilities to create a stable interface around them.

In my opinion, this is the most important principle which is indirectly related to the rest GRASP principles. Currently, one of the most important software metrics is the ease of change . As architects and programmers we must be ready for ever-changing requirements. This is not optional and “nice to have” quality attribute - it is “must-have” and our duty .

Fortunately, we are armed with a lot design guidelines, principles, patterns and practices to support changes on different levels of abstraction. I will mention only a few (already beyond the GRASP):

SOLID principles, especially the Open-Close principle (but all of them supports change)
Gang of Four (GoF) Design Patterns
Encapsulation
Law of Demeter
Service Discovery
Virtualization and containerization
asynchronous messaging, Event-driven architectures
Orchestration , Choreography

As Protected Variations principle says, first step is to identify points of predicted variation or instability . This is often very difficult because we sometimes don’t really know what would change and when. This is why iterative software development process is more suitable today because even we are forced to change something once, we can draw conclusions and be prepared for future changes at a lower cost.

Fool me once shame on you. Fool me twice shame on me.

In this post I described one of the most fundamental Object-Oriented Design set of patterns and principles - GRASP .

Skilful management of responsibilities in software is the key to create good quality architecture and code. In combination with others patterns and practices is it possible to develop well-crafted systems which supports change and do not resist it. This is good, because the only thing that is certain is change. So be prepared.

About Jonathan Boccara

Hello, my name is Jonathan Boccara, I'm your host on Fluent C++. I have been a developer for 10 years. My focus is on how to write expressive code . I wrote the book The Legacy Code Programmer's Toolbox . I'm happy to take your feedback, don't hesitate to drop a comment on a post, follow me or get in touch directly !

Jonathan Boccara's blog

GRASP: 9 Must-Know Design Principles for Code

In order to write code that is understandable, maintainable and that stands the test of time, one of the crucial skills that we all need to have is design .

What does code design mean? In my definition, doing code design means deciding which class (or more generally which component) is in charge of which responsibility.

The reason why this is so crucial is because, according to the above definition, code that is well designed is consistent and well organised, and code that is poorly designed is essentially a mess.

And understanding, adding or fixing something in a well organised structure is, as you can imagine, easier that in a mess.

The need for Patterns

Being able to decide where to assign any given responsibility is a make-or-break skill for your code. But how do we do that?

With Experience, of course!

After years of trials and errors, after paying the high prices of your design mistakes, after living in a messy code, you will end up realizing that some design choices tend to work better than others.

Or there is an easier way: capitalizing on the experience of others.

The question of choosing where to assign a responsibility in code has been around for decades, and has been thought over by thousands and thousands of developers in their day-to-day code. Probably thousands and thousands of mistakes have been made, and as many lessons have been drawn from those mistakes.

If we could benefit from this std::accumulate d experience, then we would stand on the shoulders of giants.

Luckily for us, a lot of this wisdom is available to us, and what’s more, synthesized into manageable bits that we can apply in our everyday life while coding: design principles .

Design principles are guidelines that help us take the right decisions when assigning responsibilities in our code.

There is a set of 9 such design principles: the GRASP principles .

The book where I learnt the design principles

GRASP stands for General Responsibility Assignment Software Principles. I think the words that carry the most meaning in this acronym are RA: Responsibility Assignment . This is exactly what we’re talking about.

I learnt those principle in Craig Larman’s book Applying UML and Patterns :

Even though the book title mentions UML, the book is about object-oriented design in general, as Martin Fowler praised (this is on the book cover): “People often ask me which is the best book to introduce them to the world of OO design. Ever since I came across it, Applying UML and Patterns has been my unreserved choice.”

I recommend that you read at least the parts about the GRASP patterns in this book, if not all of it.

Let me go further: even if you should read both, I think that GRASP principles are a more useful reading than the popular GoF design patterns .

Why such a bold statement?

The GRASP principles will let you understand the rationale behind the GoF design patterns,
Some GoF design patterns are obscure and not used often (at least in my experience, take the “Bridge” pattern for example),
Some GoF patterns should be avoided most of the time (for example the “Singleton” pattern, which is essentially a global variable with no copy constructor),
You can apply the GRASP pattern to other things than classes. And with free functions being idiomatic to C++, this is particularly relevant for C++ developers.

Ssome of the GoF design patterns are indeed necessary to know (“Strategy” for example), so you should also read the GoF book (especially since it contains more than just a design patterns catalogue). But to me, GRASP is a more fundamental topic to read about.

The GRASP patterns

Let’s see what the 9 GRASP patterns are. I’ll make a brief summary of each one, and you can refer to the above book for more detailed discussions and examples.

Information expert

Let’s start by one that is quite natural: information expert . This principle recommends that if you have an operation to do, and this operations needs inputs, then you should consider putting the responsibility of carrying out this operation in the class that contains the inputs for it.

This helps keeping the data local, because if you put the operation somewhere else then the inputs will have to be carried over there, creating a relationship between the class that holds the input data (the “information expert”) and that new place. This would create coupling and be detrimental for encapsulation, thus creating complexity.

Granted, it’s a natural thing to do. But formalizing this as a principle still has several benefits. For example, if you feel that a design is not quite right, thinking about the information expert principle can help you pinpoint what was disturbing you in it. Also, it helps expressing your remarks in a code review.

The Creator principle gives guidelines as to which class B should be in charge of creating a certain type of objects A. The principle contains a set of rules, such as:

B contains or aggregates instances of A
B closely uses A
B has the inputs to construct A

The more rules are fulfilled, the better B is suited to instantiate objects of type A.

This goes a further than Information expert: it’s not just about having the input of the operation of construction, it’s about being “close” to the operation.

If you put together two part of the code that are semantically close (the construction of A, and the code that works a lot with A), then they become easier to reason about than if they were far apart.

Low coupling

Coupling happens between two parts of the code when one depends on the other. Coupling introduces complexity, if only because the code can then no longer be understood isolation.

Such dependencies can be explicit, in terms of a function call for example, and that’s unavoidable and often OK.

But other types of coupling are less sane and less visible, for example when a part of the code expects that another part has set a data member to a certain value.

The design principle of low coupling encourages to keep coupling low, and it can help in particular to choose between two designs: select the one that introduces the lower amount of coupling.

For more details about the various types of coupling and the various types of problems that coupling generates, refer to this dedicated article on coupling .

Protected variations

The principle of Protected variations is related to the one of Low coupling, because it helps reducing the impacts of the changes of the code of one part A on another part B. The code of part B is protected against the variations of the code of part A, hence the name of the pattern.

How do you achieve such a protection? By organizing the responsibilities around stable interfaces .

This is particularly relevant for code that tends to change often. Introducing an interface between this unstable part of the code and the rest of the codebase helps limiting the rippling effects of those frequent changes.

The principle of protected variations is, according to my understanding, very close to the concept of “anti-corruption layer” from Domain Driven Design .

Indirection

The Indirection pattern is another way to reduce coupling by creating an intermediary class (or any kind of component) between two classes A and B. This way, the changes in each one of A and B don’t affect the other one. The intermediary class absorbs the impact by adapting its code rather than A or B (or more other classes).

This relates a lot to the Adapter design pattern, even though the Adapter design pattern is rather made to connect two existing incompatible interfaces. But it also has the effect of protecting each one against the changes of the other.

Indirection looks a bit like Protected variations, as they both introduce a layer between components in order to reduce coupling.

According to my understanding, the difference between Protected variations and Indirection is that Protected variations is about designing interfaces in the existing components, whereas Indirection is about introducing a new component in the middle.

Polymorphism

The Polymorphism principle is an exhortation to use… polymorphism in your code.

Polymorphism is often seen as having a base class with virtual methods that defines an interface, and derived classes implementing this interface, but this is only one type of polymorphism. There are plenty of types of polymorphism (including templates for example) and I hope we’ll get to dive into this topic at some point on Fluent C++.

The usage for polymorsphism is when there are several ways to accomplish a task, and you want to decouple the clients of this task from the various pieces of code that implement the various ways to perform it.

The Polymorphism principle is very close to the GoF Strategy pattern, if not identical. It contributes to the Low Coupling principle.

High cohesion

The principle of High cohesion encourages to focus classes around one responsibility, and to have all its components oriented towards achieving this responsibility. This is the principle of “do one thing and do it well”.

The principle of high cohesion also applies to other elements of the code, such as functions, and also modules and systems.

This ties back well with the idea of having a well-organized code: a highly cohesive component lets you label it in your mind with “this is the part of the code that does X”. This allows better mental abstractions as well as code abstractions .

Pure fabrication

It is natural to represent in our code objects that map the reality of the domain that we’re trying to model. For example, if you’re working on a financial application, you can probably expect to encounter some classes called Transaction or Portfolio in the code.

But sometimes you have a responsibility to assign, and it seems to not fit well in any domain class. And according to the principle of High cohesion above, you shouldn’t force a responsibility into a class that is already doing something else.

That’s when the principle of Pure fabrication comes into play: create a class that does not map to a domain object, and let it achieve this new responsibility in a cohesive way.

This principle is probably one of the hardest to guess, because it goes against our natural tendency to write code that represents the problem we’re trying to solve.

Here is an example of a pure fabrication: a UI Controller . This is such a common pattern that it was included in the 9 GRASP principles. Personal opinion: I would have kept this as an example of pure fabrication and not made a principle out of it.

The controller is the first non-UI component that receives the UI event and organizes the operations to react to this event. Indeed, that doesn’t map to any domain object, even if the UI itself can display domain concepts.

There are also other examples of pure fabrications in the GoF design patterns: for example, a Facade object is a pure fabrication.

Some principles are more fundamental than others

These were the 9 GRASP principles:

Those principles are not all of the same type. Some of those are overarching principles of good design. Some are techniques to put those principles into practice. Some are merely examples.

Also, they relates to some GoF design patterns, sometimes closely and sometimes the GoF patterns are implementations of the GRASP patterns.

In the next post, we will try to relate the GRASP patterns together.

Search form

Introduction to grasp design patterns in object-oriented design.

GRASP stands for General Responsibility Assignment Software Patterns (or Principles). GRASP consist of guidelines for assigning responsibility to classes and objects in object-oriented design.

The different patterns and principles used in GRASP are: controller , creator , indirection, information expert , high cohesion , low coupling , polymorphism, protected variations, and pure fabrication.

We will not discuss GRASP Patterns in detail now, but it is useful to know that these patterns or principles are out these. Important ones are bolded above.

Below are some of the resources where you can read more about the GRASP pattern.

en.wikipedia.org/wiki/GRASP_(object-oriented_design)

study.com/academy/lesson/grasp-design-patterns-in-object-oriented-design.html

Note: You may discuss any questions here as comments or in the Forum. You may also submit more resources.

heartin's blog
Log in or register to post comments

Partners and Platforms

We learn together, do innovations and then document them.

Follow us on:

Business newsletter.

Complete the form below, and we'll send you an e-mail every now and again with all the latest news.

About Cloudericks

Team Cloudericks is a community to learn about and master cloud computing. Current learning focus is on AWS cloud.

We believe that knowledge is useless unless you share it; the more you share, the more you learn. Visit Cloudericks .

Partner Sites

CloudMaterials
Cloudericks
Heartin.life
CriticsCloud

Photo Stream

Software Modelling and Design

Table of contents, grasp: overview and interrelationship, responsibilities, information expert, low coupling, high cohesion, polymorphism, pure fabrication, indirection, protected variations, liskov substitution principle, don’t talk to strangers.

General Responsibility Assignment Software Patterns
pattern : named and well-known problem and solution that can be applied to new contexts, providing guidance for assessing trade-offs

Benefits of patterns

capture expertise in an accessible, standardised manner
facilitate reuse of applying expertise
improve understandability and communication, by operating in a common language
inspiration for new solutions based on modifying existing patterns
responsibility : contract/obligation
do something itself, e.g. create an object, perform a calculation
initiate action in other objects
control/coordinate activities in other objects
know about private encapsulated data
know about related objects
know about things it can derive/calculate
low representational gap : domain model can be used to inspire knowing responsibilities
granularity : big responsibilities may take hundreds of classes/methods, while small ones may take a single method
responsibilities are distinct from methods: responsibilities are an abstraction, but methods fulfill responsibilities

collaboration : responsibiilities may involve multiple objects working together to fulfill a responsibility

Responsibility Driven Design: way to think about assigning responsibilities in OO software design, where the design comprises a community of collaborating responsible objects

Problem: who should be responsible for object creation?

Solution: Assign class B responsibility to create class A if:

B contains/aggregates A
B records A
B closely uses A
B has initialising data for A

The more of these that hold, the stronger the implication.

Benefits: Low coupling

Contraindications:

complex object creation, e.g. from a family of classes. Instead delegate to Factory

Problem: How to decide which class to assign a responsibility to?

Assign X the responsibility if X has the necessary information

Benefits: classes are

understandable
maintainable
the solution suggested by Information Expert may introduce problems with coupling and cohesion

Problem: how to support low dependency, low change impact, and increased reuse?

assign responsibilities such that coupling remains low.
use this to differentiate alternatives
coupling: degree of connection to other elements (whether knowledge/reliance on)

Benefits: code becomes

high coupling can be okay with stable code, e.g. standard libraries

Problem: How to keep objects focused, understandable, manageable, while suppporting low coupling?

functional cohesion: how strongly related and focused the responsibilities of an element are
low cohesion: class performs too many unrelated tasks. Code is hard to comprehend, reuse, maintain
choose between alternatives by assigning the reponsibility to X for maximum cohesion
easy to comprehend
non-functional requirements may require low cohesion, e.g. reduce processing overheads in high- performance computing

Problem: What first object beyond the UI layer receives and coordinates (i.e. controls) system operation?

facade controller: assign responsibility to a class representing the overall system
use case/session controller: assign responsibility to a class representing a use case scenario that deals with the event, named something like <UseCaseName><Handler|Coordinator|Session>

Benefits: prevent coupling between UI and application logic

break facade controller into multiple use case controllers
delegate work to other objects: only handle control in the controller itself

Bad coupling of UI to domain layer

Better UI coupling with controller

conditional variation using switch-case statements requires heavy modification when new alternatives are added
viewing components in a client-server relationship, how can you replace a server component without affecting the client?

Solution: when related alternatives/behaviours vary by type (class), assign responibility for the behaviour using polymorphic operations to the types (classes) for which the behaviour varies.

i.e. give the same name to services in different objects
i.e. inheritance with generalisation/specialisation, or interfaces

Corollary: avoid testing the type of an object as part of conditional logic to perform varying alternatives based on type (class).

Guideline: unless there is a default behaviour in the superclass, declare a polymorphic operation in the superclass to be abstract .

Guideline: when should you consider using an interface?

introduce one when you want to support polymorphism without being committed to a class hierarchy
easy extension of code: you can introduce new implementations without affecting clients
avoid premature optimisation: consider future proofing with respect to realistic likelihood of variability before investing time in increased flexibility.

Problem: what object should have a responsibility, where you don’t want to violate high cohesion/low coupling, etc., but guidance from Expert etc. is not appropriate?

Solution: assign a highly cohesive set of responsibilities to an artificial/convenience class that doesn’t exist in the problem domain.

high cohesion
reuse potential
overuse where each class is basically a single function: produces high coupling and lots of message passing
where to assign responsibility to avoid direct coupling between 2+ things?
how to decouple to support low coupling and reuse potential?
assign responsibility to an intermediary, creating indirection between components
e.g. Adapter to protect inner design against external variation
“Most problems in computer science can be solved by another layer of indirection”
reduced coupling
high performance may need to reduce amount of indirection
“Most problems in performance can be solved by removing another layer of indirection”

Problem: How to design objects/systems so that variation in these elements doesn’t impact other elements?

identify points of predicted variation/instability
assign responsibilities to create a stable interface (in the broad sense of an access view) around them
variation point: variation in existing system/requirements
evolution point: speculative variations that may arise in the future
equivalent to Open-Closed principle : objects should be open for extension, and closed to modification that affects clients
equivalent to Information Hiding
new implementations don’t affect clients
low coupling
low cost of change
cost of future-proofing can outweigh benefits
reworking a brittle design as needed may be easier
novice developers produce brittle designs
intermediate developers produce overly fancy/flexible, generalised designs that never get used
expert developers choose with insight, balancing the cost of changing a simple/brittle design against its likelihood
software (methods, classes, …) referring to a type T (interface, abstract superclass) should work properly with any substituted implementation or subclass of T

Avoid creating designs that traverse long object structure paths and/or send messages to distant, indirect (stranger) objects. doing so makes designs fragile with respect to changes in object structures.

Within a method, messages should only be passed to:

this object ( self )
parameter of the method
attribute of this , (or element of collection that is an attribute of this )
object created in the method

Intent: : avoid coupling between client and knowledge of indirect objects, and connections between objects.

Guideline: The farther along a path one traverses, the more fragile it will be. Instead add a public operation to direct objects that hides how the information is obtained.

Edit this page .

GRASP - General Responsibility Assignment Software Principles

GRASP is an acronym for General Responsibility Assignment Software Principles. In this article, we want to point out these principles and how they work.

About GRASP #

This collection of object-oriented design rules goes back to Craig Larman and his book Applying UML and Patterns from 2004. Larman didn't invent any of these principles and ideas. He simply collected them.

GRASP is a pretty fancy name, but it somehow feels more like he wanted GRASP as the acronym and linked random words to reach it. Even though it is about to become an oldie, most rules collected under the GRASP banner are still helpful, and they should be essential to every developer's toolkit.

The General Responsibility Assignment Software Principles list nine principles:

Indirection
Information Expert
Low Coupling
High Cohesion
Polymorphism
Protected Variations
Pure Fabrication.

Though they are tailored to object-oriented design, some also apply for general software development as well.

I write about some things that are not from Larman's book but my own opinion and personal note. If you don't want the unaltered version, I suggest you read the original book: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

Controller #

The controller pattern is a common tool in object-oriented software design. Though most people might only associate the controller with the ancient architecture of the MVC (Model-View-Controller - Which is far too often used for cases it absolutely doesn't fit, but that's a story for a different day), the controller is a construct of itself.

As the name implies, the controller's work is to 'control' any events that are not directly related to the user interface. But controlling does not mean implementing. The controller consists of barely any logic. It is merely a mediator between the presentation layer and the (core) logic.

For example, if we imagine a simple web-shop application with the use case of "User X bought item A"; The controller's job would be to receive the signal of the pressed button from the UI and then run the necessary functions in the correct order. In the example at hand that could be to certify the payment and then initialize the shipment of the item.

Applying the principle of a controller can hugely improve your software's lifetime as it naturally creates a resilient layer regarding the interchangeability of code. If your UI or logic (unlikely, but possible), you can adjust your mappings instead of having to rewrite large chunks of code.

Also, it becomes incredibly easier to add other layers, such as an app at the overlaying presentation layer that uses a different UI but wants the same responses.

You can also think of a controller as a driver. It knows both parts it connects with one another but it acts merely as a broker. It consists of just a few and essential parts of code.

The creator is another pattern, but to me, it's more like an abstract idea than a real pattern. I must admit I rarely use this pattern intentionally.

A creator is a class that is responsible for creating instances of objects. Larman defines the following cases as B is the creator of A :

B aggregates A objects
B contains A objects
B records instances of A objects
B closely uses A Objects
B has the initializing data that will be passed to A when it is created

So an example for a creator could be a library that contains books. In that case, the library would be the creator of books, even though this sounds syntactically weird as natural language.

Indirection #

Indirection isn't a pattern but an idea. It is also of no use of its own, only in combination with other ideas such as low coupling. The goal behind indirection is to avoid direct coupling.

To pick up an earlier example the controller for example is a kind of indirection between the UI and the logic. Instead of coupling the UI directly to the logic, the controller decouples this layer and thereby comes with all the advantages of indirection.

Information Expert #

Another principle that falls into that area is the information expert. Sometimes it is just called the expert or the expert principle. The problem that should be solved with the information expert is the delegation of responsibilities. The information expert is a class that contains all the information necessary to decide where responsibilities should be delegated to.

You identify the information expert by analyzing which information is required to fulfill a certain job and determining where the most of this information is stored.

Low Coupling #

Low or loose coupling is the idea of creating very few links between modules. In GRASP it is an inter-module concept. Meaning it describes the flow between different modules, not the flow inside the modules.

Together with cohesion, it is the main reason upon which you make global design decisions such as "Where do we pack this module or function to?".

Low coupling is another concept that supports interchangeability. By making very few dependencies, very few code must be changed in case of a change.

High Cohesion #

in GRASP high (functional) cohesion is an intra-module concept. Meaning it describes the flow inside a certain module not the flow between modules.

The main reason behind high cohesion is the idea of reducing complexity. Instead of building large classes that have many functions that have few in common and are hard to maintain, the goal should be to create classes that fit exactly their defined purpose.

It's kind of hard to understand these abstract ideas but I also wasn't able to come up with a simple example, which is why I will write an extra article on the topic of low cohesion combined with high cohesion that is more detailed.

Polymorphism #

Polymorphism: πολυ ( polús )= many/multi, μορφή ( morphé ) = shape/form, ισμός ( ismós ) = imitation of.

Meaning, Polymorphism could be frankly translated as "something that imitates many forms". And that might be a concise but useless explanation to someone who has never heard of polymorphism.

Anyone who ever took a programming class is most likely familiar with polymorphism. But, it can be a tricky question to define it sensefully.

The idea again is to reduce complexity by imagining that objects follow simple and similar rules. Consider the following example: You have three objects A, B and C. B has the same methods and attributes but has an additional method X. C has the same methods and attributes as B, but an additional method Y.

The non-developer approach to this problem would be: "Great, as you said, we have 3 objects, so we have A, B, and C. Problem solved. You little stinky moron.". Yes, non-developers are insanely evil creatures.

But as a programmer, you instinctively know that we need the concept of inheritance here. A is an object, B is an object that inherits from A, and C is an object that inherits from B. Caution: Inheritance is not polymorphism - inheritance is an application that is allowed due to polymorphism.

To wrap it up: polymorphism is the concept of disassembling objects and ideas into their most atomic elements and abstracting their commonalities to build objects that can act like they were others. Not only to reduce complexity but also to avoid repetitions.

Protected Variations #

The protected variations pattern is a pattern used to create a stable environment around an unstable problem. You wrap the functionality of a certain element (class, interfaces, whatever) with an interface to then create multiple implementations by using the concept of polymorphism. Thereby you are able to catch specific instabilities with specific handlers.

An example of the protected variations pattern is working with sensory data, such as a DHT22, a common temperature and humidity sensor often used for Raspberry Pi or Arduino). The sensor is doing its job pretty well, but sometimes it will say the temperature just rose by 200 celsius or won't return any data at all. These are cases you should catch using the protected variations pattern to avoid false behavior of your program.

Pure Fabrication #

To reach low coupling and high cohesion, it is sometimes necessary to have pure fabrication code and classes. What is meant by that is that this is code that does not solve a certain real-world problem besides ensuring low coupling and high cohesion. This is often achieved by using factor classes.

Some last words #

Often when I look into programming principles, I feel mildly overwhelmed and discouraged. That's in part because some of these concepts are very hard to grasp if you never heard of them or got no practical use case in mind. But with a growing set of programming principles and best practices, you will see that all these principles refer to the same key statements and follow the same rules.

Unfortunately, in my opinion, there's also no substitution for learning it the hard way. Memorizing merely the key statements will eventually lead to greater school and university scores, but it will still be useless incoherent information without any practical use. Thereby, my advice is to learn as much as possible about code and its principles but also get as much hands-on experience as possible to abstract the key statements by yourself.

If you liked this post or are of any different opinion regarding any of the written, please let us know via mail or comment. Happy coding!

List of languages
1.1 Information expert
1.2 Creator
1.3 Controller
1.4 Indirection
1.5 Low coupling
1.6 High cohesion
1.7 Polymorphism
1.8 Protected variations
1.9 Pure fabrication
3 References

GRASP (object-oriented design)

General Responsibility Assignment Software Patterns (or Principles ), abbreviated GRASP , is a set of "nine fundamental principles in object design and responsibility assignment" [1] : 6 first published by Craig Larman in his 1997 [ citation needed ] book Applying UML and Patterns .

The different patterns and principles used in GRASP are controller, creator, indirection, information expert, low coupling, high cohesion, polymorphism, protected variations, and pure fabrication. [2] All these patterns solve some software problem common to many software development projects. These techniques have not been invented to create new ways of working, but to better document and standardize old, tried-and-tested programming principles in object-oriented design.

Larman states that "the critical design tool for software development is a mind well educated in design principles. It is not UML or any other technology." [3] : 272 Thus, the GRASP principles are really a mental toolset, a learning aid to help in the design of object-oriented software.

In object-oriented design, a pattern is a named description of a problem and solution that can be applied in new contexts; ideally, a pattern advises us on how to apply its solution in varying circumstances and considers the forces and trade-offs. Many patterns, given a specific category of problem, guide the assignment of responsibilities to objects.

Information expert

Problem: What is a basic principle by which to assign responsibilities to objects? Solution: Assign responsibility to the class that has the information needed to fulfill it.

Information expert (also expert or the expert principle ) is a principle used to determine where to delegate responsibilities such as methods, computed fields, and so on.

Using the principle of information expert, a general approach to assigning responsibilities is to look at a given responsibility, determine the information needed to fulfill it, and then determine where that information is stored.

This will lead to placing the responsibility on the class with the most information required to fulfill it. [3] : 17:11

Related Pattern or Principle : Low Coupling, High Cohesion

The creation of objects is one of the most common activities in an object-oriented system. Which class is responsible for creating objects is a fundamental property of the relationship between objects of particular classes.

Problem: Who creates object A ? Solution: In general, Assign class B the responsibility to create object A if one, or preferably more, of the following apply:

Instances of B contain or compositely aggregate instances of A
Instances of B record instances of A
Instances of B closely use instances of A
Instances of B have the initializing information for instances of A and pass it on creation. [3] : 16:16.7

Related Pattern or Principle : Low Coupling, Factory pattern

The controller pattern assigns the responsibility of dealing with system events to a non- UI class that represents the overall system or a use case scenario. A controller object is a non-user interface object responsible for receiving or handling a system event.

Problem: Who should be responsible for handling an input system event? Solution: A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case. For instance, for the use cases Create User and Delete User , one can have a single class called UserController , instead of two separate use case controllers.

The controller is defined as the first object beyond the UI layer that receives and coordinates ("controls") a system operation. The controller should delegate the work that needs to be done to other objects; it coordinates or controls the activity. It should not do much work itself. The GRASP Controller can be thought of as being a part of the application/service layer [4] (assuming that the application has made an explicit distinction between the application/service layer and the domain layer) in an object-oriented system with common layers in an information system logical architecture.

Related Pattern or Principle : Command , Facade , Layers, Pure Fabrication

Indirection

The indirection pattern supports low coupling and reuses potential between two elements by assigning the responsibility of mediation between them to an intermediate object. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the model-view control pattern. This ensures that coupling between them remains low.

Problem: Where to assign responsibility, to avoid direct coupling between two (or more) things? How to de-couple objects so that low coupling is supported and reuse potential remains higher?

Solution: Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled. The intermediary creates an indirection between the other components.

Low coupling

Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements. Low coupling is an evaluative pattern that dictates how to assign responsibilities for the following benefits:

lower dependency between the classes,
change in one class having a lower impact on other classes,
higher reuse potential.

High cohesion

High cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of low coupling. High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system. Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities. Elements with low cohesion often suffer from being hard to comprehend, reuse, maintain and change. [3] : 314–315 </ref>

Polymorphism

According to the polymorphism principle, responsibility for defining the variation of behaviors based on type is assigned to the type for which this variation happens. This is achieved using polymorphic operations. The user of the type should use polymorphic operations instead of explicit branching based on type.

Problem: How to handle alternatives based on type? How to create pluggable software components? Solution: When related alternatives or behaviors vary by type (class), assign responsibility for the behavior—using polymorphic operations—to the types for which the behavior varies. (Polymorphism has several related meanings. In this context, it means "giving the same name to services in different objects".)

Protected variations

The protected variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

Problem: How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesirable impact on other elements? Solution: Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them.

Pure fabrication

A pure fabrication is a class that does not represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion, and the reuse potential thereof derived (when a solution presented by the information expert pattern does not). This kind of class is called a "service" in domain-driven design .

Related Patterns and Principles • Low Coupling. • High Cohesion.

Anemic domain model
Design pattern (computer science)
Design Patterns (book)
SOLID (object-oriented design)
^ Muhammad Umair (2018-02-26). "SOLID, GRASP, and Other Basic Principles of Object-Oriented Design" . DZone .
^ a b c d Craig Larman (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). Pearson. ISBN 978-0131489066 .
^ "Application Layer like business facade?" . Yahoo! Groups (domaindrivendesign) . Retrieved 2010-07-15 .

By: Wikipedia.org Edited: 2021-06-18 19:29:54 Source: Wikipedia.org

Principles Wiki

Recent Changes
Media Manager

Further reading, general responsibility assignment software patterns (grasp).

Craig Larman describes how to assign responsibilities to classes using the following principles and patterns:

High Cohesion
Indirection
Information Expert
Low Coupling
Polymorphism
Protected Variations
Pure Fabrication

He calls GRASP “patterns of general principles in assigning responsibilities” 1) . Some of these are really patterns but others are principles.

Craig Larman: Applying UML and Patterns

GRASP (object-oriented design)

Discuss this wiki article and the collection on the corresponding talk page .

Chapter: Object Oriented Analysis and Design

Grasp - general responsibility assignment software patterns (or principles).

 General Responsibility Assignment Software Patterns (or Principles), abbreviated

GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.

 The different patterns and principles used in GRASP are: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations. All these patterns answer some software problem, and in almost every case these problems are common to almost every software development project. These techniques have not been invented to create new ways of working but to better document and standardize old, tried-and-tested programming principles in object oriented design.

 It has been said that "the critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology". Thus, GRASP is really a mental toolset, a learning aid to help in the design of object oriented software.

 Creation of objects is one of the most common activities in an object-oriented system. Which class is responsible for creating objects is a fundamental property of the relationship between objects of particular classes.

 In general, a class B should be responsible for creating instances of class A if one, or preferably more, of the following apply:

1. Instances of B contains or compositely aggregates instances of A

2. Instances of B record instances of A

3. Instances of B closely use instances of A

4. Instances of B have the initializing information for instances of A and pass it on creation.

3. Information Expert

 Information Expert is a principle used to determine where to delegate responsibilities. These responsibilities include methods, computed fields and so on.

 Using the principle of Information Expert a general approach to assigning responsibilities is to look at a given responsibility, determine the information needed to fulfill it, and then determine where that information is stored. Information Expert will lead to placing the responsibility on the class with the most information required to fulfill it.

4. Low Coupling

 Low Coupling is an evaluative pattern, which dictates how to assign responsibilities to support:

1. low dependency between classes;

2. low impact in a class of changes in other classes;

3. high reuse potential

5. Controller

 The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers).

 It is defined as the first object beyond the UI layer that receives and coordinates ("controls") a system operation. The controller should delegate to other objects the work that needs to be done; it coordinates or controls the activity. It should not do much work itself. The GRASP Controller can be thought of as being a part of the Application/Service layer (assuming that the application has made an explicit distinction between the App/Service layer and the Domain layer) in an object-oriented system with common layers.

6. High Cohesion

 High Cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of Low Coupling.

 High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system. Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities.

 Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain and adverse to change.

Polymorphism

According to Polymorphism, responsibility of defining the variation of behaviors based on type is assigned to the types for which this variation happens. This is achieved using polymorphic operations.

Pure Fabrication

 A pure fabrication is a class that does not represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion, and the reuse potential thereof derived (when a solution presented by the Information Expert pattern does not). This kind of class is called "Service" in Domain-driven design.

Indirection

 The Indirection pattern supports low coupling (and reuse potential) between two elements by assigning the responsibility of mediation between them to an intermediate object. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern.

Protected Variations

 The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

7. Visibility

Creational Design Patterns

 In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design.

 Creational design patterns solve this problem by somehow controlling this object creation. In object-oriented design, there is a notation of visibility for attributes and operations. UML identifies four types of visibility: public, protected, private, and package.

 The UML specification does not require attributes and operations visibility to be displayed on the class diagram, but it does require that it be defined for each attribute or operation.

 To display visibility on the class diagram, you place the visibility mark in front of the attribute's or operation's name. Though UML specifies four visibility types, an actual programming language may add additional visibilities, or it may not support the UML-defined visibilityies

Mark Visibility

+ Public

# Protected

- Private

~ Package

A BankAccount class that shows the visibility of its attributes and operations

 Visibility - the ability of one object to “see” or have a reference to another object.

Visibility is required for one object to message another.

8. Applying GOF Design Patterns:

 Design patterns represent common software problems and the solutions to those problems in a formal manner. They were inspired by a book written by architect Christopher Alexander. Patterns were introduced in the software world by another book: "Design Patterns: Elements of Reusable Object-Oriented Software", by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. These people were nicknamed the "Gang of Four" for some mysterious reason. The Gang of Four describes 23 design patterns.

 With patterns you don't have to reinvent the wheel and get proven solutions for frequently encountered problems. Many books and articles have been written on this subject. This means that design patterns are becoming common knowledge, which leads to better communication. To summarize design patterns save time, energy while making your life easier.

8.1. Singleton

 The singleton pattern deals with situations where only one instance of a class must be created. Take the case of a system administrator or superuser. This person has the right to do everything in a computer system. In addition we will also have classes representing normal users. Therefore we must ensure that these classes have no access to the super

user constructor. The solution to this problem in C++ and Java is to declare the superuser constructor private.

 The super user class itself has a private static attribute sysadmin, which is initialised using the class constructor. Now we get an instance of the super user class with a public static method that returns sysadmin. Here is the class diagram:

8.2. Factory Method

 The Factory Method pattern deals with situations where at runtime one of several similar classes must be created. Visualise this as a factory that produces objects. In a toy factory for instance we have the abstract concept of toy.

 Every time we get a request for a new toy a decision must be made - what kind of a toy to manufacture. Similarly to the Singleton pattern the Factory Method pattern utilises a public static accessor method. In our example the abstract Toyfactory class will have a getInstance() method, which is inherited by its non abstract subclasses.

8.3. Adapter

 Sometimes it will have two classes that can in principle work well together, but they can't interface with each other for some reason. This kind of problem occurs when travelling abroad and you carry an electric shaver with you.

 Although it will work perfectly when you are at home. There can be problems in a foreign country, because of a different standard voltage. The solution is to use an adapter. Let's turn our attention back to the software domain. Here we will have an interface which defines new methods for example getElectricity2.

 An adapter class will wrap around the Shaver class. The adapter class will implement the interface with the new method.

 The Proxy pattern deals with situations where you have a complex object or it takes a long time to create the object. The solution to this problem is to replace the complex object with a simple 'stub' object that has the same interface.

 The stub acts as a body double. This is the strategy used by the Java Remote Method Invocation API. The reason to use the proxy pattern in this case is that the object is on a remote server causing network overhead. Other reasons to use the proxy can be restricted access (Java applets for example) or time consuming calculations.

8.5. Decorator

 The Decorator is usually a subclass, that is a body double for its superclass or another class with identical interface. The goal of the Decorator pattern is to add or improve the capabilities of the super class.

8.6. Composite

 The composite is often encountered in GUI packages like for instance the Java Abstract Windwing Toolkit (AWT) or Microsoft Foundation (MFC) classes. All objects in this pattern have a common abstract superclass that descibes basic object conduct. The base class in the MFC hierarchy is CObject. It provides functions for debugging and serialization. All the MFC classes even the most basic ones inherit these facilities.

8.7. Observer and MVC

 An application with Model - View - Controller setup usually uses the Observer Pattern. In a Java webserver environment the model will be represented by Java classes encompassing the business logic, the view is represented by Java Server Pages which display HTML in the client's browser and we will have a Servlets as Controllers.

 The observer pattern strategy is to have view components take subscriptions for their model. This ensures that they will get notified if the model changes.

8.8. Template

 In the good old days before OOP writing functions was the recommended thing to do. A sort algorithm would be implement by half dozen of functions, one sort function for integers, one sort function for floating points, one sort function for doubles etc.

 These functions are so similar that nobody in their right mind will type them letter by letter. Instead a programmer will write a template and copy the template several times. After that it's just a matter of writing down datatypes as appropriate. Thanks to OOP and the Template Design Pattern less code is required for this task.

 Define an abstract Template class let's call it SortTemplate and it will have methods sort, compare and process (performs one cycle of the algorithm). Then we define classes for each datatype. These classes are subclasses of SortTemplate and implement the compare and process methods.

8.9. Strategy

 The Strategy Design Pattern makes it possible chooses an implementation of an algorithm at run time. The implementation classes implement the same interface. In the case of the Java AWT Layout classes, the common interface is Layout Manager.

10. Summary

 Design patterns are a hot research item. New patterns are emerging every day. In the future design patterns will be integrated in development tools. The main advantages of design patterns:

1. Provide proven solutions

2. Simplify complex problems

3. Improve communication

Classification and list

 Design patterns were originally grouped into the categories: creational patterns, structural patterns, and behavioral patterns, and described using the concepts of delegation, aggregation, and consultation.

 For further background on object-oriented design, see coupling and cohesion, inheritance, interface, and polymorphism. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.

 In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation.

 The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation

GRASP – Software Design Patterns

GRASP – General Responsibility Assignment Software Patterns .

When writing software is simply not the process of just writing code, regardless of how much fun that may be. But rather how it is written in the context of the software. That means that during the development process, there will a point where starting designing the software. This is where using design patterns comes place. Note, these are not the same as the development processes, like iterative, scrum, and agile, which deals with how to structure the development process.

Furthermore, these design patterns are not rules , but techniques for improving code and structure. Additionally, using any design pattern will change the software restriction, limitations, and capabilities. However, what is most important is that you know what implication a design pattern will create and not how many you know, since they are just tools to improve the software.

The singleton is one the simplest to implement. Since it only requires a couple of lines of code and allows for quick early development. It is a quick way to add an object as a global object and manage its creation cycle. However, despite its easy implementation. It should not be overused, absent-mindlessly. Furthermore, misuse can cause program architecture to become weak and non-flexible. So use it with care on stuff that you know will only need a single instance and will not break other components’ life cycles.

If misused it can easily become an anti-pattern, which can be through both increased coupling and reduced cohesion by making everything more entangled. That can increase the amount of development required for simple features exponentially.

Low Coupling

Low Coupling and the following pattern High-Cohesion are very much associated with one other, which you will soon see. Nevertheless, one of the most useful design patterns in software development.

The Low Coupling design pattern attempts to minimize the number of associations between each model/class. This pattern is about simplifying the program since there is no need to make software unnecessarily complex.

Furthermore, it differed from many other patterns that usually have some code associated with them. It is more a principle/strategy for how to structure your program from architecture software design.

High Cohesion

The High Cohesion pattern, similar to low coupling is about getting the design within a goal. But let us take a look at what this pattern is all about. This pattern is all about reducing the delegation of problems to the least number of classes for instance.

For the given problem of having multiple entity classes in your program the need to communicate with the database. Each class could have its own implementation for how to communicate with the database. But this would yield a low cohesion since everyone knows how to communicate with the database in their own way. However, instead, you give a better cohesion of the software.

Another example is looking at the real world. Would it be good if we all had to know how to be doctors, programmers, lawyers, artists and etc. No, it would make it hard to delegate what one should. Rather, if I can focus on being a programmer, then my doctor can focus on how to be an Instead of everyone being doc

We create a dedicated class that will handle all the communication to the database in between. So that each of the classes will only communicate with this new class instead of never knowing of to communicate with the database.

Polymorphism

The polymorphism design pattern is related to the object-orientated programming feature inherited or interfaces. It allows other parts of the software architecture to refer to an object, for instance, IO abstract. However, there can exist multiple IO implementations, one for File, Serial, and Network. Where the construction of the inherited class handles all the specifics related to that implementation. Thus removing the coupling of the rest of the software if the IO is Serial, Network, File and etc.

Encapsulation

The Encapsulation pattern is simple but very useful for various reasons that we will see. The essence of the encapsulation pattern is that object/struct data fields shall not be accessed directly. Instead, rather, they are accessed via some method/function. Of course, this will add an additional cycle overhead to fetch the data.

However, by encapsulation, the method itself is self-containing. meaning that it can be improved later without having any effect on the compilation.

In regard to performance overhead, if a function were to be invoked frequently it can be resolved in some programming languages as inline. However, in order to allow for future update of the software, the inline function should be a pure functional functional. That is to say it take all the data it need as arguments.

How to Apply Design Pattern

Great, we look at some design patterns, but let us talk about the actual challenge, and how to apply these patterns to our software.

Of course, the amount of design is proportional to the complexity of the software. Though, it does not mean you should just make it complex for the sake of the privilege of having made a complex system. The simplest design option is the best design choice. Additionally, through understanding each of the design patterns and their consequences on the software architecture, choose the most fitting one. A software design most likely does not require to use of all possible design patterns.

A Guide to Start Creating a Game Engine

Scorching Pain - Created with Blender 3D

Snake – AI Path Finder Problem

Automate Multi Platform Build Targets with Unity 3D

Free/Open software developer, Linux user, Graphic C/C++ software developer, network & hardware enthusiast.

Categories Computer Science Programming

Tags C/C++ GRASP Guide Software Design

404 Not found

COMMENTS

GRASP (object-oriented design)
General Responsibility Assignment Software Patterns (or Principles), abbreviated GRASP, is a set of "nine fundamental principles in object design and responsibility assignment": 6 first published by Craig Larman in his 1997 [citation needed] book Applying UML and Patterns.. The different patterns and principles used in GRASP are controller, creator, indirection, information expert, low ...
GRASP Design Principles in OOAD
In Object-Oriented Analysis and Design (OOAD), General Responsibility Assignment Software Patterns (GRASP) play a crucial role in designing effective and maintainable software systems.GRASP offers a set of guidelines to aid developers in assigning responsibilities to classes and objects in a way that promotes low coupling, high cohesion, and overall robustness.
GRASP (General Responsibility Assignment Software Patterns)
GRASP (General Responsibility Assignment Software Patterns) is a design pattern in object-oriented software development used to assign responsibilities for different modules of code.. As a tool for software developers, GRASP provides a means to solve organizational problems and offers a common way to speak about abstract concepts.
GRASP
In this post I described one of the most fundamental Object-Oriented Design set of patterns and principles - GRASP. Skilful management of responsibilities in software is the key to create good quality architecture and code. In combination with others patterns and practices is it possible to develop well-crafted systems which supports change and ...
Understanding the GRASP Design Patterns
The GRASP design patterns are a set of design patterns that came after the original Gang of Four book that many of you might be familiar with. GRASP stands for General Responsibility Assignment ...
PDF GRASP Design Principles
GRASP stands for General Responsibility Assignment Software Patterns guides in assigning responsibilities to collaborating objects. 9 GRASP patterns Creator Information Expert Low Coupling Controller High Cohesion Indirection Polymorphism Protected Variations Pure Fabrication
PDF Presentation Duncan C
GRASP (General Responsibility Assignment Software Patterns) is an acronym created by Craig Larman to encompass nine object‐oriented design principles related to creating responsibilities for classes. These principles can also be viewed as design patterns and offer benefits similar to the classic "Gang of Four" patterns.
GRASP: 9 Must-Know Design Principles for Code
GRASP stands for General Responsibility Assignment Software Principles. I think the words that carry the most meaning in this acronym are RA: Responsibility Assignment. This is exactly what we're talking about. I learnt those principle in Craig Larman's book Applying UML and Patterns: Even though the book title mentions UML, the book is ...
Mastering GRASP Design Principles for Better Software Design
GRASP, which stands for General Responsibility Assignment Software Patterns (or Principles), is a collection of nine best practices that assist in assigning responsibilities to classes and objects.
GRASP (General Responsibility Assignment Software Patterns)
GRASP (General Responsibility Assignment Software Patterns) GRASP is a set of guidelines and patterns that help developers make informed decisions about assigning responsibilities to objects and ...
Introduction to GRASP Design Patterns in Object-Oriented Design
GRASP stands for General Responsibility Assignment Software Patterns (or Principles). GRASP consist of guidelines for assigning responsibility to classes and objects in object-oriented design. The different patterns and principles used in GRASP are: controller, creator, indirection, information expert, high cohesion, low coupling, polymorphism ...
GRASP · Notes
General Responsibility Assignment Software Patterns; pattern: named and well-known problem and solution that can be applied to new contexts, providing guidance for assessing trade-offs; Benefits of patterns. capture expertise in an accessible, standardised manner; facilitate reuse of applying expertise
GRASP
The General Responsibility Assignment Software Principles list nine principles: Pure Fabrication. Though they are tailored to object-oriented design, some also apply for general software development as well. I write about some things that are not from Larman's book but my own opinion and personal note.
GRASP (object-oriented design)
General Responsibility Assignment Software Patterns (or Principles), abbreviated GRASP, is a set of "nine fundamental principles in object design and responsibility assignment": 6 first published by Craig Larman in his 1997 [citation needed] book Applying UML and Patterns.. The different patterns and principles used in GRASP are controller, creator, indirection, information expert, low ...
GRASP Principles in Object-Oriented Design: A Practical Guide with
One set of principles that guides object-oriented design is GRASP (General Responsibility Assignment Software Patterns). GRASP provides guidelines for assigning responsibilities to classes and objects, which helps developers create well-structured and loosely coupled systems.
Chapter No- 6 : GRASP General Responsibility Assignment Software
This video contains the introduction about GRASP(General Responsibility Assignment Software Patterns).It include patterns like Expert, Creator, and Low Coupl...
General Responsibility Assignment Software Patterns (GRASP)
High Cohesion. Indirection. Information Expert. Low Coupling. Polymorphism. Protected Variations. Pure Fabrication. He calls GRASP "patterns of general principles in assigning responsibilities" 1). Some of these are really patterns but others are principles.
GRASP
1. GRASP. General Responsibility Assignment Software Patterns (or Principles), abbreviated. GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design. The different patterns and principles used in GRASP are: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure ...
GRASP Principles That Every Developer should know
GRASP Stands for "General Responsibility Assignment Software Principles" Grasp principles can help you understand the fundamentals behind the GOF design patterns or in fact any other object ...
GRASP
GRASP - General Responsibility Assignment Software Patterns. When writing software is simply not the process of just writing code, regardless of how much fun that may be. But rather how it is written in the context of the software. That means that during the development process, there will a point where starting designing the software.
SWEN-261 Object-Oriented Design
We will discuss object-oriented design in more detail in two lessons. Each lesson will focus on design principles from the two sets of principles known as SOLID and GRASP (General responsibility assignment software patterns/principles). This first lesson will also cover the Law of Demeter. This lesson will look at these principles:
The 9 Principles of GRASP
GRASP stands for General Responsibility Assignment Software Patterns. It is a set of principles applied to Object Oriented Programming. There are nine principles or "patterns" which help ...
GRASP
General Charge Assignment Software Patterns (or Principles), abbreviated GRASP, is one set of "nine basic principles at set design and ... 7. Polymorphism. ... Skilful general of responsibilities int software is the keyboard to create good quality architecture and code. In combination with others patterns and practices is it possible to develop ...

GRASP Design Principles in OOAD

What are GRASP Principles?

2. Information Expert

3. Low Coupling

4. High Cohesion

5. Controller

6. Pure Fabrication

7. Indirection

8. Polymorphism

Please Login to comment...

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

GRASP - General Responsibility Assignment Software Patterns Explained

Introduction

The Responsibility in Software

Doing and Knowing

1. Information Expert

3. Controller

4. Low Coupling

5. High Cohesion

6. Indirection

7. Polymorphism

8. Pure Fabrication

9. Protected Variations

Related posts See all blog posts

About Jonathan Boccara

GRASP: 9 Must-Know Design Principles for Code

The need for Patterns

The book where I learnt the design principles

The GRASP patterns

Some principles are more fundamental than others

You will also like

Search form

Partners and Platforms

Follow us on:

About Cloudericks

Partner Sites

Recent comments

Photo Stream

You are here

Software Modelling and Design

Benefits of patterns

GRASP - General Responsibility Assignment Software Principles

About GRASP #

Controller #

Indirection #

Information Expert #

Low Coupling #

High Cohesion #

Polymorphism #

Protected Variations #

Pure Fabrication #

Some last words #

GRASP (object-oriented design)

Information expert

Indirection

Low coupling

High cohesion

Polymorphism

Protected variations

Pure fabrication

Principles Wiki

Table of Contents

Chapter: Object Oriented Analysis and Design

GRASP – Software Design Patterns

Low Coupling

High Cohesion

Polymorphism

Encapsulation

How to Apply Design Pattern

A Guide to Start Creating a Game Engine

Snake – AI Path Finder Problem

Automate Multi Platform Build Targets with Unity 3D

404 Not found

COMMENTS