Designing a class in such a way that it doesn't become a "God object"
Posted
by devoured elysium
on Stack Overflow
See other posts from Stack Overflow
or by devoured elysium
Published on 2010-04-07T02:48:09Z
Indexed on
2010/04/07
2:53 UTC
Read the original article
Hit count: 274
I'm designing an application that will allow me to draw some functions on a graphic. Each function will be drawn from a set of points that I will pass to this graphic class.
There are different kinds of points, all inheriting from a MyPoint class. For some kind of points it will be just printing them on the screen as they are, others can be ignored, others added, so there is some kind of logic associated to them that can get complex.
How to actually draw the graphic is not the main issue here. What bothers me is how to make the code logic such that this GraphicMaker class doesn't become the so called God-Object.
It would be easy to make something like this:
class GraphicMaker {
ArrayList<Point> points = new ArrayList<Point>();
public void AddPoint(Point point) {
points.add(point);
}
public void DoDrawing() {
foreach (Point point in points) {
if (point is PointA) {
//some logic here
else if (point is PointXYZ) {
//...etc
}
}
}
}
How would you do something like this? I have a feeling the correct way would be to put the drawing logic on each Point object (so each child class from Point would know how to draw itself) but two problems arise:
- There will be kinds of points that need to know all the other points that exist in the GraphicObject class to know how to draw themselves.
- I can make a lot of the methods/properties from the Graphic class public, so that all the points have a reference to the Graphic class and can make all their logic as they want, but isn't that a big price to pay for not wanting to have a God class?
© Stack Overflow or respective owner