[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modelling in CS and Physics



   Anh AiViet,

--- Aiviet Nguyen <aiviet2@yahoo.com> wrote:
> Hi Ut Say,
> 
>   I know the book of the gang of four on Design Patterns.
>   Patterns are something like regularities and symmetries. But the
> patterns presented in the book of four are rather adhoc. They are not
> derived but just collected from experience. No principles and
> classification for them.

   IMHO, gang of four is the first group, who begins to see that there is
another abstraction layer above the implementation, and try to
"generalize" the structure programming. This basically give us a set of
tools to use in solving various type of problems.

   Once we have a set of common tools, which we can use to design/solve
any problems; the next phase is _if_ we can define a way to "describe" the
problem, then we can get to the phase of letting a machine (program) to
solve the problem by using that same common tool set.

>    As I said, the physicists have learned the art of modelling for
> generations so they are able to develope a technology out of it.
>    But such a young field like Sofware Engineering
> can learn a lot from the past's giants.
>    My practical question is: what is the additional input information
> we need to objectify a structural code?

   I am not quite understand your question. Any piece of code has an
effect on the system, on which it executes. If we take a snap shot of the
system before and after the code is ran, we can describe the code's
behavior/characteristic. Now, if we say that we need to "objectify" a
piece of code, then don't we have to describe/define the characteristic of
the code first? And if we can define its characteristic, I think
basically, we have a "pattern".

   I am not sure I grasp your question, thus my wandering thought might
not be anywhere close to the answer.

   Cheers,
   UtSay

---

>    Can we earn money with that objectification, if we can find it? Only
> in that case it would be worth pursuing further the issue.
> 
> Cheers
> Aiviet
> 
> --- U't Say <utsay@yahoo.com> wrote:
> >    Greetings,
> > 
> >    Compare to Physics and its thousand years of
> > maturity, software
> > engineering is still in the early infancy. But even
> > so, if we look back
> > when software is nothing but 2-bits values to
> > represent the simple
> > arithmetic operations up to now, it's undeniable
> > that software has a much
> > longer stride in its pace. I believe your answer is
> > awaiting just beyond
> > the next software evolution, after the so-called
> > "software design
> > patterns".
> > 
> >    If you have not already, I hope that you will
> > enjoy the "Design
> > Patterns, Elements of Reusable Object-Oriented
> > Software" from the "big
> > four" (Erich Gamma, Richard Helm, Ralph Johnson and
> > John Vlissides). The
> > book has a nice foreword by Grady Booch.
> > 
> >    Warmest regards,
> >    UtSay
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com