• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
  • Paul Clapham
Sheriffs:
  • paul wheaton
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Piet Souris
Bartenders:
  • Mike London

hungarian notation violates OO: please expound.

 
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
in the style sheet you (frank? paul?) stated that "hungarian notation violates OO" or something to that effect. The place i work are talking about having standards (can you beleive they don't have them and they do alot of coding) and are leaning towards hungarian notation. I am against h.n. and need more ammo so please expound. thanks
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll have a go.
When Hungarian Notation (HN) was invented, the set of data types available in any given language was largely fixed. If a language provided (for example) short and long integers, character strings and single characters, pointera and arrays, then chosing and using HN prefixes was pretty straightforward. i for int, l for long, s for string and so on. Even adding modifiers like pl for a pointer to a long, as for an array of strings or sz for a zero-terminated string still remains understandable.
However, even relatively primitive languages, such as C, have ways to extend the type mechanism through the likes of typedef and structure definitions. Allowing user types into a system can bend or even completely break HN. Using the whole new type name as a prefix can lead to very cumbersome variable and function names, and trying to abstract an abbreviation defeats the point of being able to determine the type immediately - you still have to look up the abbreviation in some sort of index.
Imagine just adding a few typedefs, enums and structures to a HN program:

Try and work out what HN prefixes you would use for these types.
Now if I want to define some aggregate variables, like an array of islands for a chain or archipelago, I would have to declare something like:
struct island details aisland_detailsGalapagos[]; or struct island_details aidGalapagos. Neither of which seems a particularly good solution.
With a fully flexible OO language, such as Smalltalk, Java, or even C++, almost every type in the system is a class type rather than a primitive type. And typical OO systems have a lot of classes. In a HN approach to a system like this, the type information prepended to variable names very rapidly becomes both cumbersome and difficult to understand.
And that's even without the use of polymorphism. Polymorphism allows (typicaly through subclassing) containers, arrays and variables to hold contents of different types at different points in the program. The commonly used Java "Vector" for example can hold objects of any class. This is completely at odds with HN, which would require the type of the contents to be specified in the name of the vector variable.
This final point is the real killer for most technically oriented people. In order to use HN, you really have to either not use polymorhism, or allow the match between name and type to sometimees slip - which defeats the point of HN. Likewise, in order to make good use of the immense power and flexibility of polymorphism, you really have to dispense with HN.
Most serious OO naming styles emphasise naming of variable by meaning rather than by type. This allows classes to be changes, renamed, subclassed, split, joined etc. without having to rename variables and methods all over the system. This is an important form of encapsulation which allows effective maintenance of OO software without incurring great costs. Anyone involved in the deveopment of large systems knows that the smaller you can make the impact of a change, the smaller the chance of introducing bugs, so less of the system needs expensive regression testing before release.
This is the killer for business oriented people. Choosing a naming style in an OO system which emphasises meaning over type can reduce software development costs and lead to fewer bugs.
Does that help?
 
Paul Wetzel
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
that helps alot. thanks for the ammo!
 
Trailboss
Posts: 23614
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Have a look at these threads:
http://www.javaranch.com/ubb/Forum19/HTML/000026.html
http://www.javaranch.com/ubb/Forum19/HTML/000022.html
Basically, if you have two integers, x and y, in hungarian notation they would be iX and iY.
Strings might be sX and sY. Doubles: dX and dY .... I think you get the idea.
(Marilyn fixed links)
[ July 18, 2002: Message edited by: Marilyn de Queiroz ]
 
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"in the style sheet you (frank? paul?)
I thought that it is extracted from the Bible. I would like to know the absolute truth: who are the authors?
"hungarian notation violates OO"
May I ... ? Thanks anyway.
I have read, or I make up, as usual, that setters and getters violate OO
Reasoning:
1)"get"/"set" paradigm is MS's contribution to OOP.
It is considered rude to get/set something directly. If you need something to be done, then give that job to that object without any extortion for your own job.
2) Objects are to communicate only through publicly determined/exposed interfaces.
 
Sheriff
Posts: 9109
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Paul Wheaton is the author.
[ February 02, 2003: Message edited by: Marilyn de Queiroz ]
reply
    Bookmark Topic Watch Topic
  • New Topic