[C# OOP] Unnecessary Interface

Във форума е въведено ограничение, което позволява на потребителите единствено да разглеждат публикуваните въпроси.

CharlieScarver 33 Точки

[C# OOP] Unnecessary Interface

Правим игра на MonoGame по ООП.
Структурата за момента ни е: http://puu.sh/lJWhe/da1444f8cb.png
Имаме интерфейс IDrawable, който изглежда така:

public interface IDrawable<br> {

Texture2D SpriteSheet { get; }

int TextureWidth { get; }

int TextureHeight { get; }

void Draw(SpriteBatch spriteBatch);<br> }

SpriteSheet, TextureWidth и TextureHeight се използват единствено в най-конкретните класове. (Aya в случая).
Не можем да преценим дали интерфейсът е излишен.
Може ли помощ, съвет, мнение.

Малко обяснение относно кога е добре нещо да се отдели в интерфейс и има ли смисъл от интерфейс над абстрактен клас също няма да е излишно.
Благодаря

Тагове:

05/12/2015 10:37:17 Advanced Level: Front-End

a_rusenov 1103 Точки

Best Answer

Да приемем, че имаш клас Renderer, който се грижи за графичната част. И сега въпросът е дали да приема колекция от IDrawable или GameObject. По-добре IDrawable, понеже така той ще вижда само тези неща на обекта, които са му необходими за рисуването (SpriteSheet, TextureWidth, etc.). като се абстрахира от другите особености на GameObject.

Основното предимство в този случай е, че се разкачаш максимално от останалия проект (loose coupling) и дейността на Renderer-а се гарантира да бъде около рисуването (strong cohesion), просто защото няма достъп до другите свойства на обекта. Също така в бъдеще може да имплементираш друг клас, който също е IDrawable, но не GameObject, и Renderer-a също ще може да работи с него.

Ако търсиш всеобщо валиден отговор на въпроса - зависи според проекта. Ако интерфейсът и абстрактният клас се припокриват като поведение и проектът ти няма изглед да се променя, тогава може би няма нужда от интерфейс. В случая обаче абстрактния т ти клас имплементира няколко поведения (освен IDrawable) и е по-добре те да останат скрити от Renderer-a.

05/12/2015 12:08:29 05/12/2015 12:20:31

CharlieScarver 33 Точки

Много благодаря за отговора.
Мисля, че разбирам.

05/12/2015 23:43:03

quickben 966 Точки

https://en.wikipedia.org/wiki/Interface_segregation_principle

А относно това дали има смисъл един абстрактен клас да имплементира интерфейс - според мен има, с оглед на това, че другото име на интерфейса е договор(contract), по този начин си гарантираш, че абстрактния клас ще имплементира нужните му методи, но това си е мое мнение, някой с по-голям опит да каже.

05/12/2015 11:39:23

kosio197 104 Точки

Наскоро и аз си задавах същия въпрос и след като ми обясниха хора с голям опит ето извода:

Обикновенно не е добре "нещо да се отдели в интерфейс". Тръгва се от самия интерфейс. Със сигурност няма смисъл за всеки клас да пишеш интерфейс. Ако обаче пишеш някаква функционалност, която налага използването на методи независимо от конкретиката на тяхната имплементация тогава пишеш интерфейса и то без имплементации на него в началото - пишеш го, ползваш го за функционалността си и едва тогава правиш конкретната имплементация. В случая, ако ти пакетираш този проект и го дадеш на друг да го ползва (примерно няколко екипа разработвате играта и ти го дадеш на друг екип) този екип ще може ли имплементирайки само този интерфейс да нарисува примерно нов герой в играта(не знам конкретиката, но идеята е имплементирайки един или няколко интерфейса да може да се направи нещо завършено)? - Ако отговора е да - има смисъл от интерфейса, ако отговора е не - два варината: 1. няма смисъл от него; 2. има смисъл от него, но не не добре написан(ей това може да се поучи когато интерфейс е изваден от клас, а не е мислен като самостоятелна еденица) .

05/12/2015 12:25:22

CharlieScarver 33 Точки

Благодаря. Много хубаво обяснение.

06/12/2015 00:41:23