0

Background

I've been thinking about documenting design patterns in our code by setting up interfaces for the common design patterns so that when people read my code it would be clear that I am using a design pattern.

I would do this by create a project, in our solution, called Design Patterns, so it was clear it was meant to be a common terminology, as opposed to business/organization specific. Possibly even making it into a open source package to further distinguish it from the business logic in our project.

The project would consist of solely interfaces for all the classes that are used for different design patterns, that would be extended/implemented when you are implementing a pattern.

Questions

Are there any functional issues in bending interfaces into a tool to document something that is inherently not functional?

In Other words, What are the consequences of using an interface as a documentation tool, where the interface is strictly superficial?

Baring the first two questions introduce no issues, would you use this "tool" with common design patterns?

Can you think of any reasons why you would not do this?

Improve this question
7
  • 1
    What exactly are you trying to achieve? It seems you're looking at the problem from the wrong way. You shouldn't use design patterns as building blocks, you should write your application, then figure out which patterns you used when you need to communicate to others about your architecture.
    – Vincent Savard
    CommentedJan 22, 2018 at 18:58
  • I use design patterns upfront, as part of my initial solution design. It is not a retroactive process. However, documentation is typically retroactive, I want my code to be self documenting, as in there would be no need to document the fact that I used an Abstract Factory Pattern, or a command pattern, etc, because it would be explicit in the use of the interfaces.
    – Devin Gleason Lambert
    CommentedJan 22, 2018 at 19:17
  • So what's your actual question?
    – Telastyn
    CommentedJan 22, 2018 at 19:33
  • 7
    You have a common disorder that I call Pattern Happiness Disease; it is closely related to Object Happiness Disease and Thread Happiness Disease. In all three, the sufferer comes to believe that their employer is paying them to implement design patterns, implement type hierarchies, or make as many threads as possible. Doing these things makes the afflicted very happy, and their employers very unhappy, since they spend their time fiddling around with pointless counterproductive code polishing and religious discussions rather than writing code that solves business problems.
    – Eric Lippert
    CommentedJan 22, 2018 at 23:06
  • 7
    In short: do none of this pointless busywork. Spend your valuable time writing tests, doing customer research, building a performance testing framework, designing the next version, fixing bugs, responding to customer requests or literally anything else than making a bunch of interfaces that no one uses as markers for patterns.
    – Eric Lippert
    CommentedJan 22, 2018 at 23:08

3 Answers 3

Reset to default
8

Can you think of any reasons why you would not do this?

This is a terrible idea because it's backwards in all manner of ways. Your problem dictates your solution, not patterns pulled from a book. Your classes describe what they do, not what box they represent in a diagram. Your implementation may follow a pattern, but they'll invariably be tailored for the problem at hand. And since the various implementations will vary, trying to force them into a standardized interface is foolhardy.

Improve this answer
8
  • So your feedback, to clarify is more around, the strict use of design patterns ? Rather than the documentation using interfaces side of my question.
    – Devin Gleason Lambert
    CommentedJan 22, 2018 at 20:17
  • Also, I get your argument, but I would say that most design patterns are flexible enough to generic problems, that 80% of the time you should be able to follow one of them. The other 20% of the time you can't, sure you can't do what I am asking, but that is more "the exception, rather than the rule" thinking.
    – Devin Gleason Lambert
    CommentedJan 22, 2018 at 20:18
  • @DevinGleasonLambert - I don't see them as being terribly separable. If you aren't using common patterns, there's unlikely to be broad generic interfaces to document from.
    – Telastyn
    CommentedJan 22, 2018 at 20:20
  • I would limit this to patterns that are covered in the GOF book, seeing as that is the defacto standard
    – Devin Gleason Lambert
    CommentedJan 22, 2018 at 20:23
  • 4
    @DevinGleasonLambert - it is entirely a negative message. Frankly, this trend to treat design patterns like lego blocks or two-by-fours is horrific. It's the paint-by-numbers form of program design: good enough that people know what you were going for, but lacking the skill to make anything great.
    – Telastyn
    CommentedJan 22, 2018 at 21:11
3

This is not possible. A design pattern cannot be captured in an interface or in a library. To quote wikipedia:

It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.

A typical example of a design pattern is the Adapter Pattern. The intent of the adapter pattern is to convert one interface into another interface. How could that pattern be represented as an interface itself? It is not possible.

If a pattern could be captured in a library, it would not be a pattern. It would just be reusable component like any other.

If you want to document that a class is an adapter, you either explicitly call it FooAdapter, or you write in source comments that it is an adapter.

Improve this answer
4
  • But doesn't the Adapter pattern explicitly use an interface, or is based on a class, that could then implement the "Adapter Interface". However, this does bring up two potential issues. Patterns that are not class based, or classes that have some other interface already, and cannot support a second interface.
    – Devin Gleason Lambert
    CommentedJan 22, 2018 at 22:08
  • Also, I appreciated your use of 'patterns cannot be libraries' reference. However true, what I am describing is not a holistic solution to implementing a pattern as a library, only 'applying nametags' to common pattern constructs.
    – Devin Gleason Lambert
    CommentedJan 22, 2018 at 22:10
  • 1
    @DevinGleasonLambert each Adapter uses a different interface, not the same interface as any other Adapter, specifically the interface it adapts
    – Caleth
    CommentedJan 23, 2018 at 9:50
  • 2
    @DevinGleasonLambert Or to put it another way: What would the members of IAdapter be?
    – Caleth
    CommentedJan 23, 2018 at 9:57
-2

One issue I have with an alternative solution, including the design pattern in the name. EG WidgetFactory, CutCommand, PasteCommand.

Is that FactoryPattern, is the name of the overarching design pattern, what about all the members at play?

For example:

The Abstract Factory Pattern has the following members, AbstractFactory, ConcreteFactory, AbstractProduct, ConcreteProduct.

The Command Pattern has the following members, Command, ConcreteCommand, Invoker, Receiver.

Issue here, is that if you are fortunate enough to know design patterns, it is less likely that you would recognize the names of the components that make up that design pattern. Further where one of the benefits of using design patterns is increased recognizability, I feel using this method does no favors.

Improve this answer
1
  • There already exists a framework interface for AbstractFactory -> Func<AbstractProduct> (or at most Func<AbstractProductArgs, AbstractProduct>)
    – Caleth
    CommentedJan 23, 2018 at 12:57

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.