Anonymous
Unregistered
|
|
I took a design class where the principle was that an object held state, therefore getters/setters were central to the design. Take the drawing example that the author gives. If you have a class that supports drawYourself(), then for each class you must have code that supports drawing in Swing, AWT, HTML, etc. In the design where objects simply hold state, you would have drawing managers for each type of drawing environment you want to support. These managers hold all the code for drawing in that environment and simply interogate the objects they are supposed to draw via their getters. I always liked the simplicity of this paradigm.
|
Chris Lane
Unregistered
|
|
The problem is that if you write a large application you will have a huge number of get/set methods and the coupling will be heavy ... read "expensive". Change the name of a variable or its type and start testing ... lots of client code will point to it. I have seen the cost of simple changes cost 10's of thousand of dollars ...
Actually make that billions of $s ... y2k! Let's see, encapsulate a date along with its math, formatting and you are done. We used to have custom formats for dates all the time - big mistake. Another example is Swing. It runs on Windows, X, Mac etc. Would rather have your app do that? The real question is this: What is likely vary? If your GUI will run on these platforms than use AWT/Swing. If you want to include a Web interface then you could write different front-end classes for AWT and Swing - with all the business logic repeated ... yuk! Same thing is true for a persistence mechanism: if you need a database to do your work (transactions) and all that, don't bother writing a flat file system to emulate it. In the real world, we add attributes and their types: if you want to change the GUI, "business layer" and database layer then you must do a lot of work.
It requires more attention on architecture but the payoff can be amazing ... one change in one place and it cascades through-out the app - it is great.
The approach of separating data and logic/presentation is called procedural programming.
|
Anonymous
Unregistered
|
|
You don't actually have to add GUI code to a class X to allow it to implement drawYourself()...
For example, if Class X represented a Person, with FirstName, LastName, Sex and Age attributes, moving away from exposing these attributes through get/setters, you might want to do something like this:
public interface Form
{
public void addStringField( ... );
public void addIntField( ... );
public void addBooleanField( ... );
public void addEnumField( ... );
}
public interface CanBePutOnAForm
// for want of a better name!
{
public void putOnForm( Form form );
};
now, you can do something like:
public class Person
{
private String first_name;
private String first_name;
private int age;
private SexEnum sex;
..
public void putOnForm( Form form )
{
form.addStringField( "First Name", this.first_name );
form.addStringField( "Last Name", this.last_name );
form.addIntField( "Age", this.age );
form.addEnumField( "Sex", this.sex );
}
}
See ... no Swing code, no AWT code, no GUI-Architecture specific bindings in person. So where does it go???
public class SwingForm
implements Form
{
...
}
public class SWTForm
implements Form
{
...
}
|
Anonymous
Unregistered
|
|
You've basically just moved the accessors to an interface called form and called them add* instead of get*. Advantage?
|
Anonymous
Unregistered
|
|
"Change the name of a variable or its type and start testing..." What are you talking about, nobody here is exposing variables and types can be abstract data types.
If you think of your objects as data, then you may want to expose that data in many different forms, XML, HTML, Swing, SQL. If you create a render interface that accepts data objects, the render simply asks the data object about itself and it displays the object as it wants to.
"The approach of separating data and logic/presentation is called procedural programming." Where did you learn this?
|
Anonymous
Unregistered
|
|
In the real world, you don't ask people or objects to draw themselves. They just are there. You use your renderer, your eyes, to "get" information about the person or object and you "render" it in your mind. Other people can request the same information from the object and "render" the object for themselves. If the person/object had to "render" themselves, their "cpus" would be pinned.
|
Anonymous
Unregistered
|
|
Quote:
If you think of your objects as data...
That's the problem. Objects aren not data. (Yes, fine, there are exceptions. Value objects or whatever are data. But that is a small percentage of the total objects in a system.)
|
Ash
Unregistered
|
|
Advantage:
* Changes to Person's structure (ie remove LastName, change type for Age, add new fields) ONLY EFFECTS Person's code. Modify putOnForm() in Person.java, instead of a huge search for GUI code that calls Person.getXXX()
It's all about maintainability.
|
Anonymous
Unregistered
|
|
A huge search, eh? Have you ever used an IDE? Have you ever designed a real-world system, for that matter?
|
Anonymous
Unregistered
|
|
Oh very mature. Nice to see we have such intelligent coders in this forum. I see, so you are one of these "real-world system coders" that make code bases complete [censored] for the rest of us to maintain....
|
Anonymous
Unregistered
|
|
Let me put it this way, retardo. Holub's ass-backwards way of doing things goes directly against the intent of having interfaces in the language in the first place. He packs everything into one place instead of having interfaces to describe well-organized areas of responsibility.
So if you have a Person data object, you will follow Holub's advice (I'm sure) and put logic into it that draws it to the screen and sends it via email and whatnot, even though all those things have nothing to do with each other. The Gang of Four did NOT mean that an object's data should never be exposed, but that implementations of specific ways of using the data shouldn't be exposed more than necessary. That's what every non-Holub response on this board has been saying.
Specific facts like "the name of Person occurs as a String value" aren't the oh-so-bad pieces of "implementation" that Holub claims. Only a dummy who never coded anything of even appreciable complexity would agree with him on this. His argument can basically be reduced to one statement:
- You should never have a data model exposed in your code.
This is absolutely ridiculous. Many posts have been entered on this board asking him to show evidence of even one medium-to-large-sized project that benefited from his approach, but he hasn't volunteered jack [censored]. That's because he can't; his approach works very, very badly in real life. I know, because I've seen beginners write code like his before, causing problems right and left.
Take a trip through the Java API sometime. Then go take a look at .NET (if you have the courage/stomach). Both of them were designed from the ground up to be exactly against what Holub proposes. The funny thing is, his approach is most often taken (in my experience) by old systems coders, which he is, that don't know much about object-oriented design, but have read a few magazine articles.
I suspect that your post was just one more lameass anonymous posting by the man o' the hour himself, Allen "Goofball" Holub. Have fun selling your crappy book-- by the looks of the response on this forum, you may sell a dozen or so.
|
Allen Holub
Unregistered
|
|
Trying to move this diccussion out of the gutter:
You have taken a simple, and key, OO concept---implementation hiding---and distorted in a way I find truly remarkable. Many of the words that you put into my mouth are nonsensical. The key concept, here, is that maintainablity is improved if the messaging system doesn't give away any knowledge of how an object is implemented. That way you can modify the definition of the object without impacting the users of the object. That's it. All the other junk you've added is junk that you've added.
The article also disccuses the fact that full implementation hiding is not possible on the procedural "boundary" of the system: the database, the UI-buider subsystem, etc. It's also very dificult to hide implemenation in a "generic" library that's built without any knowledge of how the classes will be used. The .NET APIs that you mention are examples of these generic and boundary-layer classes.
The techniques I'm discussing apply primarily to the core object-model, the part of the program that stems from the use-case analysis and other modeling that should precede coding. (Even the XP guys use use-case analysis, though they call it story cards.) Put another way, the structure of .NET, the Java packages, etc., are not relevant. I'm talking about the part of the program that *uses* these APIs, the part of the program that *can* hide implemenation because it's focused on implementing a known set of use cases.
Also, re your request for an example, there are a couple of good ones elsewhere in other threads of this discussion. It seems to me that these examples carry more wieght than anything that I can come up with, exactly because they were not posted by myself.
-AIH
|
Andy_
Unregistered
|
|
Holub, you sound a lot like a politician (i.e. George W. Bush). You say something in one sentence, and then you contradict it in the next one.
Eg. The techniques I'm discussing apply primarily to the core object-model, the part of the program that stems from the use-case analysis and other modeling that should precede coding
That sentence is just a bunch of fluff. It really says NOTHING of value. I find a lot of what you write is geared towards moronic managers who dont know technical issues, but like the way certain buzz words sound.
I must admit that your sentence structure and grammar are well written, and I ask myself: Did this man graduate college with an English Lit degree, then taught himself how to program and called himself an expert?
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
