On Wed, Apr 30, 2008 at 12:05 AM, Robert Cummings <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-04-29 at 23:51 -0400, Nathan Nobbe wrote: > > On Tue, Apr 29, 2008 at 9:22 PM, Robert Cummings <[EMAIL PROTECTED]> > > wrote: > > > > > > > > That should be a matter of choice for the developer. When you say > > "but > > > when, down the road, some logic...", all I see is you waving your > > hands > > > in the air and presuming that the logic will change. The logic may > > not > > > change, in which case why am I incurring the cost of getter/setter > > > methods. "If" the logic changes, I'll be happy to add getter and > > setter > > > methods at that time and punt the needed functionality into the > > magic > > > methods which will call the appropriate getter or setter method. You > > are > > > preparing for a future that may not come, I am willing to > > retroactively > > > handle that future "if" it arrives. Neither approach strikes me as > > being > > > more correct but rather they each presume an educated guess on the > > > likelihood of the property changing it's semantics down the road. > > > > > > the developer does have a choice. to use an interface, or an abstract > > class. data facilitates methods accomplishing what it is they > > purport. > > quite frankly, i have never written an interface with getters and / or > > setters anyway, nor do i see the need to. i would consider it silly. > > interfaces are typically used to say, any class that makes this happen > > will > > likely do it in a way differently than all the others. since, getters > > and > > setters are almost always implemented the exact same way i find these > > topics > > to be rather different. if there is in fact a standard way of doing > > things > > for any given interface, then to realize it, a common implementor > > class can > > be composed, and delegated to by classes that implement said interface > > in > > the 'standard' way. > > Abstract classes and interfaces are not the same. They are used for > fundamentally different reasons. An interface is to enforce a contract > for all implementations of the interface. Therefore if I were to create > an interface with an interface property of x, then all implementations > using that interface would know that property x exists and could use it > thusly without having to check for it's existence. i am fully aware of the differences between interfaces and abstract classes. however, if a public method is defined on any class, abstract or concrete, it may be used without checking by client code; i believe thats the entire point.. > Using an abstractclass is a hack, it's not sufficient for enforcement, and > you can't > combine multiple abstract classes as you can with interfaces. abstract classes have their place. primarily they are well suited for template method because some methods can be forced to be implemented by children and others can be optionally overridden. and lastly, coming to multiple inheritance (for lack of better terminology); that is the only argument with any value for adding public attributes to the interface construct; however i am still not receptive to it. from my perspective data is an implementation detail, period. -nathan
