Can any one tell me what are the advantages & disadvantages - and which is better?
Having many methods (say about 15) in One class - about 10 doing various actions and not interrelated at all.
Vs
spliting the methods to be in their own classes, and instantiating them only when needed? Say in this case there could be about 10 classes thus created .
Thanks
Aarvi
A class should have a relatively low number of methods that offer common functionality or act on the same data (or both). My general rule of thumb is that, aside from accessors and mutators (getters and setters), a class should not have more than 7-10 methods in it. This is not a law or commandment, just a guideline I try to follow.
Why do you have 1 class with 15 'unrelated' methods? Are five of those 15 related? If yes, move them to their own class. If the remainder have nothing at all in common, you might want to rethink your design. Creating 'God' objects that do everything is a bad code smell.
- Saish
Thank you so much for the replies.
First, I asked this question, just to get a list of disadvantages about having many "unrelated" methods inside one class.
I have got a chance to rewrite the existing code that has about 75 "unrelated" methods in one class. ( do not throw me out of this community now).
When I said, these methods should be put in their own class based on their own functionality and can be loaded only when it is called for. The counter argument from the tech arch (!!) here is - "Why not have it in one class? It works now". The tech arch is a cobal type developer.
Have to "Quote" from Java Bibles to why it is a bad code to have "a class that is merely a collection of methods".
Thanks again
RV--
Your technical architect is approching the problem from a procedural view. Java can be written as a procedural language (look at the 'class' he wants to leave as is). However, Java shines when implemented as an object oriented design.
The code may not execute any faster or slower, but by grouping similar concepts into objects (grouping) and hiding the internal implementation details (encapsulation), you can reduce the complexity of the software you are developing because each object has only one purpose that can be tested in isolation.
When you add in the other benefits of OO, especially polymorphism, you really lose out on a lot, especially in your design, if you stick to the procedural model.
Any code that runs correctly is on some level 'good'. However, it could certainly be better. :^)
- Saish
There is not one criterion which you could use to measure the qality of a code. There is a combination:-
1) Functionality
2) Reliability
3) Reusability
4) Portability
5) Maintainability
6) Efficiency
Now dont you think you would be losing on quite a few fronts using only one class. Abstraction, encapsulation, polymorphism are like life blood to OOP. And OO is all about quality programming
>
> I have got a chance to rewrite the existing code that
> has about 75 "unrelated" methods in one class. ( do
> not throw me out of this community now).
> When I said, these methods should be put in their own
> class based on their own functionality and can be
> loaded only when it is called for. The counter
> argument from the tech arch (!!) here is - "Why not
> have it in one class? It works now". The tech arch is
> a cobal type developer.
>
Hate to repeat what was said above (given the source) but.....
an object is not merely a collection of methods,
So far you have referred only to the methods.
Are there any data members?
If no then all you have is a collection of methods. You can of course still break them up but doing so doesn't necessarily mean it will be better. But in terms of the "tech arch" the impact is minimal. That of course doesn't mean that testing isn't required.
On the other hand if there is data then breaking them up would be based on how the data is used by the methods. As for why you would do that, the reason for the "tech arch" would be because the reason for using an OO language is so that one can have objects. And that 'class' is not an object.
Once again thanks for all the replies.
The class is like mere collection of methods, because there is no data members. No methods call the other methods.
Basically the class's only public method acts like a entry and controller. Based on a parameter passed to this method, there are like 75 if statements on that parameter to execute appropriate method.
I found this rather "No OO" design. So I suggested to
1. implement a factory pattern in this that takes the parameter and instantiate app. classes. This takes care of all the IF statements. And by implementing Template/Implementor class design, the other classes are also very simple and follow one set of logic.
2. By keeping the methods in its own classes, testing becomes very easy, as I can get a log of which class has been instantiated.
3. Parallel development on this One class by 2 or more developers is now so simple, as each one of them have to deal with their own class, instead of fighting to get a hold of one class to put in their code!
With all the above advantages, I wanted to include some jargons like loading the class with all the methods Vs loading only class with simple methods.
Any comments?
Thanks again,
RV
> I have got a chance to rewrite the existing code that
> has about 75 "unrelated" methods in one class. ( do
...
> loaded only when it is called for. The counter
> argument from the tech arch (!!) here is - "Why not
> have it in one class? It works now". The tech arch is
> a cobal type developer.
Oh... oh... my ears. Why, God, why?
Drake
A class with lots of unrelated methods is called a god class and is a major anti-pattern/code smell. It is analogous to having every field of a data-model int a single table, a good engineer would never do it. It might be easier in the very short term but not long term. It is wasteful of machine resources and a change to single method requires the whole interface of the class to be retested. It is not OO programming and will make reuse difficult.
The first principle of OO programming is that a class should have only one reason to change, it should have only a single responsibility.
> Once again thanks for all the replies.
>
> The class is like mere collection of methods, because
> there is no data members. No methods call the other
> methods.
>
> Basically the class's only public method acts like a
> entry and controller. Based on a parameter passed to
> this method, there are like 75 if statements on that
> parameter to execute appropriate method.
>
> I found this rather "No OO" design.
Based on your description:
1. It has nothing to do with OO. Again given that there is no data then there is no Object.
2. Nothing you said so fars suggests why it needs to be broken up.
> this method, there are like 75 if statements on that
> parameter to execute appropriate method.
I am sorry to inform you that you have actually died and gone to hell - further to this, you seem to have found your way into a whole new circle of hell, at which they have internet access, which i think it pretty cool, even if they do make you suffer horribley.
> 1. implement a factory pattern
I think thats what i'd do (if quitting really wasn't an option)
> > A class with lots of unrelated methods is called a
> > god class and is a major anti-pattern/code smell.
>
> Not in the case given. There is no data. Thus no object.
A very questionable assertion.
At least some parameter data being sent to identify the operation.
State not a _prerequisite_ of an Object.
There are many objects don't persist state between calls, stateless session beans, adapters, commands to name some.
> The class is like mere collection of methods, because
> there is no data members. No methods call the other
> methods.
...
> Basically the class's only public method acts like a
> entry and controller. Based on a parameter passed to
> this method, there are like 75 if statements on that
> parameter to execute appropriate method.
Checkout the Command pattern.
> > > A class with lots of unrelated methods is called
> a
> > > god class and is a major anti-pattern/code smell.
>
> >
> > Not in the case given. There is no data. Thus no
> object.
>
> A very questionable assertion.
>
> At least some parameter data being sent to identify
> the operation.
> State not a _prerequisite_ of an Object.
>
> There are many objects don't persist state between
> calls, stateless session beans, adapters, commands
> to name some.
Your definition is not standard.
Class != Object.
For example java.lang.Math is not an Object. It is however a class.
One definition for Object....
http://en.wikipedia.org/wiki/Object_%28computer_science%29
Note specifically that it lists two points: data and methods.
Feel free to provide sources for your definition.
> > A class with lots of unrelated methods is called a
> > god class and is a major anti-pattern/code smell.
>
> Not in the case given. There is no data. Thus no
> object.
The generally accepted definition of a 'God class' is one that does most if not all of the work of a system.
At no time it is stated that the class itself has to have data.
Of course, there is a variant of the antipattern where the class has all the system's data.
However, there is another variant where the God class is purely 'behavioral' (a Controller or Manager or else), by centralizing most of (mostly unrelated) operations/methods of the system.
Please feel free to supply references that state otherwise.
> > There are many objects [that] don't persist state between
> > calls, stateless session beans, adapters,
> > commands to name some.
>
> Your definition is not standard.
My post defines neither Class or Object.
It assets that Objects can exist without state and provides examples. Those examples are exceptions that break your rule. To shoot down my position you must demonstrate that all the classes in those patterns are either a) not Objects or b) do contain state.
> Class != Object.
strawman.
> For example java.lang.Math is not an Object.
> It is however a class.
Irrelevant. java.lang.Math should not be instantiated as an Object because all it's methods are static and can not be instantiated because it has a private constructor.
The OP stated "instantiating them only when needed", which implies that the original God Object was also instantiated.
> One definition for Object....
>
> http://en.wikipedia.org/wiki/Object_%28computer_science%29
Wikipedia is long way from an authoritative source.
> Note specifically that it lists two points: data and
> methods.
1) the linked article says "which among other things allows for:" Note it says _allows_ not and _requires_.
2) data is not the same as a property, it includes transient state (e.g. parameters).
> Feel free to provide sources for your definition.
Since I haven't provided a definition, I don't feel it necessary.
> The class is like mere collection of methods, because
> there is no data members. No methods call the other
> methods.
>
> Basically the class's only public method acts like a
> entry and controller. Based on a parameter passed to
> this method, there are like 75 if statements on that
> parameter to execute appropriate method.
>
There are obviously no data members in the controller class itself, but the 75 or so methods that are called should act on data...where is that data located?
All the 'God class' systems that I have seen were the result of procedural thinking, and hence poorly distributed system intelligence, where data and operations on that data were kept in different places.
> > > There are many objects [that] don't persist state
> between
> > > calls, stateless session beans, adapters,
> > > commands to name some.
> >
> > Your definition is not standard.
>
> My post defines neither Class or Object.
>
> It assets that Objects can exist without state and
> provides examples. Those examples are exceptions that
> break your rule. To shoot down my position you must
> demonstrate that all the classes in those patterns
> are either a) not Objects or b) do contain state.
You are specifically stating that an "Object" can exist without "state". That is a definition.
And again that is not a standard definition of an "object".
>
> > Class != Object.
>
> strawman.
Wrong.
I am pointing out that "class" is a type in java. However not all classes in java are objects.
>
> > For example java.lang.Math is not an Object.
> > It is however a class.
>
> Irrelevant. java.lang.Math should not be
> instantiated as an Object because all it's methods
> are static and can not be instantiated because it has
> a private constructor.
That has nothing to do with it. Its methods could just as well be non-static. It wouldn't change the concept of Math but merely how it is used.
>
> The OP stated "instantiating them only when needed",
> which implies that the original God Object was also
> instantiated.
Instantiation has nothing to do with whether a class is actually an object.
>
> > One definition for Object....
> >
> >
> http://en.wikipedia.org/wiki/Object_%28computer_scienc
> e%29
>
> Wikipedia is long way from an authoritative source.
>
Please provide any source that supports your definition.
> > Note specifically that it lists two points: data
> and
> > methods.
>
> 1) the linked article says "which among other things
> allows for:" Note it says _allows_ not and
> _requires_.
> 2) data is not the same as a property, it includes
> transient state (e.g. parameters).
Further down the page it has a section that says "Three properties characterize objects:". That section does not imply that the state is optional. It also specifically says that the state is stored in the object.
>
> > Feel free to provide sources for your definition.
>
> Since I haven't provided a definition, I don't feel
> it necessary.
Your statements provide your definition.
> > A class with lots of unrelated methods is called a
> > god class and is a major anti-pattern/code smell.
>
> Not in the case given. There is no data. Thus no
> object.
They called it a God class not a God object. Debates about the definition of an object notwithstanding, it seems irrelevent whether or not it is an object as they aren't calling it one. If you presume that in order for it to meet the criteria for the anti-pattern mentioned then I'll defer to Wikipedia since you have used it as a source as well:
"God object: Concentrating too many functions in a single part of the design (class)"
Their page on the anti-pattern refers to it as an object but does not indicate it is required to be an object, unless of course the assumed definition in the article is one where an object is not required to have state.
Sure seems like you're arguing about an irrelevent definition.
> You are specifically stating that an "Object" can
> exist without "state".
An this code fragment proves it.
public class Proof {
public static void main(String[] args) {
Object anObject = new Object() ;
System.out.println( anObject != null ) ;
//class aclass = new class() ;
}
}
> That is a definition.
> And again that is not a standard definition of an "object".
No, it is a single characteristic, not a rigorous definition.
> >
> > > Class != Object.
> >
> > strawman.
>
> Wrong.
So you should be able to easily point out where I stated otherwise!
Or do you require me to define a "strawman" ?
> I am pointing out that "class" is a type in java.
> However not all classes in java are objects.
No class is not a type in Java, as proven by this code fragment.
class aclass = new class() ;
> Instantiation has nothing to do with whether a class
> is actually an object.
This contradicts your earlier assertion that "Class != Object".
> >
> > Wikipedia is long way from an authoritative source.
>
> Please provide any source that supports your definition.
Since not even the luminaries of c2.com seem able to produce a definitive definition. I'm not even inclined to try to produce a definitive definition.
http://c2.com/cgi-bin/wiki?NobodyAgreesOnWhatOoIs
> Further down the page it has a section that says
> "Three properties characterize objects:".
I've already stated I don't accept Wikipedia as a authoritive source.
You are of course entitled to disagree.
> > > A class with lots of unrelated methods is called
> a
> > > god class and is a major anti-pattern/code smell.
>
> >
> > Not in the case given. There is no data. Thus no
> > object.
>
> They called it a God class not a God
> object. Debates about the definition of an
> object notwithstanding, it seems irrelevent whether
> or not it is an object as they aren't calling it one.
> If you presume that in order for it to meet the
> e criteria for the anti-pattern mentioned then I'll
> defer to Wikipedia since you have used it as a source
> as well:
>
> "God object: Concentrating too many functions in a
> single part of the design (class)"
I don't see that here (and it specifically mentions data and object)....
http://en.wikipedia.org/wiki/God_object
>
> Their page on the anti-pattern refers to it as an
> object but does not indicate it is required to be an
> object, unless of course the assumed definition in
> the article is one where an object is not required to
> have state.
>
> Sure seems like you're arguing about an irrelevent
> definition.
The original post, without a context might be relevant. However the post was made in this thread. Thus referring to what the OP was doing. And there was no indication up to that point that the OP's code consisted of "objects" which could be broken out.
And a subsequent post seems to make it even less likely that the class represents more than one object (data and method) versus just a collection of methods.
And although one can break up a collection of methods one is going to do so based on something besides OO. And OO is to what the god pattern (class or object) is referring to.
> I don't see that here (and it specifically mentions
> data and object)....
>
> http://en.wikipedia.org/wiki/God_object
Yeah, but that's where using things like Wikipedia as sources falls apart. My quote was from http://en.wikipedia.org/wiki/Anti-pattern where it specifically calls it an object/class that implements too much functionality.
Wikipedia says that it's an object that holds too much functionality. It doesn't explicitly say data is required, that would only be implied if you define an object as something that must have data.It does say "too much data and too many methods" but taken in context I don't think that implies too much data is required otherwise an otherwise normal object that we added 500 unrelated methods to would not be considered a God object.
Of course, if we presume that the article is using a definition of object where an object is required to have data then the anti-pattern article is directly contradicting it by including class. In order for the anti-pattern and God object articles to not conflict we would have to assume a definition of object that is more abstract than the one you're using (which is not to say that your definition is wrong in the context of this discussion, just wrong in the context of those two articles). If that's the case then they're directly contradicting Wikipedia's own definition of object. All of this leads me to the conclusion that because of Wikipedia's nature definitions are not necessarily consistent across articles and therefore cannot be reliably assumed. At the very least, either the definition of a God object or the definition of an object is inconsistent.
My .02 is that the class in question is not an object by the most commonly accepted definition because the class has no state. It fits the "God object" anti-pattern if you use a definition that does not explicitly require the class in question to meet the definition of an object as we're using it. It doesn't fit the anti-pattern define that a "God object" is in fact an object of the definition we're using. Either way, I think the idea behind a "God object" is that it does too much and this class seems to fit that. It does not necessarily need to be broken up, however, breaking it up into many objects with related responsibilities would be a more OO solution and all the benefits that entails. Whether or not in this particular context that is worth the time and effort and whether or not the benefits of an OO solution will actually ever be felt is probably the most important factor in whether or not this should be broken up.
> > I don't see that here (and it specifically
> mentions
> > data and object)....
> >
> > http://en.wikipedia.org/wiki/God_object
>
> Yeah, but that's where using things like Wikipedia as
> sources falls apart. My quote was from
> http://en.wikipedia.org/wiki/Anti-pattern where it
> specifically calls it an object/class that implements
> too much functionality.
>
> Wikipedia says that it's an object that holds too
> much functionality. It doesn't explicitly say data
> is required, that would only be implied if you define
> an object as something that must have data.It does
> say "too much data and too many methods" but taken in
> context I don't think that implies too much data is
> required otherwise an otherwise normal object that we
> added 500 unrelated methods to would not be
> considered a God object.
Not sure what you mean. The quote from the page you gave is a summary for the actual page. The actual page, as I previous noted, specifically refers to data.
I don't believe I said that both too much data and too many methods are required to mandate a god object. What I said was that an object (god or not) was mandated both by data and methods. No quantity was specified.
>
> Of course, if we presume that the article is using a
> definition of object where an object is required to
> have data then the anti-pattern article is directly
> contradicting it by including class.
I think you are still missing the point.
An object is a conceptual entity that has a definition in the concept of object oriented programming.
Class on the other hand refers to the way in which some languages implement an object.
I note that the usage of the above is very loose. And that the usage is often used both ways.
Even so one can never use "object" in place of "class" in java nor C++ source code. So to a certain extent the usage above is certainly dictated by the above usage.
And an object in object oriented programming must have some properties. Given your definition the following is an object.
class MyClass
{
}
And I don't believe that was the intent that the people who originally came up with OO.
> In order for
> the anti-pattern and God object articles to not
> conflict we would have to assume a definition of
> object that is more abstract than the one you're
> using (which is not to say that your definition is
> wrong in the context of this discussion, just wrong
> in the context of those two articles).
It would help me if you would specifically post the link to both and also to refer to what sections in each you are referring to.
> If that's the
> case then they're directly contradicting Wikipedia's
> own definition of object. All of this leads me to
> the conclusion that because of Wikipedia's nature
> definitions are not necessarily consistent across
> articles and therefore cannot be reliably assumed.
Myself I wouldn't mind seeing an authorative reference which defines "object oriented programming" even.
> At the very least, either the definition of a God
> d object or the definition of an object is
> inconsistent.
>
> My .02 is that the class in question is not an object
> by the most commonly accepted definition because the
> class has no state. It fits the "God object"
> anti-pattern if you use a definition that does not
> explicitly require the class in question to meet the
> definition of an object as we're using it.
The only criteria presented so far is that it has a lot of methods, about 75, none of which are related. And java.lang.Math has about 50 - one could suggests that some of those are related.
How many classes, given that none of the methods are related, would you break the OP's class into?
Would you suggest that java.lang.Math be broken in to different classes? Would it be one class per method or one class per groups of methods?
> It
> doesn't fit the anti-pattern define that a "God
> object" is in fact an object of the definition we're
> using. Either way, I think the idea behind a "God
> object" is that it does too much and this class seems
> to fit that. It does not necessarily need to
> be broken up, however, breaking it up into many
> objects with related responsibilities would be a more
> OO solution and all the benefits that entails.
Nothing so far from the OP suggests that there is any relation between any of the methods.
My bloated posts can be summed up into five points:
1. The most commonly accepted definition of "object" is one where data is required.
2. There seems to be debate about whether or not the God object anti-pattern requires an object of the same definition.
3. Wikipedia isn't necessarily consistent so we should be careful about drawing conclusions that are only true if their articles are consistent.
4. Whether or not it's technically a God object, I think if a class is doing too much and holding too much it fits the overall idea.
5. The OP hasn't given enough information to make a determination about whether or not this class does too much so you can't say it is a God object regardless of definition.
> Not sure what you mean. The quote from the page you
> gave is a summary for the actual page. The actual
> page, as I previous noted, specifically refers to
> data.
It's 'summary' directly contradicts the data in it unless you assume the definitions of objects between the two articles are inconsistent or you assume a definition that is inconsistent with Wikipedia's definition of an object. What I mean is Wikipedia is a good resource, but it is not necessarily very consistent and thus I don't accept certain assumptions about it's articles. Namely, that the article about God objects is using the same definition we're using here.
> I don't believe I said that both too much data and
> too many methods are required to mandate a god
> object. What I said was that an object (god or not)
> was mandated both by data and methods. No quantity
> was specified.
The article said that. I was trying to point out that it almost certainly didn't mean data was required and that in no other part of the article did it mention data was required. That leads to the conclusion that the only way for the article to imply that a God object must have data was to assume a definition of object that required it.
> I think you are still missing the point.
>
> An object is a conceptual entity that has a
> definition in the concept of object oriented
> programming.
>
> Class on the other hand refers to the way in which
> some languages implement an object.
>
> I note that the usage of the above is very loose.
> And that the usage is often used both ways.
>
> Even so one can never use "object" in place of
> "class" in java nor C++ source code. So to a certain
> extent the usage above is certainly dictated by the
> above usage.
>
> And an object in object oriented programming must
> have some properties. Given your definition the
> following is an object.
>
> >class MyClass
>{
>}
>
>
>
> And I don't believe that was the intent that the
> people who originally came up with OO.
I don't dispute that definition, I never said otherwise and if I implied it then it was a mistake. My only real point was that the definition of an object isn't important unless the God object anti-pattern requires it. Then we went on to Wikipedia where you implied that's what it was saying and I was pointing out that Wikipedia is inconsistent so it's hard to come to a conclusion of exactly what they meant because it depends on the writer's definition of an object.
> > In order for
> > the anti-pattern and God object articles to not
> > conflict we would have to assume a definition of
> > object that is more abstract than the one you're
> > using (which is not to say that your definition is
> > wrong in the context of this discussion, just
> wrong
> > in the context of those two articles).
>
> It would help me if you would specifically post the
> link to both and also to refer to what sections in
> each you are referring to.
http://en.wikipedia.org/wiki/God_object
"Because this object holds so much data and has so many methods..."
Only place it's implied by the article that data is required and I don't think that's what they meant for reasons stated previously. This being the case in order for a "God object" to require data you must assume the Wikipedia definition of "object" that says an object requires data. But if you do that then...
"God object: Concentrating too many functions in a single part of the design (class)"
Is wrong because a class is not necessarily an object. So either those two articles are using a definition of "object" different than Wikipedia's (which I call 'ours' since we seem to agree on it) in which case the first article doesn't require a God object have data or the two articles are inconsistent.
It's actually a relatively minor inconsistency, I just think it illustrates reasons why Wikipedia's can't be assumed to be using consistent definitions across multiple articles. In which case our attempt to connect "God object" according to Wikipedia and "object" according to Wikipedia and draw some meaningful conclusion that is only supported by one being the definition used in the other is a bit silly.
> Myself I wouldn't mind seeing an authorative
> reference which defines "object oriented programming"
> even.
You and me both, or at least one that is commonly accepted and consistent.
> The only criteria presented so far is that it has a
> lot of methods, about 75, none of which are related.
> And java.lang.Math has about 50 - one could suggests
> s that some of those are related.
>
> How many classes, given that none of the methods are
> related, would you break the OP's class into?
>
> Would you suggest that java.lang.Math be broken in to
> different classes? Would it be one class per method
> or one class per groups of methods?
I got ahead of myself. It's not so much that I think it does as that I think it would if it held "too much" functionality even if it's not an object per se. As you point out they haven't really given enough information to make that determination, so it's not possible to say it does fit the anti-pattern.
On Objects
The common definitions of 'object' or 'object-oriented' do often state that properties/state/data characterise an object. That position may be common, even the majority but that doesn't make it right.It is not necessary to go very far to see common misconceptions and group think at work.
The first principle of 'object-oriented' dictates that an Object has a single responsibility or a single reason to change. Not a single method, not a single property but a single _responsibility_.
At their most abstract Object's do not even have methods or properties, they have behaviour. Peter Kay who is generally credited with originating the term 'Object Orientated' in his paper The Early History of SmallTalk ( http://gagne.homedns.org/%7etgagne/contrib/EarlyHistoryST.html ) stated "objects need to privately own all of their behaviors: that objects are a kind of mapping whose values are its behaviors"
I've always considered the Object Orientated paradigm or mind set to be much closer to functional that procedural languages, even though they are on a sense a hybrid approach and functional languages like Lambda, Miranda, Lisp or Prolog only have transient state, not properties.
On God Class
My initial position on the God Class anti-pattern was mostly based on my position previously expressed and above. That it is an Object with to many responsibilities, or to use Kays language to many behaviours.
A little goggling has turned up Arthur Reihl's Object Oriented Design Heuristics as the original source for this term, however I don't have a copy and couldn't find a direct quote perhaps somebody else does.
On Authoritative Sources
I generally dislike appeals to authority in discussions since unless that authority has been subject to a rigorous peer review or some form of formal proof it has questionable value.
Wikipedia is not an authoritative source; anybody can change it to support their position (I'm not suggesting anybody here has). The most prolific wiki gnomes are those with lots of spare time and limited experience. A lot seem to be students who simply regurgitate positions without truly understanding them. It is useful for a broad introduction, but not the subtleties of this discussion
> My bloated posts can be summed up into five points:
>
> 1. The most commonly accepted definition of "object"
> is one where data is required.
>
> 2. There seems to be debate about whether or not the
> God object anti-pattern requires an object of the
> same definition.
>
> 3. Wikipedia isn't necessarily consistent so we
> should be careful about drawing conclusions that are
> only true if their articles are consistent.
>
> 4. Whether or not it's technically a God object, I
> think if a class is doing too much and holding too
> much it fits the overall idea.
>
> 5. The OP hasn't given enough information to make a
> determination about whether or not this class does
> too much so you can't say it is a God object
> regardless of definition.
From the book "Anti-Patterns" by Brown, etc...
From the section on "The Blob"...
General Form
...characterized by a class diagram composed of a single complex controller class surrounded by data classes..
Symptons and consequences
- Single class with a large number of attributes, operations or both. A class with 50 or more attributes and operations usually indicates the presence of the Blob.
- A disparate collection of unrelated attributes and operations encapsulated in a single class. An overall lack of cohesiveness of the attributes and operations.
- A single controller class with associated simple, data-object classes.
Note also that the OP specifically stated that none of the methods calls any others.
So (which I believe I already asked) is the suggested solution 75 classes with a single method each?
> >
> > > >class MyClass
> >{
> >}
> >
> >
> >
> > And I don't believe that was the intent that the
> > people who originally came up with OO.
>
> I don't dispute that definition, I never said
> otherwise and if I implied it then it was a mistake.
So you agree that an "Object" must have data and methods or it isn't an Object?
> My only real point was that the definition of
> f an object isn't important unless the God object
> anti-pattern requires it.
Ok. The definition I provided above actually suggests that multiple classes can exist so it isn't limited to a single class.
Even so, given that the OP specifically stated that the methods do not interact I don't see how it can match this particular anti-pattern in any way.
> Then we went on to
> Wikipedia where you implied that's what it was saying
> and I was pointing out that Wikipedia is inconsistent
> so it's hard to come to a conclusion of exactly what
> they meant because it depends on the writer's
> definition of an object.
>
Yes, but is there any authorative source to which one can rely on for the subject?
If there is no definitive source then Wikipedia is as good as the others.
> >
> > It would help me if you would specifically post the
> > link to both and also to refer to what sections in
> > each you are referring to.
>
> http://en.wikipedia.org/wiki/God_object
>
> "Because this object holds so much data and has so
> many methods..."
>
> Only place it's implied by the article that data is
> required and I don't think that's what they meant for
> reasons stated previously. This being the case in
> order for a "God object" to require data you must
> assume the Wikipedia definition of "object" that says
> an object requires data. But if you do that then...
>
> "God object: Concentrating too many functions in a
> single part of the design (class)"
>
> Is wrong because a class is not necessarily an
> object. So either those two articles are using a
> definition of "object" different than Wikipedia's
> (which I call 'ours' since we seem to agree on it) in
> which case the first article doesn't require a God
> object have data or the two articles are
> inconsistent.
I can see your point but as I pointed out the way I read the first is that it is attempting to summurize the actual pattern rather than define it. And ithe summary has the link to the actual definition.
> >
> > Would you suggest that java.lang.Math be broken in to
> > different classes? Would it be one class per
> method
> > or one class per groups of methods?
>
> I got ahead of myself. It's not so much that I think
> it does as that I think it would if it
> held "too much" functionality even if it's not an
> object per se. As you point out they haven't really
> given enough information to make that determination,
> so it's not possible to say it does fit the
> anti-pattern.
The OP specifically said that none of the methods interact.
I have seen a class, presumably this anti-pattern, once and it had over 200 attributes and over 200 methods. And the methods definitely did interact.
> On Objects
>
> The common definitions of 'object' or
> 'object-oriented' do often state that
> properties/state/data characterise an object. That
> position may be common, even the majority but that
> doesn't make it right.It is not necessary to go
> very far to see common misconceptions and group think
> at work.
So you personally disagree with the common definition.
Not a problem - but then you must explicitly make that clear everytime that you discuss that. It isn't incumbent on the population at large to figure out that you choose to use a different definition.
>
> The first principle of 'object-oriented' dictates
> that an Object has a single responsibility or a
> single reason to change. Not a single method, not a
> single property but a single _responsibility_.
Based on what authorative source for what that first principle is?
And who decides what is single?
>
> At their most abstract Object's do not even have
> methods or properties, they have behaviour. Peter
> Kay who is generally credited with originating the
> term 'Object Orientated' in his paper The Early
> History of SmallTalk (
> http://gagne.homedns.org/%7etgagne/contrib/EarlyHistor
> yST.html ) stated "objects need to privately own all
> of their behaviors: that objects are a kind of
> mapping whose values are its behaviors"
And it also says....
." For the first time I thought of the whole as the entire computer and wondered why anyone would want to divide it up into weaker things called data structures and procedures.
...
Four techniques used together--persistent state, polymorphism, instantiation, and methods-as-goals for the object--account for much of the power.
...
Generally, we don't want the programmer to be messing around with state, whether simulated or not
>
> I've always considered the Object Orientated paradigm
> or mind set to be much closer to functional that
> procedural languages, even though they are on a sense
> a hybrid approach and functional languages like
> Lambda, Miranda, Lisp or Prolog only have transient
> state, not properties.
>
> On God Class
>
> My initial position on the God Class anti-pattern was
> mostly based on my position previously expressed and
> above. That it is an Object with to many
> responsibilities, or to use Kays language to many
> behaviours.
>
> A little goggling has turned up Arthur Reihl's Object
> Oriented Design Heuristics as the original source for
> this term, however I don't have a copy and couldn't
> find a direct quote perhaps somebody else does.
>
The "Anti-Patterns" book I cite in the previous thread has a copyright date of 1998 and references 'Akroyd 96' and 'Riel 96'
Checking the biblography of the book would suggest that it is the very same one that you are citing (despite the different name spelling.)
> On Authoritative Sources
>
> I generally dislike appeals to authority in
> discussions since unless that authority has been
> subject to a rigorous peer review or some form of
> formal proof it has questionable value.
Agreed.
However given that we have not agreed on a definition and seem at odds over what our individual definitions entail how else would you resolve the situation?
>
> Wikipedia is not an authoritative source; anybody can
> change it to support their position (I'm not
> suggesting anybody here has). The most prolific wiki
> gnomes are those with lots of spare time and limited
> experience. A lot seem to be students who simply
> regurgitate positions without truly understanding
> them. It is useful for a broad introduction, but not
> the subtleties of this discussion
Again true. But it is a source that is outside of our two personal definitions.
> So (which I believe I already asked) is the suggested
> solution 75 classes with a single method each?
I haven't suggested a solution because I don't have enough information to propose one. I haven't made any judgement about what they should do because I can't. If I implied I thought they should do something without properly qualifying it then I misspoke.
> So you agree that an "Object" must have data and
> methods or it isn't an Object?
I agree that it is the most commonly accepted definition and I do not dispute it for purposes of this discussion. My own thoughts on what an object is aren't relevent.
> Yes, but is there any authorative source to which one
> can rely on for the subject?
Probably not.
> If there is no definitive source then Wikipedia is as
> good as the others.
If the other source(s) are inconsistent. Another source might not be any more authorative, but if it were consistent it'd have a leg up on Wikipedia.
> The OP specifically said that none of the methods
> interact.
>
> I have seen a class, presumably this anti-pattern,
> once and it had over 200 attributes and over 200
> methods. And the methods definitely did interact.
If it is responsbile for "too much", which is something I don't think we can know without more information, then it should probably be broken up. I'm not sure how the methods not interacting with each other changes that.
> > So (which I believe I already asked) is the
> suggested
> > solution 75 classes with a single method each?
>
> I haven't suggested a solution because I don't have
> enough information to propose one. I haven't made
> any judgement about what they should do
> because I can't. If I implied I thought they
> should do something without properly
> qualifying it then I misspoke.
That though would be the outcome if the class is a god pattern.
However if there is no relation between any of the methods, the only grouping possibility is if one breaks it up by individual method.
> > I have seen a class, presumably this anti-pattern,
> > once and it had over 200 attributes and over 200
> > methods. And the methods definitely did interact.
>
> If it is responsbile for "too much", which is
> something I don't think we can know without more
> information, then it should probably be broken up.
> I'm not sure how the methods not interacting with
> h each other changes that.
Because breaking it up means that it must be broken up using some methodology. It can either be broken into 75 classes or some grouping of common functionality could be used.
For instance if one were to break up java.lang.Math one could group all of the integer methods together in one class and all of the floating point in another. Or one could break up by putting the trig methods in one and everything else in another.
However, so far nothing the OP has said suggests that there is any relationship between any of the methods. So, to me, nothing that the OP has said so far would suggest, any more than with java.lang.Math, that the class should be broken up.
> > On Objects
> >
> > The common definitions of 'object' or
> > 'object-oriented' do often state that
> > properties/state/data characterise an object.
> > That position may be common, even the majority but that
> > doesn't make it right.It is not necessary to go
> > very far to see common misconceptions and group
> > think at work.
>
> So you personally disagree with the common
> definition.
No, they are typically over simplistic, but then I'm sure you already know that.
> Not a problem - but then you must explicitly make
> that clear everytime that you discuss that. It isn't
> incumbent on the population at large to figure out
> that you choose to use a different definition.
I disagree, I would say it IS incumbent on people who claim to OO experts to understand the gross generalisation of common OO definitions compared to subtlety of more complete understanding.
AIH this discussion started of with me stating that the assertion that an object without data is not an object is very questionable.
> > The first principle of 'object-oriented' dictates
> > that an Object has a single responsibility or a
> > single reason to change. Not a single method, not
> a
> > single property but a single _responsibility_.
>
> Based on what authorative source for what that first
> principle is?
http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign
> And who decides what is single?
That is clearly the architect/designs responsibility.
> > > On Objects
> > >
> > > The common definitions of 'object' or
> > > 'object-oriented' do often state that
> > > properties/state/data characterise an object.
> > > That position may be common, even the majority but that
> > > doesn't make it right.It is not necessary to go
> > > very far to see common misconceptions and group
> > > think at work.
> >
> > So you personally disagree with the common
> > definition.
>
> No, they are typically over simplistic, but then I'm
> sure you already know that.
>
I don't see that definition as being simplistic.
> > Not a problem - but then you must explicitly make
> > that clear everytime that you discuss that. It isn't
> > incumbent on the population at large to figure out
> > that you choose to use a different definition.
>
> I disagree, I would say it IS incumbent on people who
> claim to OO experts to understand the gross
> generalisation of common OO definitions compared to
> subtlety of more complete understanding.
Based on your definition which most people do not agree with.
Again I would like to see one "expert" definition, besides your own, that equates to what you are saying.
>
> AIH this discussion started of with me stating that
> the assertion that an object without data is not an
> object is very questionable.
That might not be why this discussion started but you did specifically state that in reply #14...
State not a _prerequisite_ of an Object.
But actually this discussion started with you asserting that OP's code suggested a god class. I then pointed out that there was no data. And since then I have provided another sources, besides wikipedia, which supports that data is definitely part of the god pattern.
>
> > > The first principle of 'object-oriented' dictates
> > > that an Object has a single responsibility or a
> > > single reason to change. Not a single method, not
> > a
> > > single property but a single _responsibility_.
> >
> > Based on what authorative source for what that first
> > principle is?
>
> http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign
In reply #18, #22 and #27 you stated that wikipedia is not a authorative source.
>
> > And who decides what is single?
>
> That is clearly the architect/designs responsibility.
Although the above discussion might have merit it isn't something that necessarily I disagree with.
But it doesn't have anything to do with whether a class is an object if it doesn't have data either.
> http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign
>
> In reply #18, #22 and #27 you stated that wikipedia
> is not a authorative source.
C2.com is the Portland Pattern repository, it is a wiki, but it is not wikipedia. My problem with wikipedia is the low quality of it's typical contributors, not that's it's a wiki.
I don't think there is anything else to be gained from further discussion of the Object state issue.
> >
> http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesig
> n
> >
> > In reply #18, #22 and #27 you stated that
> wikipedia
> > is not a authorative source.
>
> C2.com is the Portland Pattern repository, it is a
> wiki, but it is not wikipedia. My problem with
> wikipedia is the low quality of it's typical
> contributors, not that's it's a wiki.
Ok.....
http://c2.com/cgi/wiki?ObjectOriented
My CeePlusPlus professor explained this concept thus: "objects are data with methods attached."
Myself the above sentence would not suggest an authorative source. But it is from the site that you state is more authoratative.
> > >
> >
> http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesig
>
> > n
> > >
> > > In reply #18, #22 and #27 you stated that
> > wikipedia
> > > is not a authorative source.
> >
> > C2.com is the Portland Pattern repository, it is a
> > wiki, but it is not wikipedia. My problem with
> > wikipedia is the low quality of it's typical
> > contributors, not that's it's a wiki.
>
> Ok.....
>
> http://c2.com/cgi/wiki?ObjectOriented
>
>
> My CeePlusPlus professor explained this concept thus:
> "objects are data with methods attached."
>
>
>
> Myself the above sentence would not suggest an
> authorative source. But it is from the site that you
> state is more authoratative.
The authoritative source is indirectly Robert C. Martin.I also see Bertrand Meyer and Barbara Liskov mentioned, but I don't actually see anywhere that either of those people supported the specific principle in question.
