I have multiple shapes to draw such as rectangle, square, circle etc, and this number of shapes can increase to 20 or more than that. Do I have to create different classes for all these shapes and implement Shape. This method would give me lots of classes which I don't prefer.
Is there any design pattern that can better handle such situation?
We have shapes like this , with different object inside each shape. Diagram
A mixture of subclassing and parameters seems to fit this problem.
Guiding principles will be: What helps a developer use the collection of shapes, and what helps the shape implementer to efficiently provide operations (for the various shapes).
The best answer will likely be obtained only after experimentation. Start with a small collection of different types of shapes, and with a test application which performs expected operations on the shapes, and figure out what shape classes work best.
There are many ways to parameterize shapes, for example, circles, ellipses, parabolas, and hyperbolas are examples of conic sections. Squares are rectangles with equal side lengths, but are also regular polygons, which are in turn closed polygons. You may find that careful selection of parameters and of shape types will provide for many common shapes.
You don't have to make a Circle, Square and a Rectangle class, those are usually just examples. There's a myriad of ways to implement drawing any shape - having a class for each individual shape is just one of them.
The major benefit of having a Shape interface is that it allows your client code to not be coupled to the way you currently implement your shapes, but only to the concept of shapes instead.
A Shape, however, doesn't necessarily have to be an object that implements one particular shape like a square or trialngle. Your Shape may have a render() method, it's up to the individual implementations to decide how they do that rendering.
You could, for instance, have a Bitmap implements Shape which keeps a file property and implements render() by displaying an image, while also having a Polygon implements Shape that keeps a list of Point objects and implements render() by drawing lines between those points.
It might still make sense to just start with a Rectangle and a Circle, though (or whichever shapes you happen to start out with) so long as that's the most simple solution. Think of it like this: what if it turns out you only ever need just a circle and a rectangle, and there was never any need for more shapes? If that's the case and you spent five months on a solution that can flawlessly render the most ingenious of shapes, you wasted five months. If indeed it turns out the variety of shapes drastically increases over time, you'll be glad to see all your client code only depending on the concept of a Shape: you simply pass a Polygon or Bitmap instead of a Rectangle or Square and the client code simply keeps on working.
