3 ms·

I can see what the author is trying to get at. If you are talking about building a library with an API, or maybe even a command line tool, then what he says ha

I can see what the author is trying to get at. If you are talking about building a library with an API, or maybe even a command line tool, then what he says has quite a bit of wisdom to it. Unfortunately for the author, industry's long experience with GUI apps indicates that MVC is the way to go - when I consider the frameworks that I use for writing UIs, the two that most clearly give me an MVC architecture (Cocoa and Rails), are easily the most productive frameworks that I use. This comes into conflict with the original article when you consider the M of MVC. A Model makes no sense at all without getters and setters. It's job is mostly to handle serialisation of data - either to a database using ORM (ActiveRecord), or to a file using something like Cocoa's NSCoding protocol. It may even be used for serialising data to be sent over the network. Regardless, if the UI can't get it's hands on the data, the data is useless. So how can we get the data to the UI. If you look in the comments section of the article, the autor suggests (in responding to a question for how to populate a pull-down menu list) that you create a method in the model class that takes a pull-down menu as a parameter, and then populates the menu. No! Models should never even know what a pull-down menu is! How can I re-use my model code elsewhere if it is tied to a GUI. Again, going back to ActiveRecord. I can create a model class inheriting from ActiveRecord, and re-use exactly the same class in a RubyCocoa app, or a Rails app. How am I supposed to do that if my model class starts spitting out html, or starts calling NSArrayControllers? No. If the author is right, then MVC must be wrong, and quite frankly I don't think that he has presented a strong enough case to justify one of the more successful architectural choices that we as an industry have found over the last 50 odd years.

andrewf 18y ago
I'm not sure this excludes the use of getters and setters under any and all circumstances. A purist argument is that objects are supposed to do stuff, and that methods should be big, chunky verbs that don't expose unnecessary implementation details - including dozens of properties and twiddly knobs that "could be useful some day". But if you're building container classes for a model, then your value of "do stuff" is "store data and make it available to others", so the use of getters and setters seems entirely reasonable.
- ajross 18y ago
  Agreed. This article seems like a good idea (essentially: "don't write needless code", and "don't expose fine-grained stuff you don't have to") extended to the point of pedantry. Certainly accessor methods can be clean and useful, especially for things like computed or read-only values. They certainly aren't a red flag for maintainability by themselves.
babul 18y ago
I agree. In my past experience I have found it actually better to build all the domain elements (model) first based on command line usage, as it more clearly and accurately defines the problem (focus is not lost on GUI issues), and then work on GUI development. This allows very loosely coupled yet highly cohesive systems to be easily built. The main problem I face with others who adopt a GUI-driven development method (which has many merits of course) is they start to confuse elements/logic/tiers and tie things together too much at too early a stage and hence is is no separation of concerns and elements making systems harder to change/scale/iterate-upon etc.
jimbokun 18y ago
I'm not sure that the examples you cite make the point you want to make. Objective C 2.0 just introduced properties. One of the main reasons for this is to avoid manually writing accessors. I'm pretty sure that in Rails, you just give an annotation (I probably got the terminology wrong here) indicating what attributes you want to make accessible. Again, no manually written accessors. I suppose this is different from the argument made by the article, but it is still an argument against WRITING accessor methods. Whatever benefits there are for having some kind of accessors mechanism, certainly there is no good reason for having to explicitly write methods to implement them. I never saw the point in writing "private int theNumber" immediately followed by "public int getTheNumber() { return theNumber; } public void setTheNumber(int n) { theNumber = n; }"
- allertonm 18y ago
  While the original article talked about accessors, the argument was really against publicly accessible properties on objects - even readonly properties. As demallien correctly argues, this approach breaks MVC. It's not stated outright, but the original author obviously has a Java or C++ background. The Java & C++ syntaxes for accessing a getter are different from those for accessing a public member, and as a result Java/C++ programmers almost always write accessors for all properties because it will be hard to change later.

andrewf 18y ago

I'm not sure this excludes the use of getters and setters under any and all circumstances. A purist argument is that objects are supposed to do stuff, and that methods should be big, chunky verbs that don't expose unnecessary implementation details - including dozens of properties and twiddly knobs that "could be useful some day". But if you're building container classes for a model, then your value of "do stuff" is "store data and make it available to others", so the use of getters and setters seems entirely reasonable.

ajross 18y ago
Agreed. This article seems like a good idea (essentially: "don't write needless code", and "don't expose fine-grained stuff you don't have to") extended to the point of pedantry. Certainly accessor methods can be clean and useful, especially for things like computed or read-only values. They certainly aren't a red flag for maintainability by themselves.

babul 18y ago

I agree. In my past experience I have found it actually better to build all the domain elements (model) first based on command line usage, as it more clearly and accurately defines the problem (focus is not lost on GUI issues), and then work on GUI development. This allows very loosely coupled yet highly cohesive systems to be easily built. The main problem I face with others who adopt a GUI-driven development method (which has many merits of course) is they start to confuse elements/logic/tiers and tie things together too much at too early a stage and hence is is no separation of concerns and elements making systems harder to change/scale/iterate-upon etc.

jimbokun 18y ago

I'm not sure that the examples you cite make the point you want to make. Objective C 2.0 just introduced properties. One of the main reasons for this is to avoid manually writing accessors. I'm pretty sure that in Rails, you just give an annotation (I probably got the terminology wrong here) indicating what attributes you want to make accessible. Again, no manually written accessors. I suppose this is different from the argument made by the article, but it is still an argument against WRITING accessor methods. Whatever benefits there are for having some kind of accessors mechanism, certainly there is no good reason for having to explicitly write methods to implement them. I never saw the point in writing "private int theNumber" immediately followed by "public int getTheNumber() { return theNumber; } public void setTheNumber(int n) { theNumber = n; }"

allertonm 18y ago
While the original article talked about accessors, the argument was really against publicly accessible properties on objects - even readonly properties. As demallien correctly argues, this approach breaks MVC. It's not stated outright, but the original author obviously has a Java or C++ background. The Java & C++ syntaxes for accessing a getter are different from those for accessing a public member, and as a result Java/C++ programmers almost always write accessors for all properties because it will be hard to change later.