c# - Is having class Thing that implements interface IThing a bad practice? -

i have class thing, , interface implements, named ithing. uses ithing can presume it's thing, since it's class implements interface, @ same time understands can access subset of public members of thing, , there's pretty design reason — basically, ithing read-only version of thing (it's little bit more complex that, let's pretend it's read-only/write distinction sake of question).

is convention though? alternative, name interface ithingreadonly or name class thingwritable, or this, seems these names bulky , less readable in big codebase.

i use extension methods extensively both interface , class, have thingextensions , ithingextensions well. it's useful, because reads code of extensions can operate assumption uses public members of thing , ithing, respectively. however, having both thingextensions , ithingextensions files sitting alongside in project seem little bit off reason.

so, 1 better option — keep thing , ithing alongside, or rename 1 of them?

update close vote:

this opinion-based question, because it's question best practice — it's not primarily opinion-based question (please mind distinction). has lot of great question , answers best practices, think either there's difference between question , other best-practice question don't see, or question has same right exist other best-practice question.

first off i´d suggest using extension-methods types not have control on, e.g. .net-types ienumerable. may consider create 2 different interfaces, 1 base interface reading (let´s call ithingread) , 1 represents actual thing-type (ithingwrite) write-modifiers.

anyway creating interface every class practice , eases testing mocking uof types.