是否可以省略setter和getter？

假设有2个1组的数据需要传递，以下两种方法都可以。
--[方法1]--
--bean--


package beans;

public class Test
{
	private int i=0;
	private String s="blank";

	public void setI(int i)
	{
		this.i=i;
	}

	public void setS(String s)
	{
		this.s=s;
	}

	public int getI()
	{
		return i;
	}

	public String getS()
	{
		return s;
	}
}
--jsp--
<jsp:useBean id="T" class="beans.Test" scope="page"/>
<body>
<!--写-->
<%
T.setI(23466);
T.setS("Hurry Up!");
%>
<!--读-->
i=<%=T.getI()%><br>
s=<%=T.getS()%><br>
</body>


--[方法2]--
--bean--
package beans;

public class Test
{
	public int i=0;
	public String s="blank";
}
--jsp--
<jsp:useBean id="T" class="beans.Test" scope="page"/>
<body>
<!--写-->
<%
T.i=23466;
T.s="Hurry Up!";
%>
<!--读-->
i=<%=T.i%><br>
s=<%=T.s%><br>
</body>

请各位高手给评价一下二种方法的优劣和性能。
另外请讲讲方法1可以实现JavaBean的自省机制之外的好处。
好像有个规定，只要是属性，就一定要声明成private，也必须要有setter和getter。不过也有反方意见。
对于一个对象的属性，是可以直接读写呢，还是一定要通过一个方法来读写？
比如获取一个String的长度，在java里要用String.length()，在JavaScript里是用String.length。

[该贴被s79于2007年02月18日 18:26修改过]

别人不愿意献丑我就来丢丢脸
俺不是什么高手
但是为什么使用setter，getter
一个对象最重要的是封装
外界应当不了解类内部的事情

比如
class persion
{
private string name;
public void setName(string sName){name = sname;}
public string getName(){return name;}
}
但是可能有一天你对于人名需要处理一下，你可能用户的名字前面加一个前缀，如果你不使用setter的话，你所有进行name赋值的地方都要修改，如果用了setter你只需要修改这个类的setter方法就可以了。

受教了。感谢您的指导，我对封装有更深的认识了。

写起来相对简洁的方法局限性必然相对大。走了捷径自然也就不符合规范了。

随之而来我又有了新的问题：

我们常说OO，但是面对一个具体的业务来说，是否也可以面向业务编程呢？是否可以适当的走一走捷径，甚至偶尔违反一下规范，而用更灵巧的方法来实现目的呢？看到有人提出：解决问题是中心思想，不管你是面向对象，还是面向过程。你可以用Python简化程序的编写，但在效率敏感的地方用c++来实现一些特殊功能。我们去饭店吃套餐是最符合营养搭配最规范卫生和方便的，但谁敢说这套餐太棒了，以后我再也不吃路边摊了？

大家常说一个好的程序特点是可扩展，如果对客户负责，就要做出有生命力的软件。但究竟把握到何种尺度，才算是真正完美的解决呢？要做到多大的可扩展性才能满足日后的发展需要呢？“日圆仄，月满亏，水满溢”，有谁能说把握得好这个尺度，做出一个十几年不用重写，性能上又极优异的软件呢？

我有一把丛林大王一号：
一个真正的野外生存者在野外随身携带的全部工具仅仅应是一把刀，一把真正的野外生存刀。美国萨夫特凯期公司生产的JUNGLEKING（丛林之王）野外生存刀，据称是迄今为止最完美的。西班牙也生产这种刀。这种刀的刃部是由洛氏硬度为56－57的钢制造而成，刀背可做锯子用。橄榄绿色的尼龙刀鞘，除了装刀外，还装有多种野外生存用具，其中有指北针、发信号用的反光镜、钓鱼钩和线、鱼叉头、打火石、磨刀石、别针、橡皮膏、缝补工具、小手术刀、开罐头刀、开瓶器、螺丝刀、铅笔、止血带等。刀鞘底部还有一个折叠叉环，连接橡胶带可作为弹弓。

但是我平时切菜的时候还是用家用菜刀，削铅笔还是用铅笔刀，锯东西我会根据情况选择是用钢锯还是木锯，点火呢，我用点烟的5毛一个的打火机。

我其实很少去丛林，所以我手边经常有更方便的工具。

如果说一个好的框架是这把丛林大王一号，那么你掌握了它的使用方法以后，就可以用它来做几乎所有的事情。但有时候你会觉得它不如手边的其他一些功能单一却更顺手的东西来的痛快。

有人又说了，如果每个人人手一把丛林大王一号，那么任何人的这把刀的任何一个部件坏掉了，只需要借用他人相同的部件就可以无缝的拼装上。这点很cool，因为我们可以很多人一起合作，而不必担心我们哪个人的工具坏掉而导致缺少一个人手了。而且重点是，我们只要掌握这把丛林大王一号的使用方法，就可以齐心合力投入生产了，再也不用学习其他工具的使用办法了。
于是这个小组的每个人开始用丛林大王一号削铅笔，锯木头……
不错，丛林大王一号什么都可以干，但是效率怎么样？

这个小组考虑的是工具的无缝拼装，但为什么不分派成2个小组，一个专门用铅笔刀削铅笔，一个专门用木锯锯木头呢？就算后加入的人不知道这些铅笔是怎么削出来的，这些木头是怎么锯断的，教会他们用铅笔刀和木锯，总比教会他们用丛林大王一号要容易一些吧。

所以我们需要结构简单、构思巧妙、功能单一的组件，拼装起来达到目的。这才是敏捷的编程。

虽然这些组件拿到另外的项目上可能派不上用场，但敏捷的人马上会找到另外的项目上更好的工具。而不是始终揣着丛林大王一号去做所有的事情。

当然，如果你的思维够敏捷，不可能不会用丛林大王一号。只是有时候你不愿意用它。

于是在要解决一个问题的时候，出现了4类人：
1：会用丛林大王一号，但不常用甚至基本不用。
2：会用丛林大王一号，而且精通丛林大王一号在任何不同环境下的使用方法。
3：不会用丛林大王一号，但能使用达到丛林大王一号的一些功能的基本工具。
4：不会用丛林大王一号，也不会用其他工具。

还有更高境界的人，就像Banq大哥一样，觉得美版的丛林大王一号——M16在结构和性能上并不优秀，而自己重新设计了自己的丛林大王一号——AK47来实现同样的功能。

Banq大哥在推销自己的丛林大王一号的同时，也在教大家自己的丛林大王一号的指南针是怎么实现的，坚实的刀刃是怎么实现的。但我个人以为以Banq大哥的造诣，如果能制造出更精妙优雅的、高效的、功能单一的工具供大家选择和参考，受众定会以几何级增长。

最后申明一下，本人只达到了第3种境界，还没研究过任何一个版本的丛林大王一号的功能，也没用过任何一个版本的丛林大王一号解决现有问题，有些见解难免浅薄，还望各位高手批评指正，以免小弟误入歧途。感谢大家阅读此文，给大家拜个年！祝新年事业腾飞，财源广进！

楼上妙文一篇啊。同意:"我们需要结构简单、构思巧妙、功能单一的组件，拼装起来达到目的。这才是敏捷的编程"

如果知道了目标，路径可以选择不同。

非常同意你的观点，但是framework的好处在于你不用自己从基础做起，而是可以从一个基础上建立自己的应用。而不用重新建造，成本是你必须详细阅读使用说明书。
如果你的应用就是一个hello world，使用framework不是不可以，但是会比较讨厌了，如果是一个大型企业应用，你从转头开始建造很可能延误工期。
这是规模决定工具的问题。
[该贴被Coolyu0916于2007年02月20日 17:16修改过]