OOP principle wrong?
-
I remember reading in many books and being tought at uni that when programming in the OOP style we should use get and set methods to read and write properties. Supposedly this controls access to the variables. Now that I have left uni and dont have anyone marking my work anymore, I have left this principle where I think it belongs - not existing. I myself have never had any problems accessing a variable by accident (might be because my code has never exceded 3000 lines) Forgoing this principle has made my code much easier to read, and less to type. What do you think?
If you are not using Get/Set on the data in your classes than, simply put, you are not doing OOP. Which is fine, as long as you undertand that. OOP is NOT the best solution to all problems. But programmers who think they are doing OOP when in fact they are not ARE a BIG problem in the industry. I am currently responsible for a large legacy codeset left behind by someone with an attitude very similar to yours. Public data in every class, used globaly in a rather large application - an absolute disaster. A programmer's job is to manage data, OOP is simply a technique which sets a standard for how to do that (a standard which C++ unfortunantly makes very easy to break). If you do not understand that, become a network quy or a QA guy or something.:mad:
-
If you are not using Get/Set on the data in your classes than, simply put, you are not doing OOP. Which is fine, as long as you undertand that. OOP is NOT the best solution to all problems. But programmers who think they are doing OOP when in fact they are not ARE a BIG problem in the industry. I am currently responsible for a large legacy codeset left behind by someone with an attitude very similar to yours. Public data in every class, used globaly in a rather large application - an absolute disaster. A programmer's job is to manage data, OOP is simply a technique which sets a standard for how to do that (a standard which C++ unfortunantly makes very easy to break). If you do not understand that, become a network quy or a QA guy or something.:mad:
Easy Stan!, the guys was only asking a question whether not accessors and mutators (set/get methods) are a good or bad thing. Generally accessors/mutators are good for closed class style implementation, by that I mean classes such as a CPen class where the details of the classes are not relevent to the programmer. A good place where open classes are acceptable, or in data classes, classes that simple map straight onto a data base. In a large project where 10+ data classes are being used, its simplely a overhead to provide accessors/mutators for every data class. This are opinions of myself and nobody elses. Regards Norm Almond Chief Technical Architect FS Walker Hughes Limited
-
I remember reading in many books and being tought at uni that when programming in the OOP style we should use get and set methods to read and write properties. Supposedly this controls access to the variables. Now that I have left uni and dont have anyone marking my work anymore, I have left this principle where I think it belongs - not existing. I myself have never had any problems accessing a variable by accident (might be because my code has never exceded 3000 lines) Forgoing this principle has made my code much easier to read, and less to type. What do you think?
That's all I wanted to say. -- Alex Marbus www.marbus.net
-
I remember reading in many books and being tought at uni that when programming in the OOP style we should use get and set methods to read and write properties. Supposedly this controls access to the variables. Now that I have left uni and dont have anyone marking my work anymore, I have left this principle where I think it belongs - not existing. I myself have never had any problems accessing a variable by accident (might be because my code has never exceded 3000 lines) Forgoing this principle has made my code much easier to read, and less to type. What do you think?
Well, that statement implies that all of your member variables are public, and that also flies in the face of good OOP usage. I *always* uses Set/Get methods for member variables in a class. All of my member variables are protected or private, and my Get/Set methods are generally in the following format in the header file: private: CString m_sMyString; public: CString GetMyString() { return m_sMyString; }; As a manager, if I was looking at your code and asked you why all your data members were public, you better damn well have a better answer than "because I don't have a problem with accessing a variable by accident".
-
Well, that statement implies that all of your member variables are public, and that also flies in the face of good OOP usage. I *always* uses Set/Get methods for member variables in a class. All of my member variables are protected or private, and my Get/Set methods are generally in the following format in the header file: private: CString m_sMyString; public: CString GetMyString() { return m_sMyString; }; As a manager, if I was looking at your code and asked you why all your data members were public, you better damn well have a better answer than "because I don't have a problem with accessing a variable by accident".
-
I remember reading in many books and being tought at uni that when programming in the OOP style we should use get and set methods to read and write properties. Supposedly this controls access to the variables. Now that I have left uni and dont have anyone marking my work anymore, I have left this principle where I think it belongs - not existing. I myself have never had any problems accessing a variable by accident (might be because my code has never exceded 3000 lines) Forgoing this principle has made my code much easier to read, and less to type. What do you think?
Alright, I stand corrected get and set should be used. I was just trying to raise some interest by taking an unusual position :P I enjoy examining the base principles we program from to check if they are right or not. Following rules for the sake of it has never been me :) Well I learned a lot thankyou. The main reasons for keeping them as I see now is that because its industry standard, and we dont all follow the same practices, we make our own lives that little bit harder. Second point is that its easy to remember get and set when looking for the methods in the interfaces and "is" for that matter. Validation using get and set never occured to me, thanks :) I think a class can look after itself quite easily without the accessor methods. I think a method should do something a little more than return a datatype. Maybe manipulate data then return it. otherwise typing theclass.getX() or theclass.x is rather trivial. Although I do not mean to say we should not use get/set just that this arguement for get/set is poor. One of the pros for the unusual position is that it may be more efficent to access to variable directly rather than having a stack assignment of the method call. C++ developers seem to love the supreme efficiency c++ provides, but they also will be using the get/set methods to make there already hard code easier to read. In my opinion this same sacrificing of efficiency for ease of development will be why c++ will die out and languages like java and c# will take over. After all java and c# are much more easier to develop with and are able to produce very comparable products to c++ in a lot less time. C++ will probably become a language for hackers who enjoy the thrill of getting the most out of the computer. Neural Computation and real time apps will probably still enjoy it for there need to be efficient.:cool:
-
That's all I wanted to say. -- Alex Marbus www.marbus.net
Yes, and math is about way more than 1 + 1 = 2. OOP is about data encapsulation. If you have a single publicly defined data member in a single class than you have, in fact, introduced a non-OO element into your overall architecture. There may exist good, professionally valid, reasons for doing that, but saving keystrokes is not among them. You should at least be aware that your design cannot be trully described as OO. Your marketing guys might sale it as OO, but you as as the programmer, should not delude yourself. Again, OOP is not the answer to all problems, but if you need procedural code, don't dress it up as OO. After all, typing "class" is a waste of five keystrokes.
-
i know exactly what you mean ... went thru the same stuff in my masters and came to the same conclusion after i was taught it ... however ... if you work on your own projects and you're a disciplined coder it is cool but those principals are meant for very large systems with teams of people working on them over long periods of time ... a new member of a team won't read all the source code of all the modules ... if there is a simple get/set method for each variable all they have to do is call it and not worry about what the variable type is also the principle is meant to facilitate information hiding within a class such that if you wish to change the implementation of a class it wont affect the rest of the system as long as you leave the interfaces identical and handle the changes from within they are very important principles for production level code that has to have a long lifetime and you would do well to adhere to them :suss: --- "every year we invent better idiot proof systems and every year they invent better idiots"
-
Well, that statement implies that all of your member variables are public, and that also flies in the face of good OOP usage. I *always* uses Set/Get methods for member variables in a class. All of my member variables are protected or private, and my Get/Set methods are generally in the following format in the header file: private: CString m_sMyString; public: CString GetMyString() { return m_sMyString; }; As a manager, if I was looking at your code and asked you why all your data members were public, you better damn well have a better answer than "because I don't have a problem with accessing a variable by accident".
Small point, but it does not imply this in totality. The internal variables and variables that need validation so a set method is a necessity would be private. But this is a stupid point of mine, having them all as get and set and is for booleans makes life easier for developing as we dont have to worry about whether a variable is public or private since they are all accessed with get. I've noticed a lot of programmers would program a Point class like this though: public class point{ public int x,y; public point(int x, int y){ this.x = x; this.y = y; } } so maybe simple endpoints in code its allowed????
-
Alright, I stand corrected get and set should be used. I was just trying to raise some interest by taking an unusual position :P I enjoy examining the base principles we program from to check if they are right or not. Following rules for the sake of it has never been me :) Well I learned a lot thankyou. The main reasons for keeping them as I see now is that because its industry standard, and we dont all follow the same practices, we make our own lives that little bit harder. Second point is that its easy to remember get and set when looking for the methods in the interfaces and "is" for that matter. Validation using get and set never occured to me, thanks :) I think a class can look after itself quite easily without the accessor methods. I think a method should do something a little more than return a datatype. Maybe manipulate data then return it. otherwise typing theclass.getX() or theclass.x is rather trivial. Although I do not mean to say we should not use get/set just that this arguement for get/set is poor. One of the pros for the unusual position is that it may be more efficent to access to variable directly rather than having a stack assignment of the method call. C++ developers seem to love the supreme efficiency c++ provides, but they also will be using the get/set methods to make there already hard code easier to read. In my opinion this same sacrificing of efficiency for ease of development will be why c++ will die out and languages like java and c# will take over. After all java and c# are much more easier to develop with and are able to produce very comparable products to c++ in a lot less time. C++ will probably become a language for hackers who enjoy the thrill of getting the most out of the computer. Neural Computation and real time apps will probably still enjoy it for there need to be efficient.:cool:
Using Get/Set is a good idea if a) you think your public variable names are in danger of changing (admittedly how would one know this? Better safe than sorry) b) you need to check valid bounds when setting a variable (good idea, design by contract) c) you expect your class to be accessed from multiple threads. In this case, the Get/Set methods need to have additional mechanisms to synchronize access. You've noted some of the efficiency problems with using function calls, but for most real applications where most work is spent elsewhere, the cost of a function call is effectively zero. All this being said, you can "get away" without Get/Set for small apps like you're talking about, but for any large projects, it's a standard with some excellent reasons behind it.
-
Alright, I stand corrected get and set should be used. I was just trying to raise some interest by taking an unusual position :P I enjoy examining the base principles we program from to check if they are right or not. Following rules for the sake of it has never been me :) Well I learned a lot thankyou. The main reasons for keeping them as I see now is that because its industry standard, and we dont all follow the same practices, we make our own lives that little bit harder. Second point is that its easy to remember get and set when looking for the methods in the interfaces and "is" for that matter. Validation using get and set never occured to me, thanks :) I think a class can look after itself quite easily without the accessor methods. I think a method should do something a little more than return a datatype. Maybe manipulate data then return it. otherwise typing theclass.getX() or theclass.x is rather trivial. Although I do not mean to say we should not use get/set just that this arguement for get/set is poor. One of the pros for the unusual position is that it may be more efficent to access to variable directly rather than having a stack assignment of the method call. C++ developers seem to love the supreme efficiency c++ provides, but they also will be using the get/set methods to make there already hard code easier to read. In my opinion this same sacrificing of efficiency for ease of development will be why c++ will die out and languages like java and c# will take over. After all java and c# are much more easier to develop with and are able to produce very comparable products to c++ in a lot less time. C++ will probably become a language for hackers who enjoy the thrill of getting the most out of the computer. Neural Computation and real time apps will probably still enjoy it for there need to be efficient.:cool:
>Maybe manipulate data then return it. otherwise typing theclass.getX() or >theclass.x is rather trivial. Although I do not mean to say we should not >use get/set just that this arguement for get/set is poor. I don't know what sort of code you write, but the world I code in is continuously changing. I personally am in a position where I need to anticipate that the code for theclass.getX() is going to need to be changed for different customers, as well as simply changing over time ( ie validation rules will change over time ). I also need to write feature-reduced versions of products, and I can assure you that calls to theclass.getX() are a lot easier to alter than theclass.X. >One of the pros for the unusual position is that it may be more efficent to >access to variable directly rather than having a stack assignment of the >method call. That's why we have the inline keyword in C++.;)
-
Using Get/Set is a good idea if a) you think your public variable names are in danger of changing (admittedly how would one know this? Better safe than sorry) b) you need to check valid bounds when setting a variable (good idea, design by contract) c) you expect your class to be accessed from multiple threads. In this case, the Get/Set methods need to have additional mechanisms to synchronize access. You've noted some of the efficiency problems with using function calls, but for most real applications where most work is spent elsewhere, the cost of a function call is effectively zero. All this being said, you can "get away" without Get/Set for small apps like you're talking about, but for any large projects, it's a standard with some excellent reasons behind it.
Fundamentally we agree, but I think the language you use in making your points draws attention away from the best reason to use Get/Set. You said (slightly edited for brevity): "Using Get/Set is a good idea if a) you think your public variable names are in danger of changing b) you need to check valid bounds when setting a variable c) you expect your class to be accessed from multiple threads." The best reason of all for using Get/Set is that in most development environments you don't know how your code is going to be used in the longer term. So the things you mentioned (and countless other eventualities) could happen even if you don't think your variable names are in danger of changing, you don't need to check valid bounds (at the moment), and you don't expect your class to be accessed from multiple threads. Cheers, Gavin.
-
Yes, and math is about way more than 1 + 1 = 2. OOP is about data encapsulation. If you have a single publicly defined data member in a single class than you have, in fact, introduced a non-OO element into your overall architecture. There may exist good, professionally valid, reasons for doing that, but saving keystrokes is not among them. You should at least be aware that your design cannot be trully described as OO. Your marketing guys might sale it as OO, but you as as the programmer, should not delude yourself. Again, OOP is not the answer to all problems, but if you need procedural code, don't dress it up as OO. After all, typing "class" is a waste of five keystrokes.
OOP is about data encapsulation And beyond. OOP is, as the name mentions, all about objects. A class itself is an object, but the members of a class are objects on their own. It's not a big deal or a problem to give the knowledge of such an object to another class? I even understand that you create a Get and a Set function for such a member, suppose you wish to give another object the ability to change the member, and do some extra stuff for yourself in the Set-function? I can understand that a private member has protected get- and setfunctions, so the derived classes can retrieve and set the value of the member, but don't have direct access to the member itself. Think of an object as a black box filled with information. You don't have to know how it works, you just need to know that is works. If you send a request to such an object, you can be certain that the result you receive from the object after processing is a valid result. And nobody cares if one or more of the members of that object are private, public or virtual, as long as they don't change the state of the object itself. At least, that's my thought. I might be wrong, ofcourse -- Alex Marbus www.marbus.net
-
I remember reading in many books and being tought at uni that when programming in the OOP style we should use get and set methods to read and write properties. Supposedly this controls access to the variables. Now that I have left uni and dont have anyone marking my work anymore, I have left this principle where I think it belongs - not existing. I myself have never had any problems accessing a variable by accident (might be because my code has never exceded 3000 lines) Forgoing this principle has made my code much easier to read, and less to type. What do you think?
While you might be a great programmer and be able to keep track of how to validate each member outside of the class, the next guy who has to maintain your code might no be... write you code like you would you UI, idiot proof :) Have a good one, -Ben "Its funny when you stop doing things because they’re wrong, but because you might get caught." - Unknown
-
I remember reading in many books and being tought at uni that when programming in the OOP style we should use get and set methods to read and write properties. Supposedly this controls access to the variables. Now that I have left uni and dont have anyone marking my work anymore, I have left this principle where I think it belongs - not existing. I myself have never had any problems accessing a variable by accident (might be because my code has never exceded 3000 lines) Forgoing this principle has made my code much easier to read, and less to type. What do you think?
I recently read an article that stated using get/set methods is not OO. If you need to get() a variable to perform a given task you should give the object the data necessary to do it for you. This makes perfect sense, only the object should know about its state (variables) and only it should know how to perform tasks related to its state. However, I am torn between what should be done in a doc/view pattern. Should the view give the doc a canvas to render onto or should the view know the state of the doc and render it. E.g. // bare in mind this is a oversimplification class Doc { public: void Draw(CDC *pDC); private: CString m_text; }; void View::OnDraw(CDC *pDC) { pDoc = GetDocument(); pDoc->Draw(pDC); } // or ////////////////////////////// class Doc { public: CString * GetText(); private: CString m_text; }; void View::OnDraw(CDC *pDC) { pDoc = GetDocument(); pDC->TextOut(0, 0, pDoc->GetText); } The first version allows the doc to change without requiring the view to change also. However, it would require a separate method for each rendered style (DrawBarGraph, DrawPieChart, etc.). The second version is closer to the MVC pattern (except that the controller and the view are integrated, which has always bothered me). It permits the view to render the doc whatever way the view should (CBarGraphView, CPieChartView, etc.). What to do! P.S. Sorry for the long post.
-
OOP is about data encapsulation And beyond. OOP is, as the name mentions, all about objects. A class itself is an object, but the members of a class are objects on their own. It's not a big deal or a problem to give the knowledge of such an object to another class? I even understand that you create a Get and a Set function for such a member, suppose you wish to give another object the ability to change the member, and do some extra stuff for yourself in the Set-function? I can understand that a private member has protected get- and setfunctions, so the derived classes can retrieve and set the value of the member, but don't have direct access to the member itself. Think of an object as a black box filled with information. You don't have to know how it works, you just need to know that is works. If you send a request to such an object, you can be certain that the result you receive from the object after processing is a valid result. And nobody cares if one or more of the members of that object are private, public or virtual, as long as they don't change the state of the object itself. At least, that's my thought. I might be wrong, ofcourse -- Alex Marbus www.marbus.net
Let me add a little more to the above.... OOP is about visibility and responsibility. What happens when change occurs? You will basically have to trace back through everything and make changes however, if you have properly defined visibility and responsibilities your changes should be isolated. The Law of Demeter becomes very important in this respect!
-
If you are not using Get/Set on the data in your classes than, simply put, you are not doing OOP. Which is fine, as long as you undertand that. OOP is NOT the best solution to all problems. But programmers who think they are doing OOP when in fact they are not ARE a BIG problem in the industry. I am currently responsible for a large legacy codeset left behind by someone with an attitude very similar to yours. Public data in every class, used globaly in a rather large application - an absolute disaster. A programmer's job is to manage data, OOP is simply a technique which sets a standard for how to do that (a standard which C++ unfortunantly makes very easy to break). If you do not understand that, become a network quy or a QA guy or something.:mad:
And then of course, MFC is not object-oriented, and ATL is not, and all functions must be virtual etc... We heard it many times. If I may throw my vote - when a new programmer is learning OOP, he should definitely use Get/Set technique. Once he has learned it, he can be use getters and setters much more selective - without breaking OOP. If OOP did not have practical exceptions, there would be no "const_cast" operator. Win32/ATL/MFC Developer Oslo, Norway
-
I remember reading in many books and being tought at uni that when programming in the OOP style we should use get and set methods to read and write properties. Supposedly this controls access to the variables. Now that I have left uni and dont have anyone marking my work anymore, I have left this principle where I think it belongs - not existing. I myself have never had any problems accessing a variable by accident (might be because my code has never exceded 3000 lines) Forgoing this principle has made my code much easier to read, and less to type. What do you think?
Hi, I think the idea of get/set helps in several ways: 1) you can use it to help debugging (ie. easy trace statements on cariable access) 2) you can use it to hide the underlying implementation for instance using GetColour(int nIndex) rather that MyPicture.Colours.GetAt(myPos) means that if you decide to change over from MFC collections to STL for instance, you only have to change the GetColour() function rather than the entire code base. Hope that helps, Andrew.
-
Small point, but it does not imply this in totality. The internal variables and variables that need validation so a set method is a necessity would be private. But this is a stupid point of mine, having them all as get and set and is for booleans makes life easier for developing as we dont have to worry about whether a variable is public or private since they are all accessed with get. I've noticed a lot of programmers would program a Point class like this though: public class point{ public int x,y; public point(int x, int y){ this.x = x; this.y = y; } } so maybe simple endpoints in code its allowed????
It's called "discipline". I know this might be a rather extreme example, but... If you're willing to let something like this by, where do you draw the line at proper coding technique? At what point do you come to the decision that Get/Set methods would be a better idea?
-
Let me add a little more to the above.... OOP is about visibility and responsibility. What happens when change occurs? You will basically have to trace back through everything and make changes however, if you have properly defined visibility and responsibilities your changes should be isolated. The Law of Demeter becomes very important in this respect!
How could I forget that :) Thanks Ed :rose: -- Alex Marbus www.marbus.net