• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Tim Cooke
  • Devaka Cooray
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
Bartenders:
  • Carey Brown
  • Roland Mueller

code vs. design

 
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But not in the way it is implemented. It's much more like a service, in that it's not the protocol handler which decides when it is appropriate to use it. Or so it seems to me. --Ilja Preuss
You are perfectly right and that's why I quoted the word "aspect". In the most general sense, an aspect is a unit of modularization for a crosscutting concern. This unit might as well be proactive or completely passive, it all depends on how it is implemented and which goals it pursues. Today, we suffer from AspectJ's definition of an aspect and we fail to recognize other kinds of aspects (and realizations thereof) when they come up.
Moreover, the way something is implemented does not drive the way the paradigm should be interpreted but the other way around. To follow up on the protocol handler example, in J2ME you use a Connection object and you don't really know what protocol underlies your connection, all you know (and what matters) is that you have a connection and that you can communicate with the rest of the world. The protocol handler in CLDC decides how to handle the bytes you send to it.
Finally, from thefreedictionary.com:


[...]
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.
[...]


In other words, the aspect-oriented paradigm tends to see communication (which are handled by protocol handlers) as a crosscutting concern of a system, and thus, an aspect of the system in the AOP sense.
[ May 11, 2004: Message edited by: Valentin Crettaz ]
 
Valentin Crettaz
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't know about you, but I really enjoy this discussion. --Valentin Crettaz
Ditto! --Ilja Preuss
Your sympathy for this debate seems to be fading way, or so it seems :roll:
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Valentin Crettaz:
I don't know about you, but I really enjoy this discussion. --Valentin Crettaz
Ditto! --Ilja Preuss
Your sympathy for this debate seems to be fading way, or so it seems :roll:


It's more a matter of time constraints - answering your earlier post is still on my todo list, but I want to give it the time it deserves...
 
Valentin Crettaz
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, I couldn't resist, I was just kidding of course
Take all the time you need, no rush
 
Valentin Crettaz
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've been doing some reorganizing in my bookmarks and I found this old thread.

Ilja, did you find time to read my post
 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Partly! The programming language is just one means we have invented to communicate our ideas to computers. I feel that the way we use programming languages these days is very limitative. Maybe I ask too much from them, but you have to agree that as soon as the system grows in size and becomes substantially big (50-100'000 LOC) you cannot have an overall view of the system, and thus, you cannot be sure that your code properly reflects what it has been written for. All I'm saying is that the code is good but we really lack *something* to assess it against. Nowadays we use test cases, this is good, but still not enough.

[ May 03, 2004: Message edited by: Valentin Crettaz ][/QB]



Big code is an issue related to brain power and code design. I can get my head around a million lines of well written code, but about what you specified of poorly written code.

Some very famous people from history have used the term "my brain is full". I have had that feeling before, but in reality you can learn more at the cost of old information access. The older memories don't go away they just usually get harder to recall once you get that full brain feeling. It hit me when I was around 30. Most famous people in history when they where 50 or older, but they did not have near the information we deal with. In a few more years you will have kids getting that full brain feeling.

This has been a huge limiting factor for foreign language people for a long time. Usually most people are limitied to seven human languages. Only a few make the ever increasing effort to learn beyond the full brain feeling.

Travis

http://www.allbinary.com
 
For my next feat, I will require a volunteer from the audience! Perhaps this tiny ad?
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic