2011-01-31 4 views
2
public static class Th 
{ 
    public static T e<T>(T theObject) where T : class 
    { 
     return theObject; 
    }   
} 

public static class ObjectExtensions 
{ 
    public static bool Is<T>(this T o, Func<T, bool> a) where T : class 
    { 
     return a(o); 
    } 
} 

//... 

//logic in a method somewhere 
Func<string, bool> valid = property => _myService.SomeValidationMethod(property); 

if (Th.e(_request.Property).Is(valid)) 
{ 
    //do something 
} 

이 코드는 제작에 적합하며 그 이유는 무엇입니까?얼마나 유창한 C#으로 너무 멀리 있습니까?

편집 : 의견을 보내 주셔서 감사합니다. 나는 당신이 당신의 반응을 읽었을 때 C# 구문을 깨뜨리는 것에 대해 많은 재미를 느꼈기를 바랍니다.

+1

이해할 필요가있는 의견이 많습니다. 내 눈과 마음에 상처를줍니다. :) –

+0

음 재미 있고 약간 무의미합니다. – Kris

+0

IOC# CC, 누구? – BoltClock

답변

5

유창한 API에는 아무런 문제가 없지만 이것은 최소한의 놀라움의 원칙을 위반하는 것으로 보입니다. Th 클래스의 목적이나 e이라는 메소드의 목적을 이해할 수 없습니다.

+0

... 인수 만 반환합니다. –

+0

나는 그게 무슨 목적으로 봉사하는지 궁금해하고있었습니다. – Marlon

+0

@ Marlon은 더 "유창하게"만들었습니다. dooh! –

2

이 코드가 '유창함'이라고 생각하십니까?

이것은 절대적으로 유창하지 않으며 자체 문서화가 아닙니다.

+5

중괄호, 밑줄 및 점을 모두 무시하면서 살아 남을 수 있다면'if (Th.e (_request.Property) .Is (valid))'를 문장으로 읽을 수 있기 때문에 가능성이 높습니다. –

+0

@Amis, nice, 나는 그 라인보다 한참 전에 처음으로 읽지 않았다. – gjvdkamp

2

너무 큽니다. 코드는 제작에 적합하지 않습니다. Th.e은 정확하게 문구 나 적절한 이름의 코드가 아니며 두 문맥 모두에서 의미가 없습니다.

1

당신이 "유창함"이라고 부르는 것이 매우 중요하며 대부분의 개발자는 CS 알고리즘 작성자와 같이이 점에 대해 정말로 신경을 써야합니다. 사용자에게 보여준 코드 스타일은 언어의 표현력을 남용하는 것이지 매우 유용합니다, IMO, 2 이유 :

  • if (_request.Property.Is(valid)) 심지어 Th 클래스와 Th.e 방법이없는만큼 "유창하게"될 것이다;
  • "유창함"때문에 귀중한 식별자가 없어졌습니다. 다른 물체를 확인해야한다면? if (Th.e(_request.Property2).Is(valid)) 또는 if (Th.e(_request2.Property).Is(valid))을 사용합니까? 다른 검사를해야한다면? if (Th.e(_request.Property).Is(valid2))을할까요?
관련 문제