OOP principle wrong?
-
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
-
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.
IMHO, a View should have knowledge of a Doc, and a Doc definately not of a View. The view needs to know about the doc, because it needs to draw the contents of the document. The document has nothing to do with the view, because it doesn't have to know what should be drawn, and on what device context. For that matter, the Doc should contain no functions related to displaying or printing a document. The doc only needs to known what it should do with members (objects) belonging to a document itself, and ofcourse related functions such as serializing etc. I'm certain you can't always have a perfect OOD or OO application, but you can at least try as hard as possible. Unfortunately, OO means in most cases loss of performance. Two things you have to think of.. speed and maintainability.. hard to choose. -- Alex Marbus www.marbus.net
-
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:
I think someone taught you the wrong definition of OOP. OOP says nothing about Getters or Setters, but rather interfaces. Treating instances (objects) of a type (class) as single entities with their own state. OOP is designed to model the way we work with things in real life. For instance, your Television set has many things which are getters/setters, such as the channel changer or volume control, however it also has "public data" in the form of the speaker and picture tube. We, the object client have direct access to this data without having to manipulate an interface to do so. Imagine if we had to flip a switch evertime we wanted to get a frame of image data or a cycle of sound. When it makes sense, public data is perfectly acceptable and doesn't violate encapsulation. Encapsulation only makes sense when dealing with object state, and seldom with object data. Does exposing m_pMainWnd in CWinApp violate encapsulation? Not really, since if you are accessing it from outside the CWinApp derived class, that means the MainWnd exists, and it's not going to change (if using the framework as designed). Further, changing the pointer doesn't effect CWinApp's internal state, so there is nothing to update. My point is really that encapsulation is something important, but it only really applies when you need to encapsulate something.
-
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 think you've missed a VERY big point of OOP....data hiding. I often tell OOP beginners that if I see more than a few Get/Set type methods for anything but a container class, I know that they didn't write it properly..... I prefer to "inject" data or other objects into your object and avoid trying to get data back out of the object. Why?? Well data is usually not worth much, but information is! The data placed into anything but a container object should typically be used to generate information rather than spitting it back out in its original form. Another benefit of avoiding public data: You can "force" the way that data is injected into your object. If, for example, the object has 5 members, it is possible (as has frequenctly been the case in my code) that in one case you set 3 of the values, but in another case, only 2 specific values should be set....buy using a method which takes 3 values in one case, and 2 values in the other, you can make sure that the user of your class (which may be you a year later) uses the class properly. Using these ideas, I reworked a co-workers code...he told me he used public data because he just wanted something that was easy to work with....as a result, he had functionality spread throughout 10 classes with a fair amount of similar code in multiple places. When I was done, not only was it much easier to use the class (by his admisssion, not my judgement), but it also meant that the code base was much smaller (about 2000 lines of code were removed from a section of code with 5000 lines to begin with).
-
I think you've missed a VERY big point of OOP....data hiding. I often tell OOP beginners that if I see more than a few Get/Set type methods for anything but a container class, I know that they didn't write it properly..... I prefer to "inject" data or other objects into your object and avoid trying to get data back out of the object. Why?? Well data is usually not worth much, but information is! The data placed into anything but a container object should typically be used to generate information rather than spitting it back out in its original form. Another benefit of avoiding public data: You can "force" the way that data is injected into your object. If, for example, the object has 5 members, it is possible (as has frequenctly been the case in my code) that in one case you set 3 of the values, but in another case, only 2 specific values should be set....buy using a method which takes 3 values in one case, and 2 values in the other, you can make sure that the user of your class (which may be you a year later) uses the class properly. Using these ideas, I reworked a co-workers code...he told me he used public data because he just wanted something that was easy to work with....as a result, he had functionality spread throughout 10 classes with a fair amount of similar code in multiple places. When I was done, not only was it much easier to use the class (by his admisssion, not my judgement), but it also meant that the code base was much smaller (about 2000 lines of code were removed from a section of code with 5000 lines to begin with).
I agree with you, for the most part. However, I think you're thinking too much about business logic and not so much about things like GUI framework classes and the like which don't provide "information" but rather provide structure to your application. Of course, most of the work I do is structural in nature. For instance, much of my work is front end development for laser machining systems. While there's a lot of backend work as well, the majority of our work is visual (but hooked into real-time data).