Can a piece of code, if reusable and applicable to different contexts be classified a pattern?

Question

What constitutes a pattern ? If i have a template/code that is reusable and can be applied to other similar situations, can it be called a pattern ?

The following is what i have created. It is a binary approach to handling conditional constructs. I have a field in a table that is composite i.e. it comprises of 3 or more other sub-fields each of which have a true or false value.

Now, i have the sub-fields representing true/false values as 0 and 1. These fields are presented as drop downs to the user in the web based application. These fields are combined to form a byte value comprising 8 bits with the first 3 bits have values of 0 or 1 which the user chooses as false or true. If the user chooses all fields as true the main field would have a value 7 and if he chooses all fields as false, the main field would have a value 0 and like wise.

The main field represents one of the columns in an existing table. The advantage of this code is that, as new sub-fields are required, there is no need to add new columns in the table. The user interface would have an additional drop down for each new sub-field.

This code is reusable and can be applied to different contexts. Could this be classified as a pattern ?

Answer 1

A Pattern isn't the actual code it is the method. A guess this could be some kind of pattern... I would say that patterns tend to be peices of logic/methods that are pared back to their basic form and have uses to many people in many situations.

Not sure whether your method is one of those or not?!

Answer 2

There are langage patterns but mostly a pattern refers to a design rather than anything specific to a language.

The thing you describe I would call a component.

As an aside, storing more than one value in a column is probably against the guidelines of normalization. It might be easier for you in the long run if you used a column per value.

See the first answer to this question for an illustration of normalization.

Answer 3

Well, design patterns are typically more abstract than this. There is, no doubt, an underlying pattern here. However, the details of how you are storing become more implementation detail rather than part of a pattern. Now, you could probably think deeply and discern the underlying patten that you're using. It's a bit late for me to think that deeply about it right now, though. :) But, you are taking a sort of meta data approach and that has some relationship to things like Entity Attribue Value (though, this isn't a case of EAV).

Answer 4

Not really. A pattern is a solution, a way to approach a common programming problem, and not a piece of code.

What you're describing is better named a module or a library (or even a function/subroutine) that does something.

Answer 5

From Design Patterns:

"Point of view affects one's interpretation of what is and isn't a pattern. One person's pattern can be another person's primitive building block."

It also says that, in general, patterns have four essential elements:

• name
• problem
• solution
• consequences

I think it's reasonable to say that even some of the techniques that a very experienced programmer would call primitive building blocks can be viewed as a pattern for a beginner. If I was teaching a brand new programmer I think I'd start talking about patterns straight away, relating them to language constructs like loops (for...next, do...while, etc) and error handling (try...catch, on error goto, etc.) and then introduce the idea that you can create and use your own patterns (e.g. lazy initialisation, guard clauses).

I read somewhere that the really useful patterns will eventually get incorporated into languages, so I always imagine that the for...next loop started off as an assembler pattern. So today's design patterns are tomorrow's primitive building blocks are the-day-after-tomorrow's language features.

Answer 6

What you have is a component. A pattern is a technique for building components, and isn't specific to any particular problem domain.