Софтуерно Инженерство
Loading...
+ Нов въпрос
CharlieScarver avatar 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 в случая).
Не можем да преценим дали интерфейсът е излишен.
Може ли помощ, съвет, мнение.

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

1
Advanced Level: Front-End
a_rusenov avatar 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.

2
05/12/2015 12:20:31
CharlieScarver avatar CharlieScarver 33 Точки

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

0
quickben avatar quickben 976 Точки

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

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

 

2
kosio197 avatar kosio197 104 Точки

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

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

 

 

3
CharlieScarver avatar CharlieScarver 33 Точки

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

0