Class or instance method makes no difference in this case with regard to
polymorphism.
On Jan 12, 2011, at 4:51 PM, Gordon Apple wrote:
> What I would do use a class method and pass the two arrays as parameters.
>
>
> On 1/12/11 2:03 PM, "cocoa-dev-requ...@lists.apple.com"
> <cocoa-dev-requ...@lists.apple.com> wrote:
>
>> Yes, you can, but... don't forget that in -computeVar3... self is not fully
>> initialized. If you have all control on self it can be without problems, but
>> Objective-C is an OO language. Consider this :
>>
>> - Your class is ClassA with it's init method.
>> - Then you have ClassB, subclass of ClassA. ClassB override -init cleanly
>> (call super in the beginning etc.)
>> - Then ClassC, subclass of ClassB. ClassC override -computeVar3.
>> And then the problems can begin, in -[ClassC computeVar3] self is not fully
>> initialize from the point of view of ClassA, but the initialization has not
>> even began from the point of view of ClassB and ClassC. I think it's a break
>> of encapsulation principle.
>>
>> If you want to put the code outside -init only for code readability, just use
>> a plain C function.
>>
>> Frédéric
>>
>> Le 12 janv. 2011 à 12:41, Luc Van Bogaert a écrit :
>>
>>> Hi,
>>>
>>> I have a question about how to design a initializer mehod.
>>>
>>> I have defined a class with three instance variables. Two of them are arrays
>>> and their value can be initialized straightforward in the initializer
>>> method,
>>> but the value of the third instance variable is the result of a complex
>>> algorithm, based on the contents of the two arrays.
>>>
>>> I would like to implement that algorithm in a seperate method, instead of
>>> writing it directly in the initializer. Is that OK, and could I then message
>>> "self" in the initializer like:
>>>
>>> - (id) init
>>> {
>>> self = [super init];
>>> if (self) {
>>> var1 = ...;
>>> var2 = ...;
>>> var3 = [self computerVar3With:var1:var2];
>>> }
>>> return self;
>>> }
>>>
>>> Or is it better to write the algorithm directly as part of the initializer?
>>> Thanks,
>>>
>>> --
>>> Luc Van Bogaert
>>> luc.van.boga...@me.com
>>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/cocoa-dev/ftestuz%40bluewin.ch
>>>
>>> This email sent to ftes...@bluewin.ch
>
> --
> Gordon Apple
> Ed4U
> Little Rock, AR
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/erik.buck%40sbcglobal.net
>
> This email sent to erik.b...@sbcglobal.net
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
