Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > design pattern for a file converter...

Reply
Thread Tools

design pattern for a file converter...

 
 
Tom Anderson
Guest
Posts: n/a
 
      12-12-2010
On Sat, 11 Dec 2010, Arne Vajh°j wrote:

> On 11-12-2010 08:57, Tom Anderson wrote:
>> On Fri, 10 Dec 2010, Stefan Ram wrote:
>>
>>> Tom Whittaker <(E-Mail Removed)> writes:
>>>> Does anyone have any insight into the best design pattern(s) to use
>>>> for this feature?
>>>
>>> I tend to write such code in a more procedural manner first.
>>>
>>> Then, I see the patterns in the code.
>>>
>>> Then, I refactor to make the patterns explicit if this seems
>>> to be of any use at all.

>>
>> This is what i do too. When i was younger, i used to start with a lovely
>> objecty design. I think what broke that habit was spending a few years
>> in Python instead of Java, mostly writing very simple, procedural
>> programs, because of the nature of the work i was doing. When i came
>> back to Java, i found myself in the same mindset as Stefan - start
>> simple, and refactor out the objects and patterns as they become obvious.

>
> I think it depends on the problem.
>
> I don't think starting a 500 KLOC project procedural and then
> refactoring to OO later will work.


Not after you've written the half million lines, no. But you can do it as
you go along - write something straightforward, then "refactor out the
objects and patterns as they become obvious".

tom

--
22% Essential Components, 22% Repetitive Patterns, 56% Pauses
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-12-2010
On 11-12-2010 21:31, Tom Anderson wrote:
> On Sat, 11 Dec 2010, Arne Vajh°j wrote:
>
>> On 11-12-2010 08:57, Tom Anderson wrote:
>>> On Fri, 10 Dec 2010, Stefan Ram wrote:
>>>
>>>> Tom Whittaker <(E-Mail Removed)> writes:
>>>>> Does anyone have any insight into the best design pattern(s) to use
>>>>> for this feature?
>>>>
>>>> I tend to write such code in a more procedural manner first.
>>>>
>>>> Then, I see the patterns in the code.
>>>>
>>>> Then, I refactor to make the patterns explicit if this seems
>>>> to be of any use at all.
>>>
>>> This is what i do too. When i was younger, i used to start with a lovely
>>> objecty design. I think what broke that habit was spending a few years
>>> in Python instead of Java, mostly writing very simple, procedural
>>> programs, because of the nature of the work i was doing. When i came
>>> back to Java, i found myself in the same mindset as Stefan - start
>>> simple, and refactor out the objects and patterns as they become
>>> obvious.

>>
>> I think it depends on the problem.
>>
>> I don't think starting a 500 KLOC project procedural and then
>> refactoring to OO later will work.

>
> Not after you've written the half million lines, no. But you can do it
> as you go along - write something straightforward, then "refactor out
> the objects and patterns as they become obvious".


As soon as the first part become OO'ish, then building
procedural on top of that can become tricky.

Arne

 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      12-12-2010
On 12/11/2010 09:53 PM, Arne Vajh├Şj wrote:
> On 11-12-2010 21:31, Tom Anderson wrote:
>> On Sat, 11 Dec 2010, Arne Vajh├Şj wrote:
>>
>>> On 11-12-2010 08:57, Tom Anderson wrote:
>>>> On Fri, 10 Dec 2010, Stefan Ram wrote:
>>>>
>>>>> Tom Whittaker <(E-Mail Removed)> writes:
>>>>>> Does anyone have any insight into the best design pattern(s) to use
>>>>>> for this feature?
>>>>>
>>>>> I tend to write such code in a more procedural manner first.
>>>>>
>>>>> Then, I see the patterns in the code.
>>>>>
>>>>> Then, I refactor to make the patterns explicit if this seems
>>>>> to be of any use at all.
>>>>
>>>> This is what i do too. When i was younger, i used to start with a
>>>> lovely
>>>> objecty design. I think what broke that habit was spending a few years
>>>> in Python instead of Java, mostly writing very simple, procedural
>>>> programs, because of the nature of the work i was doing. When i came
>>>> back to Java, i found myself in the same mindset as Stefan - start
>>>> simple, and refactor out the objects and patterns as they become
>>>> obvious.
>>>
>>> I think it depends on the problem.
>>>
>>> I don't think starting a 500 KLOC project procedural and then
>>> refactoring to OO later will work.

>>
>> Not after you've written the half million lines, no. But you can do it
>> as you go along - write something straightforward, then "refactor out
>> the objects and patterns as they become obvious".

>
> As soon as the first part become OO'ish, then building
> procedural on top of that can become tricky.


The "write first, refactor later" strategy is not incompatible with "get it
right first". If you are well-versed in object-oriented (or better,
type-based) programming, you will code that way from the get-go. You're not
going to write crappy spaghetti and then magically decide to apply good sense
to it. You're either going to apply good sense from the beginning or you are
never going to.

That said, initial knowledge is imperfect and refactoring will be needed.
Those that wrote their code intelligently up front will find this less of a
problem than those that didn't. So yes, you "refactor out the objects and
patterns as they become obvious", but a lot of them will be "obvious" at the
start.

If you aren't finding at least some patterns and programming for durability at
the start, good effing luck. You'll need it.

--
Lew
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      12-12-2010
On Sat, 11 Dec 2010, Arne Vajh?j wrote:

> On 11-12-2010 21:31, Tom Anderson wrote:
>> On Sat, 11 Dec 2010, Arne Vajh?j wrote:
>>
>>> On 11-12-2010 08:57, Tom Anderson wrote:
>>>> On Fri, 10 Dec 2010, Stefan Ram wrote:
>>>>
>>>>> Tom Whittaker <(E-Mail Removed)> writes:
>>>>>> Does anyone have any insight into the best design pattern(s) to use
>>>>>> for this feature?
>>>>>
>>>>> I tend to write such code in a more procedural manner first.
>>>>>
>>>>> Then, I see the patterns in the code.
>>>>>
>>>>> Then, I refactor to make the patterns explicit if this seems
>>>>> to be of any use at all.
>>>>
>>>> This is what i do too. When i was younger, i used to start with a lovely
>>>> objecty design. I think what broke that habit was spending a few years
>>>> in Python instead of Java, mostly writing very simple, procedural
>>>> programs, because of the nature of the work i was doing. When i came
>>>> back to Java, i found myself in the same mindset as Stefan - start
>>>> simple, and refactor out the objects and patterns as they become
>>>> obvious.
>>>
>>> I think it depends on the problem.
>>>
>>> I don't think starting a 500 KLOC project procedural and then
>>> refactoring to OO later will work.

>>
>> Not after you've written the half million lines, no. But you can do it
>> as you go along - write something straightforward, then "refactor out
>> the objects and patterns as they become obvious".

>
> As soon as the first part become OO'ish, then building
> procedural on top of that can become tricky.


Conceivably. One of the things i learned from my time in python is that it
isn't necessarily, or even frequently, the case: you can write procedural
code that picks up some objects, does stuff with them, and then puts them
down and carries on being procedural. It depends on your objects of
course: for example, you can happily write very procedural-ish code using
Java's collections classes - they're just another datatype the code can
work with. They don't force you to object-orient your own code. There are
classes which do force you to adopt object-orientation: SAX parsers and
Swing spring to mind, both because they need you to write event handlers.

tom

--
I might feel irresponsible if you couldn't go almost anywhere and see
naked, aggressive political maneuvers in iteration, marinating in your
ideology of choice. That's simply not the case. -- Tycho Brahae
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      12-12-2010
On Sat, 11 Dec 2010 20:29:23 -0500, Arne Vajh├Şj wrote:

> The phrasing of the question makes me assume that a give piece of code
> (strategy/plugin/whatever) is hardcoded for a given input format.
>

I wasn't certain either way but may have been influenced by a similar job
that required a data dictionary approach, i.e. the ability to define
matching fields in input and output and the type of conversion required.
An explicit requirement was that the format converter must be able to
deal with arbitrary changes to input formats without requiring any code
to be rewritten.

But, no matter which approach is taken to the format conversion,
designing and writing a set of hard-coded plugins for a common interface
is almost certainly harder than the OP thinks: ignoring that while asking
about patterns for the outer loop sounded like misdirected effort. Hence
what I wrote.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C++ and design Pattern (Composite design Pattern ) Pallav singh C++ 1 01-22-2012 10:48 PM
C++ and design Pattern (Composite design Pattern ) Pallav singh C++ 0 01-22-2012 10:26 PM
C++ and design Pattern (Composite design Pattern ) Pallav singh C++ 0 01-22-2012 10:25 PM
May I have a example of design pattern of "composite", I still feel fuzzy after reading book of Addison-Wesley's"design pattern " jones9413@yahoo.com C++ 1 08-31-2007 04:09 AM
documents related to factory design pattern and Abstract foctory pattern. sunny C++ 1 12-07-2006 04:26 AM



Advertisments