What Pattern am I looking for?

Question

0.00/5 (No votes)

See more:

I have:

Several color classes, RGB, CMYK etc.
Each has the same 'ToGrey' methods (Desaturate, Decompose etc.)

Initially there was just one ToGrey method in each class which took a parameter to decide which actual method to use. I'm now implementing the strategy pattern in order to avoid having the switch statements in this earlier method.

Therefore I need to have:
A class for each ToGrey implementation.
An associated interface.
A contect class and an instance of that class in each color class.

However, each ToGrey implementation needs to take any one of several different color classes, so the method signature needs an interface rather than a color class and it needs to be the interface that permits type casting between the color types (since some ToGrey methods are RedChannel, BlueChannel etc.) hence asking for the RedChannel grey version of a CMYK or HSL color becomes possible, since I know I can convert the passed object to an RGB type. Either that or every ToGrey implementation needs to be overloaded with every color type.

That's starting to feel messy and hance the design must be wrong (I think).
Any ideas?

Addendum
==========
The next problem with the above thinking is that once I get an instance of a color (but which I must treat as the interface) and convert it to e.g. RGB in order to get the RedChannel then it's easy apart from when I need to convert it back to its original class type, since I have no idea what that was!

Thanks,
M

Posted 20-Oct-13 10:31am

M-Badger

Updated 20-Oct-13 10:38am

v2

Add a Solution

Comments

Andreas Gieriet 20-Oct-13 16:40pm

How do you want to call the ToGrey method? Are the various color classes polymorph, i.e. they implement an IColor interface?
E.g.

IColor color = GetSomeColorImplementation(...);
...
... = color.ToGrey();

Cheers
Andi

M-Badger 20-Oct-13 16:48pm

aCMYK newColor = new aCMYK();
newColor.ToGrey(GreyScaleMethod.RedChannel)

Public Interface IToGrey
Sub ToGrey(ByRef color As IColorModelConvertible)
End Interface

Public Interface IColorModelConvertible
Function ToARGB(Optional ByVal alpha As Integer = 255) As aRGB
Function ToColor(Optional ByVal alpha As Integer = 255) As Color
Function ToAHSB() As aHSB
Function ToAHSL() As aHSL
Function ToACMYK() As aCMYK
Function ToHex(Optional ByVal alpha As Integer = 255) As String
End Interface

Public Class RGBAverage
Implements IToGrey
Public Sub ToGrey(ByRef color As IColorModelConvertible) Implements IToGrey.ToGrey
Dim newARGB As aRGB = color.ToARGB()
newRGB.Green = newRGB.Red()
newRGB.Blue = newRGB.Red()
color = newRGB.To [Help: Don't know original class type!)
End Sub

Andreas Gieriet 20-Oct-13 18:07pm

You may add the needed SetFromRGB(...) etc. functions to the IColorModelConvertible to allow modify an existing polymorphic instance. Your last statement in RGBAverage::ToGrey(...) method would then be color.SetFromRGB(newRGB).
Cheers
Andi

Sergey Alexandrovich Kryukov 21-Oct-13 0:00am

I have a couple of somewhat different ideas. First of all, the concept of color does not have to be the same as OP envisioned it.
Please see my answer.
—SA

Andreas Gieriet 21-Oct-13 2:25am

Hello Sergey,
I fully agree with your assessment. I was about to write a solution for it but deferred that task since it was more than a quick answer...
Cheers
Andi

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-10-20T17:59:00

I think, in your speculations on the classes, interfaces and methods you already limited yourself to some unreasonably rigid set of possible type designs. You need to take a wider look.

I can see two approaches.

First one would be this: you have one and only one color class. This and only this class can be used for all drawing needs, such as rendering. This class should encapsulate the pure idea of color and not expose any color components at all. In other words, internal representation of color should be hidden and not directly accessible Instead, you should have separate unrelated classes called RRG, CMYK, HSL, etc. This classes should not be used for rendering, but only for color calculations through color components. They should conduct the idea of "a point in color space". Let's say, they all have a common base class PointInColorSpace, and this base class is abstract.

Now, the class Color should have a constructor taking a parameter of the type PointInColorSpace. Better yet, each of the classes derived from PointInColorSpace should provide their own implementation of the methods: Color ToColor() returning the object of the class Color and static method void FromColor(Color), and a call to the method ToColor should be the only way to produce and instance of the type Color, except for the "default color", which can be expressed in the form of the parameterless constructor Color().

So, where is the place for ToGray in this schema? Only as Color.ToGray. Only one method for only one (internal, hidden) representation of color. For all other color spaces, the gray point will be found by taking the value returned by ToGray and constructing an instance of PointInColorSpace via each concrete implementation of FromColor. If you consider this schema properly you will find that it is operationally complete.

The second approach could be having different color classes derived from the base class Color. This class would be abstract, in contrast to the very different class Color suggested before. The methods like ToGray would be also abstract, overridden in each of the concrete implementations of color. The second approach is naturally less flexible, even though it may mean less work. Besides, it would not reflect a nature of color. You should make distinction between a color and a point in color space.

—SA