Designing a class in such a way that it doesn't become a “God object”

问题

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?

回答1:

I would do as you suggested and make each point responsible for drawing itself, passing the array of other points to it:

interface ICanDraw {
    void Draw(ArrayList<Point> allPoints);
}

public abstract class Point : ICanDraw {
    ...
}

public PoniePoint : Point {
    public void Draw(ArrayList<Point> allPoints) {
        // do drawing logic here
    }
}

For your GraphicMaker:

public void DoDrawing() {
    foreach (Point point in points) {
        point.Draw(points);
    }
}

(My Java is a bit rusty, so that might not 100% syntactically correct Java but I think it conveys my suggestion).

回答2:

You are correct that each subclass of Point should have its own drawing method overriding the one in the base Point class.

The drawing method should take a reference to the graphics object, which should have public methods/properties for anything that needs to be used in the point drawing methods, including the list of points if that is one of the things some of the drawing methods need.

Why are you concerned about making public methods on the graphics class? Once the code grows, a few extra visible methods is a lot less confusing than one huge method that does everything.

来源：https://stackoverflow.com/questions/2589703/designing-a-class-in-such-a-way-that-it-doesnt-become-a-god-object

标签

java

design-patterns

oop

god-object