Re: MVP's: static methods in interfaces. (REDEFINED)

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Picho (SPAM_picho_at_telhai.ac.il)
Date: 12/21/04 

Date: Tue, 21 Dec 2004 18:37:50 +0200

And if I may, add to Dans example that that class is implementing an
interface - that is - following the interface-programing guidlines, and
moreover, this static method is public and therfore should be publicly known
in some manner....

"Dan Bass" <danielbass [at] postmaster [dot] co [dot] uk> wrote in message
news:uXFRYk35EHA.2568@TK2MSFTNGP11.phx.gbl...
> How would you approach the following:
>
> In developing an application, it becomes obvious that a few lines of code
> is being repeated more than a few times and so refactoring is to be done.
> The thing is it's not necessarily object specific, but more of a general
> set of commands.
>
> My approash is a class that contains a public static method that is
> declared as follows:
>
> public static string ExceptionInfo ( Exception ex )
> {
> if ( ex == null ) return "";
>
> StringBuilder sb = new StringBuilder();
> sb.Append( " Exception: " );
> sb.Append( ex.Message );
> sb.Append("\r\n");
> sb.Append( " Stack Trace: ");
> sb.Append( ex.StackTrace );
> return sb.ToString();
> }
>
> This is referenced all over applications, across different projects in my
> solution (which means it's in a constants / enum definitions / type class
> library) every time an exception of any sort is thrown for logging
> purposes.
>
> Is this incorrect / bad / undesirable?
>
> Thanks for your time.
>
> Daniel.
>
>
> "Nick Malik [Microsoft]" <nickmalik@hotmail.nospam.com> wrote in message
> news:xBXxd.218947$5K2.160644@attbi_s03...
>> Hello Picho,
>>
>> You have a distaste for class factories. That is unfortunate. In
>> Component-oriented-design, it is considered a good practice for one body
>> of
>> code to define a behavior (the interface) and another body of code to
>> define
>> how an instance is created (the factory method). These are seperate on
>> purpose. Behaviors are not the same as instances, and the logic for
>> creating instances is often quite complex. There is no reason for them
>> to
>> be coupled together, and forcing them apart often reduces unnecessary
>> coupling.
>>
>> There are seperate patterns that manage and control the ways that objects
>> are created. These are termed 'creational patterns' in the GoF book.
>> Included are Factory Method, Abstract Factory, Singleton, Builder, and
>> Prototype. Take a look at these patterns. Only Prototype and Singleton
>> are
>> coupled to the class, and then Singleton is only coupled because of
>> language
>> constraints, not OO principles. The rest illustrate the principle that
>> the
>> construction of an object is an inherently seperate process from its use.
>>
>> You can still use interfaces to describe object creation. That is what
>> the
>> Abstract Factory pattern describes. However, in this case, you have an
>> interface that is responsible for creating a set of _related_ objects.
>> By
>> deriving types from an abstract factory, you can create a framework.
>>
>> I personally discourage the use of static methods for nearly all OO
>> programmers. You should use a static method ONLY when there is a
>> behavior
>> of a type that is independent of the instance of that type, and even
>> then,
>> you'd be challenged in a code review to justify it. This is not because
>> I
>> dislike the construct. It is because this construct can lead to lazy
>> programming (not just in initial development... but also in maintenance
>> programming). I see very few reasons for opening the door to lazy
>> programming.
>>
>> And maybe that's just me :-).
>>
>> --
>> --- Nick Malik [Microsoft]
>> MCSD, CFPS, Certified Scrummaster
>> http://blogs.msdn.com/nickmalik
>>
>> Disclaimer: Opinions expressed in this forum are my own, and not
>> representative of my employer.
>> I do not answer questions on behalf of my employer. I'm just a
>> programmer helping programmers.
>> --
>> "Picho" <SPAM_picho@telhai.ac.il> wrote in message
>> news:%238axdm25EHA.2124@TK2MSFTNGP15.phx.gbl...
>>> OK.
>>>
>>> Let me rearange this...
>>>
>>> obviosly you are not following me and this is usualy my fault...
>>>
>>> I know all about interfaces, constructors, abstract classes and
>>> everything
>>> you guys already said.
>>> If you are famalier with component-oriented design or interface-based
>>> programming, this question is for you.
>>>
>>> We are supposed to use interface-based programming for many reasons.
>> Static
>>> methods ARE infact "a behavior" that I would like to declare and use in
>>> my
>>> class. I was mearly expressing my distress since we cannot declare
>> "static"s
>>> in an interface but still encoureged to use interface-based
>>> programming...
>>>
>>> Thanx again.
>>>
>>> Picho
>>>
>>>
>>>
>>> "Picho" <SPAM_picho@telhai.ac.il> wrote in message
>>> news:%23489sfz5EHA.828@TK2MSFTNGP14.phx.gbl...
>>> > Hi all,
>>> >
>>> > I popped up this question a while ago, and I thought it was worth
>> checking
>>> > again now... (maybe something has changed or something will change).
>>> >
>>> > I read this book about component oriented design (owreilly - Juval
>> Lowy),
>>> > and it was actually very nice.
>>> > The book goes on about how we should use Interfaces exposure instead
>>> > of
>>> > classes (this is my terminology and english is not my language so I
>>> > hope
>>> > you understand what I'm on about...).
>>> >
>>> > however...
>>> >
>>> > I want to give my classes the ability to staticly create instances,
>> simply
>>> > because I think that calling a 'MyClass.FromSomething(Something
>>> > something)' is more intuative than a constructor 'public
>> MyClass(Something
>>> > something)'
>>> >
>>> > this is just me...
>>> >
>>> > anyway, as far as I know interfaces cannot define static members. this
>>> > pushed me into something I even like less - a class factory (even
>>> > though
>>> > it is in some scenarios a good practice).
>>> >
>>> > MVP's...
>>> >
>>> > 1. Is there a more... 'elegant' way for me to achieve this?
>>> > 2. is this somehing we want from C# (static member decleration in
>>> > interfaces)?
>>> > 3. am I just being picky (should I just use constructors and forget my
>>> > intuition?)
>>> > 4. am I totaly wrong?
>>> > 5. all the above
>>> >
>>> > Thanx,
>>> > Picho
>>> >
>>> > hang on... can we even define constructors in interfaces today?...
>>> > god I even confused myself...
>>> >
>>> >
>>>
>>>
>>
>>
>
>

Relevant Pages

  • Re: MVPs: static methods in interfaces. (REDEFINED)
    ... My approash is a class that contains a public static method that is declared ... These are termed 'creational patterns' in the GoF book. ... > Abstract Factory pattern describes. ... > programming). ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: static method in interface?
    ... What would a static method on an interface mean? ... "Whatever class implements this interface must also ... situation, if the interface declared a static property, this would not ... The second is a way of associating code that belongs with the interface ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Separation of API and implementation
    ... I'm missing something or an Abstract Factory could help? ... I have an API defined in one plugin, ... interface X { ... implementation of Y, say YImpl. ...
    (comp.object)
  • Re: Design for test
    ... tests for it so I imagine I have to make an interface for MySession ... Is always going to access the implementation in MyAbstractClass, which I doubt is what you want, if you've also declared getInt() in MyClass. ... With no implementation for the static method allow in the interface, it really doesn't make sense for a static method to be there. ...
    (comp.lang.java.programmer)
  • Re: Making a generic Parameter class
    ... I've used the adapter and abstract factory patterns before. ... What I need to know is if there is already a generic implementation class ... for the IdbParameter interface that I can use? ... If you have a database (that is not ...
    (microsoft.public.dotnet.general)