Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #30710 > unrolled thread

Re: "How do you arrive at classes?"

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: "How do you arrive at classes?" Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-01-14 11:40 -0600
    Re: "How do you arrive at classes?" Robert Klemme <shortcutter@googlemail.com> - 2015-01-14 20:29 +0100

#30710 — Re: "How do you arrive at classes?"

On 1/13/2015 10:57 PM, ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>    I tried to answer the question »How do you arrive at
>    classes?« in the classroom, kind-a stuttering, because
>    I was not prepared for this question. Now, I am curious:
>    How would /you/ answer this question?

The shortest answer is "there is no one true way to do this."

A longer response:
The primary point of object-oriented programming is to break the state 
up into a series of objects each responsible for managing its own state. 
Keeping that in mind, a class is a collection of state and its 
manipulators that can be reasoned about independently of the rest of the 
program. As you work through and design the system and its API, classes 
will tend to fall out naturally as things that just make sense to exist.

A caveat is that ultimately the purpose of design is to produce the most 
maintainable program. Sometimes, things are so simple that adding 
classes makes the code less, rather than more, maintainable. An example 
is parsers: if you're parsing a complex programming language like Java, 
you'll want to have a distinct Parser class. But if you're parsing 
something as simple as an RFC 822 address string, you'll probably want 
to make it a method. Simple here does not mean lines of code (the latter 
parser is ~500 lines of code and one using the former framework is ~700 
lines of code, both including very copious comments), but is rather the 
utility and reuse of state between methods.

Another caveat is that there is room for reasonable disagreement: two 
different answers on what are classes in a particular applications can 
both be right.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [next] | [standalone]

#30711

On 14.01.2015 18:40, Joshua Cranmer 🐧 wrote:
> On 1/13/2015 10:57 PM, ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>>    I tried to answer the question »How do you arrive at
>>    classes?« in the classroom, kind-a stuttering, because
>>    I was not prepared for this question. Now, I am curious:
>>    How would /you/ answer this question?
>
> The shortest answer is "there is no one true way to do this."

Right.

> A longer response:
> The primary point of object-oriented programming is to break the state
> up into a series of objects each responsible for managing its own state.
> Keeping that in mind, a class is a collection of state and its
> manipulators that can be reasoned about independently of the rest of the
> program. As you work through and design the system and its API, classes
> will tend to fall out naturally as things that just make sense to exist.

... if you have some experience.

> A caveat is that ultimately the purpose of design is to produce the most
> maintainable program.

Not always: if it's a one off or there are other goals much more 
important (e.g. performance) then maintainability can be sacrificed with 
good reasons.

> Sometimes, things are so simple that adding
> classes makes the code less, rather than more, maintainable. An example
> is parsers: if you're parsing a complex programming language like Java,
> you'll want to have a distinct Parser class. But if you're parsing
> something as simple as an RFC 822 address string, you'll probably want
> to make it a method. Simple here does not mean lines of code (the latter
> parser is ~500 lines of code and one using the former framework is ~700
> lines of code, both including very copious comments), but is rather the
> utility and reuse of state between methods.

Absolutely agree.

> Another caveat is that there is room for reasonable disagreement: two
> different answers on what are classes in a particular applications can
> both be right.

That hints to that "right" and "wrong" are probably the wrong categories 
to judge a design. :-)

Cheers

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web