Võtame kaalust alla

Peter Paul Rubensile meeldisid lopsakad naised ja ta maalis neist ilusaid pilte. Kalduvus tüsedusele ei ole tervislik nii elus eneses kui ka objekt-orienteeritud programmeerimises, mistõttu on praegune mood alakaalulisusele. Tihti näeme liideseid, kus pole ühtegi meetodit ja neid võime nimetada tähisteks või alakaalulisteks.

Vastupidine lähenemine on problemaatiline, sest liiga suured meetodi kogumid peidavad endas mitmeid võimalusi muutumiseks, mis teeb ka väljalubatud liidese kergemini purunevaks. Hea näide on .NET raamistikus MembershipProvider, mis näeb välja selline:

public abstract class MembershipProvider
{
    public override string ApplicationName { get; set; } 

    public override bool ChangePassword(string username, string oldPassword, string newPassword);

    public override bool ChangePasswordQuestionAndAnswer(string username, string password, string newPasswordQuestion, string newPasswordAnswer);

    public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status);

    public override bool DeleteUser(string username, bool deleteAllRelatedData);
    public override bool EnablePasswordReset { get; }
    public override bool EnablePasswordRetrieval { get; } 

    public override MembershipUserCollection FindUsersByEmail(string emailToMatch, int pageIndex, int pageSize, out int totalRecords);

    public override MembershipUserCollection FindUsersByName(string usernameToMatch, int pageIndex, int pageSize, out int totalRecords);

    public override MembershipUserCollection GetAllUsers(int pageIndex, int pageSize, out int totalRecords);

    public int GetNumberOfUsersOnline();
    public string GetPassword(string username, string answer);

    public MembershipUser GetUser(string username, bool userIsOnline);

    public MembershipUser GetUser(object providerUserKey, bool userIsOnline);

    public string GetUserNameByEmail(string email);
    public int MaxInvalidPasswordAttempts { get; }
    public int MinRequiredNonAlphanumericCharacters { get; }
    public int MinRequiredPasswordLength { get; }
    public int PasswordAttemptWindow { get; }
    public MembershipPasswordFormat PasswordFormat { get; }
    public string PasswordStrengthRegularExpression { get; }
    public bool RequiresQuestionAndAnswer { get; }
    public bool RequiresUniqueEmail { get; }
    public string ResetPassword(string username, string answer);
    public bool UnlockUser(string userName);
    public void UpdateUser(MembershipUser user);
    public bool ValidateUser(string username, string password);
}

Kuidagi palju meetodeid? Tundub nii. Vaatame teist näidet, mis mis võib tekkida omapoolse abstraktsiooni tegemisel.

public interface IEntity
{
    long Identity { get; }
    void Insert();
    void Update();
    void Delete();
}

Sellise liidese puhul on sinnamaani kõik hästi kui tekkib olem, mida näiteks ei saa salvestada või kustutada. Lahendusi on sellele mitmeid: ebavajalikes meetodites teavitada veaga, et see pole võimalik; jagada liides mitmeks. Esimene variant on piisavalt segadust tekitav ning halb objekt-orienteeritud lahendus. Teine lahendus näeks välja järgnev:

public interface IEntity
{
    long Identity { get; }
}
public interface IAddable
{
    void Insert();
}
public interface IEditable
{
    void Update();
}
public interface IDeletable
{
    void Delete();
}

Moraal on siin lihtne – objekte ei tohiks sundida realiseerima meetodeid, mida nad ei kasuta (Interface Segregation Principle).

Liidestel on aeg nüüd dieedile minna.