Proper class hierarchy
Hi all
I've a class hierarchy problem. I'm trying, to create classes that will parse XML files for different sports, and display them in the table. I've no influence on XML files which I read, and they are different for each sport. To avoid code repeating I've created such a structure:
[CODE]
public interface Sport {
public List getMatchlist(Integer leagueId);
public void addMatchlist(Integer localCategoryId);
public void addMatch(Integer categoryId, Map data);
}
...
public abstract class TeamSport implements Sport {
public List getMatchlist(Integer remoteLeagueId, int NOT_STARTED_STATUS) throws Exception {
// here between other lines I need to invoke function from class that extends this class...
[...]
}
[...]
}
...
public class Soccer extends TeamSport{
private static String SPORT_ID = "s";
public Soccer(Map params) {
super(params, SPORT_ID);
}
public String getRemoteStatusName(int statusCode) {
return SoccerStatusCodes.getStatusName(statusCode);
}
public int getRemoteNotStartedStatus() {
return SoccerStatusCodes.NOT_STARTED;
}
}
[/CODE]
What my problem is, that for team sports xml are very similar, but xml node attribute status has different values for each sport. And I need to use it in TeamSport.getMatchlist class. I'd need to invoke Soccer.getRemoteNotStartedStatus() function to get correct value for given value. Obviously it's not possible, because TeamSport is superclass of Soccer. The simplest solution is to copy getMatchlist method from TeamSport to Soccer class and every other sport, but it's resulting in duplicating the code, what I want to avoid.
Can anybody help?
Michal
[1820 byte] By [
mglowackia] at [2007-11-27 2:17:39]
# 1
You can remove the Soccer class and make TeamSport a concrete class. Add a private field called "sportName" and get/set methods for the field.When you parse the team sports XML file, you set the "sportName" field and work from there.
# 2
> You can remove the Soccer class and make TeamSport a
> concrete class. Add a private field called
> "sportName" and get/set methods for the field.
>
> When you parse the team sports XML file, you set the
> "sportName" field and work from there.
why should TeamSport be concrete, though? a team sport, as of itself, cannot exist. there must be something more specific, like, well, Soccer, to be played. ergo, shouldn't TeamSport remain abstract?
# 3
> why should TeamSport be concrete, though? a team
> sport, as of itself, cannot exist. there must be
> something more specific, like, well, Soccer, to be
> played. ergo, shouldn't TeamSport remain abstract?
By making the TeamSport a concrete class, you solve the problem of the visibility of the getMatchlist method.
Creating a individual class definition for each sport seems like a silly waste of time, if someone likes to simply write code, they can go for it.
A team sport can and does exist in the real world, basketball is a team sport, so is baseball, etc. Each team sport that exists in the real world has a name that describes the game that is played, e.g. football, rugby. The name is a description of the sport that is played.
In an object-oriented model, it makes sense that the description of the entity be a field name, in my opinion. Without business requirements, there is no need to create a specific class for each individual sport.
If there are specific requirements that mandate special behavior that only one sport will do, then a extension would be made. The getMatchlist method does not seem specific to only the Soccer sport.
Again, without specific requirements, they can be many designs.
# 4
> > why should TeamSport be concrete, though? a team
> > sport, as of itself, cannot exist. there must be
> > something more specific, like, well, Soccer, to be
> > played. ergo, shouldn't TeamSport remain abstract?
>
> By making the TeamSport a concrete class, you solve
> the problem of the visibility of the getMatchlist
> method.
what problem?
> Creating a individual class definition for each sport
> seems like a silly waste of time, if someone likes to
> simply write code, they can go for it.
>
> A team sport can and does exist in the real world,
> basketball is a team sport, so is baseball, etc. Each
> team sport that exists in the real world has a name
> that describes the game that is played, e.g.
> football, rugby. The name is a description of the
> sport that is played.
hmmm. interesting model. feasible, indeed. I can see maintenance increasing exponentially, though: a lot of "if sportName.equals("football")" and so on and so forth, more code to be added to controllers for each new sport. still, the notion of a "team sport" as a concrete entity does seem attractive
# 5
> hmmm. interesting model. feasible, indeed. I can see
> maintenance increasing exponentially, though: a lot
> of "if sportName.equals("football")" and so on and
> so forth, more code to be added to controllers for
> each new sport. still, the notion of a "team sport"
> as a concrete entity does seem attractive
What does 'maintenance' have to do with the conditional test of the value of sportName variable?
What makes you think that the if statement would be required anywhere? And, what makes you think that there will be controllers for each sport?
The problem the OP stated was there was no access to the method in TeamSport. Whether he/she was correct or not is another story.
Regardless, the better design is to make TeamSport concrete and not code a separate class for each sport, in my opinion.
Aside, software maintenance and software design are two different concepts.
# 6
Obviously, as the OP explained, each sport has different attributes and values, e.g. the status stuff as shown in the Soccer class.
If the result shall be one common class TeamSport that contains all the information, the OP might employ factories or parser/translator classes to transform incoming XML to a common representation. I agree, that these not necessarily require a subclassing approach, but one would definitely need some sport-type dependent object to at least do the mentioned transformations.
As georgemc pointed out, using a String (or alternatively an enum) field to distinct between each sport would result in rather nasty if-else or switch statements to perform those transformations making maintenance a pain. And I strongly disagree with GhostRadioTwo, that maintenance is no design issue. Good design always should support and consider maintenance as an important part of the applications lifecycle.
# 7
> > hmmm. interesting model. feasible, indeed. I can
> see
> > maintenance increasing exponentially, though: a
> lot
> > of "if sportName.equals("football")" and so on
> and
> > so forth, more code to be added to controllers for
> > each new sport. still, the notion of a "team
> sport"
> > as a concrete entity does seem attractive
>
> What does 'maintenance' have to do with the
> conditional test of the value of sportName variable?
a lot. as new sports are added, that test can have new results. unless these sport classes exist purely for their own sake, something else is using them. and that something else needs to be maintained
> What makes you think that the if statement would be
> required anywhere? And, what makes you think that
> there will be controllers for each sport?
see above for the "if" statement. controllers was just an example of a class that would use these "sport" classes, something has to use them, and the OP hasn't specified what, so a little guesswork was involved
> The problem the OP stated was there was no access to
> the method in TeamSport. Whether he/she was correct
> or not is another story.
it's a public method. how would it not be accessible? you don't think that, as an analyst, it's your job to identify incorrect assumptions?
> Regardless, the better design is to make TeamSport
> concrete and not code a separate class for each
> sport, in my opinion.
I'm undecided. I think your concrete TeamSport idea is interesting, but I'm unsure. having a general-purpose sport, that is configurable, could be open to having nonsensical configurations made, such as soccer on ice
> Aside, software maintenance and software design are
> two different concepts.
are they? I strongly disagree. what is a "good" design? IMO, a good design must, by necessity, facilitate the adding of new features, the extending of the application. that is maintenance is it not?
# 8
phew, loud conversation I've started...
Anyway my solution was quite simple, I've just made two functions in TeamSport abstract (getRemoteStatusName and getRemoteNotStartedStatus). I implement them in concrete sport's class and everything works fine now.
Regarding discussion if creating concrete class for each sport is necessary. It is, because I need to get different set of statuses for each sport, and each sport has own class which has them stored as static int fields. And some fields are different, like in footlball FIRST_HALF, and in basket ball FIRST_QUARTER.
# 9
Ah, but you can solve that by using enumerated types for the statusof each sport, making each type implement an interface, and returningthe correct implementation from the sport.
# 10
> I agree, that these not necessarily require a
> subclassing approach, but one would definitely need
> some sport-type dependent object to at least do the
> mentioned transformations.
The type of sport would be derived from the XML data. The mentioned transformations should occur as generically as possible, and transformations should be governed by XML format and not XML content.
> And I strongly disagree with GhostRadioTwo, that maintenance is no > design issue. Good design always should support and consider
> maintenance as an important part of the applications
> lifecycle.
Sounds good, but I never stated that "maintenance is no design issue". What I stated, (see above), is that software maintenance and software design are two different concepts.
Yes, good design should always take maintenance into consideration, but, and this is a big but, they are still different concepts.
Maintenance has to do with debugging client and user issues, configuration settings, mappings, restarting applications, data loading, data refreshing, reporting, cleaning the toliet, etc.
Adding new features, reengineering applications, creating new extensions of an application is software design, not maintenance, in my opinion.
You could design an application with 25 individual classes, one for each sport, and successfully meet/satisfy the business/domain requirements.
I'm 93.3% sure that I could design an application with a TeamSport class and maybe one or two helpers, and successfully meet/satisfy the same business/domain requirements.
Like I mentioned earlier, there can be many designs, you pick which one you want to call proper :o)
Whether you call something a "quarter" or a "period" or a "round" does not mandate the creation of a distinct class, in my opinion.
Remember, programming and object-oriented design are different concepts. One can learn to program in a few months, it takes 2+ years of dedicated study to learn object-oriented design and to be able to skillfully craft complex business object models based on complex business requirements.
# 11
> > I agree, that these not necessarily require a
> > subclassing approach, but one would definitely
> need
> > some sport-type dependent object to at least do
> the
> > mentioned transformations.
>
> The type of sport would be derived from the XML data.
> The mentioned transformations should occur as
> generically as possible, and transformations should
> be governed by XML format and not XML content.
>
> > And I strongly disagree with GhostRadioTwo, that
> maintenance is no > design issue. Good design always
> should support and consider
> > maintenance as an important part of the
> applications
> > lifecycle.
>
> Sounds good, but I never stated that "maintenance is
> no design issue". What I stated, (see above), is that
> software maintenance and software design are two
> different concepts.
>
> Yes, good design should always take maintenance into
> consideration, but, and this is a big but, they are
> still different concepts.
>
> Maintenance has to do with debugging client and user
> issues, configuration settings, mappings, restarting
> applications, data loading, data refreshing,
> reporting, cleaning the toliet, etc.
>
> Adding new features, reengineering applications,
> creating new extensions of an application is software
> design, not maintenance, in my opinion.
I don't really think it's a matter of opinion. maintenance is the ongoing process of keeping software running. over time, the requirements will change, new features will be added, this is part of the maintenance programmers job. a good design makes this easy, a bad design does not. I would not consider any design good unless it had addressed the problem of extensibility. the relationship between a good design and maintenance is stronger than merely a consideration
# 12
> I don't really think it's a matter of opinion.
> maintenance is the ongoing process of keeping
> software running. over time, the requirements will
> change, new features will be added, this is part of
> the maintenance programmers job. a good design makes
> this easy, a bad design does not. I would not
> consider any design good unless it had
> addressed the problem of extensibility. the
> relationship between a good design and maintenance is
> stronger than merely a consideration
Thanks for sharing your opinion. In the real world, maintenance programmers are unable to add any new features to complex information systems. They either don't have the experience, the software development process does not support this, or any number of other reasons.
If you are speaking about adding a new feature or extension to the Hello World application in the Java training book, then fine, yes maintenance might be handled by the same group as the designer's group.
# 13
When talking about "design and maintenance" it is about maintaining the application. Fixing bugs, as I think is what you assume (I never worked for a company employing "maintenance programmers"), is only a tiny part of software maintenance. Our real worlds seem to differ quite a lot.
# 14
> When talking about "design and maintenance" it is
> about maintaining the application. Fixing bugs, as I
> think is what you assume (I never worked for a
> company employing "maintenance programmers"), is only
> a tiny part of software maintenance. Our real worlds
> seem to differ quite a lot.
I highlight what some of the tasks of software maintenance are in my earlier post (see above). I specify "debugging client/user issues. For emphasis, "fixing bugs" and identifying bugs and putting them into a report are different tasks.
Maintenance programmers are those working on the operational level. They are assigned tasks such as mentioned earlier, and may be assigned some small design tasks as well to help them develop their skills. They are also assigned the manual (labor intensive) tasks and are not responsible for major design and/or product development .
Senior developers and software engineers work on the tactical level and are given more design responsibilites. They pass off the operational work to those below them to free up time to handle "bigger" things.
Master architects work on the strategic level of the enterprise. They are responsible for the overall direction of the software development process and typically design the software architectures of the products. Take note that software architecture and software design are related, but different concepts.
Software Architects and Senior Engineers rarely perform "maintenance tasks", i.e. those mentioned earlier.
# 15
I just think, this is a matter of terminology. I am talking about software maintenance as performing "post-delivery activities changing the software product", which includes enhancing and extending the software to new or changed requirements. This definition comes from a software engineering perspective and is well agreed upon.
A narrowed definition would be to restrict software maintenance to "the correction of errors in software systems and the remedying of inadequacies in running the software".
# 16
When a new building is going to be built, there is an architecture design process, and many subsequent engineering processes, e.g. electrical, mechanical, etc.
Once the building is designed and built, there are then many maintenance activities and processes for the life of the building.
The architects and engineers do not then also perform building maintenance duties.
If the building owner decides at some point to make additions to the structure, he/she then calls in the architect and/or engineers to execute an analysis and design phase and possibly built the addition. The astute owner certainly does not ask the maintenance men to make the addition.
For non-trivial systems, the above analogy describes the overall software engineering situtation. The software that controls the traffic control systems at the airport and the software of the Hello World website are different products.
The web master of the Hello World website may do design duties and do design and may also do administration and add new features. Context is key. Software maintenance and software design are different concepts when speaking of non-trivial software systems.
# 17
>
> Thanks for sharing your opinion. In the real world,
> maintenance programmers are unable to add any new
> features to complex information systems. They either
> don't have the experience, the software development
> process does not support this, or any number of other
> reasons.
>
oh?
Maintenance is almost always performed by the same people responsible for implementing new features, at the time new features are added.
In my experience most "bugs" aren't bugs but feature requests...
> If you are speaking about adding a new feature or
> extension to the Hello World application in the Java
> training book, then fine, yes maintenance might be
> handled by the same group as the designer's group.
And so it will be for multi million line applications as well.
# 18
> > I don't really think it's a matter of opinion.
> > maintenance is the ongoing process of keeping
> > software running. over time, the requirements will
> > change, new features will be added, this is part
> of
> > the maintenance programmers job. a good design
> makes
> > this easy, a bad design does not. I would not
> > consider any design good unless it had
> > addressed the problem of extensibility. the
> > relationship between a good design and maintenance
> is
> > stronger than merely a consideration
>
> Thanks for sharing your opinion. In the real world,
> maintenance programmers are unable to add any new
> features to complex information systems. They either
> don't have the experience, the software development
> process does not support this, or any number of other
> reasons.
>
> If you are speaking about adding a new feature or
> extension to the Hello World application in the Java
> training book, then fine, yes maintenance might be
> handled by the same group as the designer's group.
I do not believe, given the above, that you have ever been involved in an actual commercial software venture in your life. kindly stop trolling, daFei
# 19
Comparing software with a building is the most pointless allegory I've ever read. And, guess what, even in building architects and engineers do "maintenance", if the building or parts of it are too old to work properly, instead of tearing it down and build a new one. It is called
# 20
> When a new building is going to be built, there is an
> architecture design process, and many subsequent
> engineering processes, e.g. electrical, mechanical,
> etc.
and software isn't a building. there may be some parallels between the two, but only some
> Once the building is designed and built, there are
> then many maintenance activities and processes for
> the life of the building.
the word "maintenance" is overloaded. in a building, maintenance would not include "adding a new storey", and they wouldn't ask the janitor to do it. software maintenance does indeed cover adding new features
> The architects and engineers do not then also
> perform building maintenance duties.
quite. but as I said, not every activity in a building site has a direct counterpart in software design
> If the building owner decides at some point to make
> additions to the structure, he/she then calls in the
> architect and/or engineers to execute an analysis and
> design phase and possibly built the addition. The
> astute owner certainly does not ask the
> maintenance men to make the addition.
hung up on the term "maintenance", I see. this conversation is going nowhere. time and again you prove that you really don't know what you're talking about, and have merely extracted your "opinions" from old books
> For non-trivial systems, the above analogy describes
> the overall software engineering situtation. The
> software that controls the traffic control systems at
> the airport and the software of the Hello World
> website are different products.
the above analogy does nothing of the sort. it simply shows that you've read some comparisons between building buildings, and building software, but have not seen enough actual software design to know where those comparisons don't apply
> The web master of the Hello World website may do
> design duties and do design and may also do
> administration and add new features. Context is key.
> Software maintenance and software design are
> different concepts when speaking of non-trivial
> software systems.
context is indeed key. in the context of a tower block, the word "maintenance" has an entirely different meaning than in the context of a piece of software. software design and software maintenance may be different concepts, but they are very closely related. a design that does not facilitate maintenance is not a good design at all. I'd argue that ease of maintenance was one of the most important aspects of a good design
tell me, then, what the purpose of a good software design is. what would constitute a good design, in your view?
# 21
> When a new building is going to be built,
</snipped>
> For non-trivial systems, the above analogy describes the overall software
> engineering situtation.
... in the 1950's and 60's, yes. I believe it was 1969 or 1970 when people first began to realize that developing software is very different from building buildings, and that it had cost them enormous amounts of wasted time, effort and frustration trying to pretend that it was. In addition, the waste associated with a waterfall-based process and a strict people-hierarchy increases with the complexity and lifetime of a system (not the other way around, as you seem to suggest).
Lokoa at 2007-7-21 20:23:29 >
# 22
> context is indeed key. in the context of a tower
> block, the word "maintenance" has an entirely
> different meaning than in the context of a piece of
> software. software design and software maintenance
> may be different concepts, but they are very closely
> related. a design that does not facilitate
> maintenance is not a good design at all. I'd argue
> that ease of maintenance was one of the most
> important aspects of a good design
I highlighted a great point made (see above text in bold).
# 23
Developing large scale software is not very different than building buildings, in my opinion. I agree, there are differences.
A requirements-focused waterfall is still valuable. It just doesn't apply well with the actual development process. Moreso, due to the tighter timelines and deadlines dictated by the business world.
A requirements-focused waterfalll combined with the iterative-style Unified Process is a good fit, in my opinion.
# 24
> > context is indeed key. in the context of a tower
> > block, the word "maintenance" has an entirely
> > different meaning than in the context of a piece
> of
> > software. software design and software
> maintenance
> > may be different concepts, but they are very
> closely
> > related. a design that does not facilitate
> > maintenance is not a good design at all. I'd argue
> > that ease of maintenance was one of the most
> > important aspects of a good design
>
> I highlighted a great point made (see above text in
> bold).
pointless rhetoric
# 25
> Developing large scale software is not very different
> than building buildings, in my opinion. I agree,
> there are differences.
then why has virtually every attempt to treat a software project in this manner gone over-budget? the building industry doesn't suffer from anything like the failure rate of software, yet the process is similar. could it be, the paradigm simply doesn't fit the software world? and here we get to a reason that maintenance and extension should be a large component of a good software design, and disprove the notion that construction and software development are not so dissimilar:
suppose I build a house. over the years, it gives in to the elements, and one of the walls starts to crumble. so I have to perform maintenance, namely repair the wall. the maintenance exists to combat deterioration that occurs. now suppose I build a stock control system. that stock control system, once it's working perfeclty, will happily run forever without modification of any kind. of course, it won't ever get to that stage, because software is always released imperfect. so the maintenance on that software doesn't exist to combat deterioration, it's function is to complete work that wasn't finished before release, to correct mistakes that were made, and then of course to meet new, previously unknown requirements. maybe it needs to cope with more load, or maybe now they've got a new ERP system at head office, and they'd like the two to integrate. whatever it is, the well-designed piece of software allows this sort of extension easily, the poorly-designed one gets new functionality nailed to the side of it with all different sizes of nails, and eventually becomes a mess of structureless spaghetti. so the maintenance of a building and the maintenance of software aren't at all the same thing
how often does a skyscraper accidentally get built half a mile from where it was supposed to be? that sort of blunder happens in software projects all the time, and it just gets absorbed. if, halfway through a software project we re-think the architecture, we can refactor and bear the load in other ways, to make that change. a building would have to be completely demolished. it's tempting to draw an allegory there, and boldly claim that in effect you would have to completely demolish your codebase and start again, but there would be no cost or effort in doing so, you would simply cease work on the project and start anew. entirely different from a building site
> A requirements-focused waterfall is still valuable.
> It just doesn't apply well with the actual
> development process. Moreso, due to the tighter
> timelines and deadlines dictated by the business
> world.
>
> A requirements-focused waterfalll combined with the
> iterative-style Unified Process is a good fit, in my
> opinion.
is this how your current project is running?
# 26
> then why has virtually every attempt to treat a
> software project in this manner gone over-budget? the
> building industry doesn't suffer from anything like
> the failure rate of software, yet the process is
> similar. could it be, the paradigm simply doesn't fit
> the software world? and here we get to a reason that
> maintenance and extension should be a large component
> of a good software design, and disprove the notion
> that construction and software development are not so
> dissimilar:
>
> suppose I build a house. over the years, it gives in
> to the elements, and one of the walls starts to
> crumble. so I have to perform maintenance, namely
> repair the wall. the maintenance exists to combat
> deterioration that occurs. now suppose I build a
> stock control system. that stock control system, once
> it's working perfeclty, will happily run forever
> without modification of any kind. of course, it won't
> ever get to that stage, because software is always
> released imperfect. so the maintenance on that
> software doesn't exist to combat deterioration, it's
> function is to complete work that wasn't finished
> before release, to correct mistakes that were made,
> and then of course to meet new, previously unknown
> requirements. maybe it needs to cope with more load,
> or maybe now they've got a new ERP system at head
> office, and they'd like the two to integrate.
> whatever it is, the well-designed piece of software
> allows this sort of extension easily, the
> poorly-designed one gets new functionality nailed to
> the side of it with all different sizes of nails, and
> eventually becomes a mess of structureless spaghetti.
> so the maintenance of a building and the maintenance
> of software aren't at all the same thing
>
> how often does a skyscraper accidentally get built
> half a mile from where it was supposed to be? that
> sort of blunder happens in software projects all the
> time, and it just gets absorbed. if, halfway through
> a software project we re-think the architecture, we
> can refactor and bear the load in other ways, to make
> that change. a building would have to be completely
> demolished. it's tempting to draw an allegory there,
> and boldly claim that in effect you would have
> to completely demolish your codebase and start again,
> but there would be no cost or effort in doing so, you
> would simply cease work on the project and start
> anew. entirely different from a building site
Any special reason why you do not write with proper capitalization or sentence structure. Have you ever thought about improving your communication (writing) style? You seem to have some good points, but your writing style takes away from that very much. For me, after the third line I move on.
Using paragraphs, capitalization and good grammar will help readers understand your points. Stop writing like a little kid with a bad temper.
# 27
> > then why has virtually every attempt to treat a
> > software project in this manner gone over-budget?
> the
> > building industry doesn't suffer from anything
> like
> > the failure rate of software, yet the process is
> > similar. could it be, the paradigm simply doesn't
> fit
> > the software world? and here we get to a reason
> that
> > maintenance and extension should be a large
> component
> > of a good software design, and disprove the notion
> > that construction and software development are not
> so
> > dissimilar:
> >
> > suppose I build a house. over the years, it gives
> in
> > to the elements, and one of the walls starts to
> > crumble. so I have to perform maintenance, namely
> > repair the wall. the maintenance exists to combat
> > deterioration that occurs. now suppose I build a
> > stock control system. that stock control system,
> once
> > it's working perfeclty, will happily run forever
> > without modification of any kind. of course, it
> won't
> > ever get to that stage, because software is always
> > released imperfect. so the maintenance on that
> > software doesn't exist to combat deterioration,
> it's
> > function is to complete work that wasn't finished
> > before release, to correct mistakes that were
> made,
> > and then of course to meet new, previously unknown
> > requirements. maybe it needs to cope with more
> load,
> > or maybe now they've got a new ERP system at head
> > office, and they'd like the two to integrate.
> > whatever it is, the well-designed piece of
> software
> > allows this sort of extension easily, the
> > poorly-designed one gets new functionality nailed
> to
> > the side of it with all different sizes of nails,
> and
> > eventually becomes a mess of structureless
> spaghetti.
> > so the maintenance of a building and the
> maintenance
> > of software aren't at all the same thing
> >
> > how often does a skyscraper accidentally get built
> > half a mile from where it was supposed to be? that
> > sort of blunder happens in software projects all
> the
> > time, and it just gets absorbed. if, halfway
> through
> > a software project we re-think the architecture,
> we
> > can refactor and bear the load in other ways, to
> make
> > that change. a building would have to be
> completely
> > demolished. it's tempting to draw an allegory
> there,
> > and boldly claim that in effect you would
> have
> > to completely demolish your codebase and start
> again,
> > but there would be no cost or effort in doing so,
> you
> > would simply cease work on the project and start
> > anew. entirely different from a building site
>
> Any special reason why you do not write with proper
> capitalization or sentence structure. Have you ever
> thought about improving your communication (writing)
> style? You seem to have some good points, but your
> writing style takes away from that very much. For me,
> after the third line I move on.
Because to me, a forum is like a conversation, and I pretty much write what I would say with speech. My handwriting is atrocious for similar reasons, I saw psychologists about it at school. They said it's down to thoughts coming down faster than my hands can manage, basically. Not ideal, and I am conscious I've done it, afterwards. I'd rather own up to that rather than excuse it. My written style proper is far better, when I take the time
> Using paragraphs, capitalization and good grammar
> will help readers understand your points. Stop
> writing like a little kid with a bad temper.
Did you actually have any comments on what I wrote, or are you pulling another straw man?
# 28
> > Any special reason why you do not write with
> proper
> > capitalization or sentence structure. Have you
> ever
> > thought about improving your communication
> (writing)
> > style? You seem to have some good points, but your
> > writing style takes away from that very much. For
> me,
> > after the third line I move on.
>
> Because to me, a forum is like a conversation, and I
> pretty much write what I would say with speech. My
> handwriting is atrocious for similar reasons, I saw
> psychologists about it at school. They said it's down
> to thoughts coming down faster than my hands can
> manage, basically. Not ideal, and I am conscious I've
> done it, afterwards. I'd rather own up to that rather
> than excuse it. My written style proper is far
> better, when I take the time
>
Poor handwriting can be excused that way, especially hard to read letters, typing cannot.
If you don't bother to use proper capitalisation and punctuation when typing that's just laziness, shows a disdain for your reader, just as SMS shorthand does.
> > Using paragraphs, capitalization and good grammar
> > will help readers understand your points. Stop
> > writing like a little kid with a bad temper.
>
> Did you actually have any comments on what I wrote,
> or are you pulling another straw man?
If you were more inclined to write in a way that people can understand they might not consider you a little kid with a bad temper who can't be bothered to try and make others understand what it thinks.
# 29
> > > Any special reason why you do not write with
> > proper
> > > capitalization or sentence structure. Have you
> > ever
> > > thought about improving your communication
> > (writing)
> > > style? You seem to have some good points, but
> your
> > > writing style takes away from that very much.
> For
> > me,
> > > after the third line I move on.
> >
> > Because to me, a forum is like a conversation, and
> I
> > pretty much write what I would say with speech. My
> > handwriting is atrocious for similar reasons, I
> saw
> > psychologists about it at school. They said it's
> down
> > to thoughts coming down faster than my hands can
> > manage, basically. Not ideal, and I am conscious
> I've
> > done it, afterwards. I'd rather own up to that
> rather
> > than excuse it. My written style proper is far
> > better, when I take the time
> >
> Poor handwriting can be excused that way, especially
> hard to read letters, typing cannot.
> If you don't bother to use proper capitalisation and
> punctuation when typing that's just laziness, shows a
> disdain for your reader, just as SMS shorthand does.
Perhaps. I do try not to do it, but no disdain for the reader is intended
> > > Using paragraphs, capitalization and good
> grammar
> > > will help readers understand your points. Stop
> > > writing like a little kid with a bad temper.
> >
> > Did you actually have any comments on what I
> wrote,
> > or are you pulling another straw man?
>
> If you were more inclined to write in a way that
> people can understand they might not consider you a
> little kid with a bad temper who can't be bothered to
> try and make others understand what it thinks.
GhostRadioTwo - aka daFei - pulls this sort of straw man out every time he runs out of actual points
# 30
> GhostRadioTwo - aka daFei - pulls this sort of straw> man out every time he runs out of actual pointsIndeed, and in this case "getting away with it" on account of your spelling. If that's not a motivator for you... ;-p
Lokoa at 2007-7-21 20:23:34 >
# 31
> > GhostRadioTwo - aka daFei - pulls this sort of
> straw
> > man out every time he runs out of actual points
>
> Indeed, and in this case "getting away with it" on
> account of your spelling. If that's not a motivator
> for you... ;-p
I take umbrage with that! My typing may be lazy, and sentence structure may be somewhat lacking, but my spelling is, I believe, as good as anybody's! ;-)
But yes, it is something of a motivator
# 32
> I take umbrage with that!
Another expression learned from these forums. Cheers!
>My typing may be lazy, and
> sentence structure may be somewhat lacking, but my
> spelling is, I believe, as good as anybody's! ;-)
Sorry, I meant capitalization. Which still sort of falls under spelling, I suppose.
Lokoa at 2007-7-21 20:23:34 >
# 33
Ok, now that the book reports are out of the way, can we continue the discussion? I think there's potential for some interesting insights to come out of this
