OOP: part of discipline, science or art?
-
I've been following the threads about OOP and feel that difference in opinions is caused by somewhat different view on programming as a whole. My opinion is that in environments where programming is first of all discipline, accessing member variables directly is crime and must be punished :) And very often there are good reasons to treat development as a discipline without any exceptions - for example, when maintaining a large project with multiple sites and 500 developers (ugh, do they exist, such projects? :) ). But if the team is small, or even consists of a single person, the team can reach much better performance if developers will follow their aesthetical preferences (providing, of course, that such preferences are consistent and people are not stupid ;P ). Look at hungarian notation, for example (I know it's old-fashioned, but there are millions of lines of code that use it and needs maintenance). Should we define prefix per each type? Should we use different prefixes for pointer variables, not just pSomething? Hungarian notation has nothing to do with OOP, but here there is a question about discipline. I've seen the code that used nearly hundreds prefixes for data types. It was very disciplined, but it was ugly and (strange enough!) hard to read. As we all know, COM is about love (c) Don Box. Why should be OOP about military training? Can't it be about love too? ;) Bottom line: listen to your heart! :rose: Win32/ATL/MFC Developer Oslo, Norway
-
I've been following the threads about OOP and feel that difference in opinions is caused by somewhat different view on programming as a whole. My opinion is that in environments where programming is first of all discipline, accessing member variables directly is crime and must be punished :) And very often there are good reasons to treat development as a discipline without any exceptions - for example, when maintaining a large project with multiple sites and 500 developers (ugh, do they exist, such projects? :) ). But if the team is small, or even consists of a single person, the team can reach much better performance if developers will follow their aesthetical preferences (providing, of course, that such preferences are consistent and people are not stupid ;P ). Look at hungarian notation, for example (I know it's old-fashioned, but there are millions of lines of code that use it and needs maintenance). Should we define prefix per each type? Should we use different prefixes for pointer variables, not just pSomething? Hungarian notation has nothing to do with OOP, but here there is a question about discipline. I've seen the code that used nearly hundreds prefixes for data types. It was very disciplined, but it was ugly and (strange enough!) hard to read. As we all know, COM is about love (c) Don Box. Why should be OOP about military training? Can't it be about love too? ;) Bottom line: listen to your heart! :rose: Win32/ATL/MFC Developer Oslo, Norway
Easy to come with all this ideas about love, when you live in the land of blonde and free minded women. I'd say that "discipline is nothing more then scientifically formalized philosophy and art." I guess the whole philosophy of OO is about SIMPLICITY. In Software Engineering we try to manage complexity by constantly raising levels of abstraction and by modelling difficult to comprehend machine concepts with everyday real world concepts. The latter is adressed by OO philosophy. The general rule would be: the closer object is to the real world, the more beautiful it is. From this in combination with raising the abstraction level one could conclude that: it does not matter if you write ppapdwSomething or pSomething, it matters what your object does, it matters if the general concept of it's usage is easy to comprehend, its interface is bulletproof, etc. OO is about objects and their cooperation, not about pesky drudgery in the background. Aesthetics means simplicity, and genuine simplicity can always be recognized as C.Alexander's "quality without a name" . You don't belive it? Do an experiment. Select 10 men. To exclude "ira et studio" factor, do not tell them that you are using them in an experiment. Then ask two of your girl friends to "accdentaly" meet them. One beautiful and simple and the other ugly and complex. Let them ask the guys for a date at the same time. See on which date they'll show up...I'm sure they'll recognize "quality without a name". p.s. Is this software engineering forum or f* Woodstock? And what kind of stuff are you on? Tomaz Software Engineer, Pfaeffikon, Switzerland
-
I've been following the threads about OOP and feel that difference in opinions is caused by somewhat different view on programming as a whole. My opinion is that in environments where programming is first of all discipline, accessing member variables directly is crime and must be punished :) And very often there are good reasons to treat development as a discipline without any exceptions - for example, when maintaining a large project with multiple sites and 500 developers (ugh, do they exist, such projects? :) ). But if the team is small, or even consists of a single person, the team can reach much better performance if developers will follow their aesthetical preferences (providing, of course, that such preferences are consistent and people are not stupid ;P ). Look at hungarian notation, for example (I know it's old-fashioned, but there are millions of lines of code that use it and needs maintenance). Should we define prefix per each type? Should we use different prefixes for pointer variables, not just pSomething? Hungarian notation has nothing to do with OOP, but here there is a question about discipline. I've seen the code that used nearly hundreds prefixes for data types. It was very disciplined, but it was ugly and (strange enough!) hard to read. As we all know, COM is about love (c) Don Box. Why should be OOP about military training? Can't it be about love too? ;) Bottom line: listen to your heart! :rose: Win32/ATL/MFC Developer Oslo, Norway
If you practice good programming technique when it doesn't matter, it will be a lot easier to do it when it does. Sure, you're writing the code in a small group of people, but in a year, will you remember what was going on or why you did things? Will you remember what type the variable MyVariable is without searching for it in the header file? I like "m_" prefix for member variables, and I use the following type identification (i don't go nuts like i've seen some folks do): CMyPointer* m_pMyPointer; int m_nMyInt; double m_dMyDouble; CString m_sMyString; CTypePtrArray <> m_tpaMyArray; COleDateTime m_odtMyDate; etc... For constants, I use all upper case prefixed by "cn", "cs", or something appropriate for the type. For function macros, it's all upper case, and for compiler definitions, they're prefixed with two underscores. I only wish I'd adopted these techniques long ago when I first started coding in C. Listen to your heart? I thnk not. It's more important to listen to your manager and follow published coporate coding guidelines. If you follow your heart, you may find that your last paycheck is following you out the door when they kick you out onto the street.
-
I've been following the threads about OOP and feel that difference in opinions is caused by somewhat different view on programming as a whole. My opinion is that in environments where programming is first of all discipline, accessing member variables directly is crime and must be punished :) And very often there are good reasons to treat development as a discipline without any exceptions - for example, when maintaining a large project with multiple sites and 500 developers (ugh, do they exist, such projects? :) ). But if the team is small, or even consists of a single person, the team can reach much better performance if developers will follow their aesthetical preferences (providing, of course, that such preferences are consistent and people are not stupid ;P ). Look at hungarian notation, for example (I know it's old-fashioned, but there are millions of lines of code that use it and needs maintenance). Should we define prefix per each type? Should we use different prefixes for pointer variables, not just pSomething? Hungarian notation has nothing to do with OOP, but here there is a question about discipline. I've seen the code that used nearly hundreds prefixes for data types. It was very disciplined, but it was ugly and (strange enough!) hard to read. As we all know, COM is about love (c) Don Box. Why should be OOP about military training? Can't it be about love too? ;) Bottom line: listen to your heart! :rose: Win32/ATL/MFC Developer Oslo, Norway
If you practice good programming technique when it doesn't matter, it will be a lot easier to do it when it does. Sure, you're writing the code in a small group of people, but in a year, will you remember what was going on or why you did things? Will you remember what type the variable MyVariable is without searching for it in the header file? I like "m_" prefix for member variables, and I use the following type identification (i don't go nuts like i've seen some folks do): CMyPointer* m_pMyPointer; int m_nMyInt; double m_dMyDouble; CString m_sMyString; CTypePtrArray <> m_tpaMyArray; COleDateTime m_odtMyDate; etc... For constants, I use all upper case prefixed by "cn", "cs", or something appropriate for the type. For function macros, it's all upper case, and for compiler definitions, they're prefixed with two underscores. I only wish I'd adopted these techniques long ago when I first started coding in C. Listen to your heart? I thnk not. It's more important to listen to your manager and follow published coporate coding guidelines. If you follow your heart, you may find that your last paycheck is following you out the door when they kick you out onto the street.
-
Easy to come with all this ideas about love, when you live in the land of blonde and free minded women. I'd say that "discipline is nothing more then scientifically formalized philosophy and art." I guess the whole philosophy of OO is about SIMPLICITY. In Software Engineering we try to manage complexity by constantly raising levels of abstraction and by modelling difficult to comprehend machine concepts with everyday real world concepts. The latter is adressed by OO philosophy. The general rule would be: the closer object is to the real world, the more beautiful it is. From this in combination with raising the abstraction level one could conclude that: it does not matter if you write ppapdwSomething or pSomething, it matters what your object does, it matters if the general concept of it's usage is easy to comprehend, its interface is bulletproof, etc. OO is about objects and their cooperation, not about pesky drudgery in the background. Aesthetics means simplicity, and genuine simplicity can always be recognized as C.Alexander's "quality without a name" . You don't belive it? Do an experiment. Select 10 men. To exclude "ira et studio" factor, do not tell them that you are using them in an experiment. Then ask two of your girl friends to "accdentaly" meet them. One beautiful and simple and the other ugly and complex. Let them ask the guys for a date at the same time. See on which date they'll show up...I'm sure they'll recognize "quality without a name". p.s. Is this software engineering forum or f* Woodstock? And what kind of stuff are you on? Tomaz Software Engineer, Pfaeffikon, Switzerland
Tomaz, I'm sorry for some misunderstanding. Perhaps the last sentence of my message ("listen to your heart") reminded about drugs:) Of course, I mean that first you have to acquire all necessary skills, really understand OOP (if you like objects), and be a part of several succesfull projects (ideally also maintain some). And then... listen yo your heart ;P Yes, then you will implicitly apply 99% of OOP methods strictly. But if in 1% you decide not to follow them (for example, for aesthetical reasons), you may do so. No rose symbol this time. It will be misinterpreted :rolleyes: Win32/ATL/MFC Developer Oslo, Norway
-
Easy to come with all this ideas about love, when you live in the land of blonde and free minded women. I'd say that "discipline is nothing more then scientifically formalized philosophy and art." I guess the whole philosophy of OO is about SIMPLICITY. In Software Engineering we try to manage complexity by constantly raising levels of abstraction and by modelling difficult to comprehend machine concepts with everyday real world concepts. The latter is adressed by OO philosophy. The general rule would be: the closer object is to the real world, the more beautiful it is. From this in combination with raising the abstraction level one could conclude that: it does not matter if you write ppapdwSomething or pSomething, it matters what your object does, it matters if the general concept of it's usage is easy to comprehend, its interface is bulletproof, etc. OO is about objects and their cooperation, not about pesky drudgery in the background. Aesthetics means simplicity, and genuine simplicity can always be recognized as C.Alexander's "quality without a name" . You don't belive it? Do an experiment. Select 10 men. To exclude "ira et studio" factor, do not tell them that you are using them in an experiment. Then ask two of your girl friends to "accdentaly" meet them. One beautiful and simple and the other ugly and complex. Let them ask the guys for a date at the same time. See on which date they'll show up...I'm sure they'll recognize "quality without a name". p.s. Is this software engineering forum or f* Woodstock? And what kind of stuff are you on? Tomaz Software Engineer, Pfaeffikon, Switzerland
"p.s. Is this software engineering forum or f* Woodstock? And what kind of stuff are you on?" rofl --- "every year we invent better idiot proof systems and every year they invent better idiots"
