JavaRush /Java Blog /Random-TL /Pagdidisenyo ng mga Klase at Interface (Pagsasalin ng art...

Antas

28 February 2021
35 views
0 comments

Pagdidisenyo ng mga Klase at Interface (Pagsasalin ng artikulo)

Проектирование Классов и Интерфейсов (Перевод статьи) - 1

Nilalaman

Panimula
Mga interface
Mga marker ng interface
Mga functional na interface, static na pamamaraan at default na pamamaraan
Mga abstract na klase
Mga hindi nababagong (permanenteng) klase
Anonymous na klase
Visibility
Mana
Maramihang mana
Mana at komposisyon
Encapsulation
Mga huling klase at pamamaraan
Anong susunod
I-download ang source code

1. PANIMULA

Anuman ang ginagamit mong wika ng programming (at ang Java ay walang pagbubukod), ang pagsunod sa mahusay na mga prinsipyo ng disenyo ay ang susi sa pagsulat ng malinis, naiintindihan, at nabe-verify na code; at likhain din ito upang mahaba ang buhay at madaling suportahan ang paglutas ng problema. Sa bahaging ito ng tutorial, tatalakayin namin ang pangunahing mga bloke ng gusali na ibinibigay ng wikang Java at ipakilala ang ilang mga prinsipyo ng disenyo sa pagsisikap na tulungan kang gumawa ng mas mahusay na mga desisyon sa disenyo. Higit na partikular, tatalakayin natin ang mga interface at interface gamit ang mga default na pamamaraan (isang bagong feature sa Java 8), abstract at final classes, immutable classes, inheritance, composition, at muling bisitahin ang visibility (o accessibility) na mga panuntunan na panandalian nating natalakay sa. Bahagi 1 aralin "Paano lumikha at sirain ang mga bagay" .

2. MGA INTERFACES

Sa object - oriented programming, ang konsepto ng mga interface ay bumubuo ng batayan para sa pagbuo ng mga kontrata . Sa madaling sabi, ang mga interface ay tumutukoy sa isang hanay ng mga pamamaraan (mga kontrata) at ang bawat klase na nangangailangan ng suporta para sa partikular na interface ay dapat magbigay ng pagpapatupad ng mga pamamaraang iyon: isang medyo simple ngunit makapangyarihang ideya. Maraming mga programming language ang may mga interface sa isang anyo o iba pa, ngunit ang Java sa partikular ay nagbibigay ng suporta sa wika para dito. Tingnan natin ang isang simpleng kahulugan ng interface sa Java.

package com.javacodegeeks.advanced.design;

public interface SimpleInterface {
void performAction();
}

Sa snippet sa itaas, ang interface na tinawag namin SimpleInterface, ay nagdedeklara lamang ng isang paraan na tinatawag na performAction. Ang pangunahing pagkakaiba sa pagitan ng mga interface at mga klase ay ang mga interface ay nagbabalangkas kung ano ang dapat na contact (nagdedeklara sila ng isang pamamaraan), ngunit hindi nagbibigay ng kanilang pagpapatupad. Gayunpaman, ang mga interface sa Java ay maaaring maging mas kumplikado: maaari silang magsama ng mga nested na interface, mga klase, mga bilang, mga anotasyon, at mga constant. Halimbawa:

package com.javacodegeeks.advanced.design;

public interface InterfaceWithDefinitions {
    String CONSTANT = "CONSTANT";

    enum InnerEnum {
        E1, E2;
    }

    class InnerClass {
    }

    interface InnerInterface {
        void performInnerAction();
    }

    void performAction();
}

Sa mas kumplikadong halimbawang ito, mayroong ilang mga paghihigpit na walang kondisyong ipinapataw ng mga interface sa mga nesting construct at mga deklarasyon ng pamamaraan, at ang mga ito ay ipinapatupad ng Java compiler. Una sa lahat, kahit na hindi tahasang idineklara, ang bawat paraan ng deklarasyon sa isang interface ay pampubliko (at maaari lamang maging pampubliko). Kaya ang mga sumusunod na deklarasyon ng pamamaraan ay katumbas:

public void performAction();
void performAction();

Стоит упомянуть, что каждый отдельный метод в интерфейсе неявно объявлен абстрактным и даже эти объявления метода эквивалентны:

public abstract void performAction();
public void performAction();
void performAction();

What касается объявленных полей констант, дополнительно к тому что они являются публичными, они также неявно статические и помечены, How final. Поэтому следующие объявления также эквивалентны:

String CONSTANT = "CONSTANT";
public static final String CONSTANT = "CONSTANT";

И, наконец, вложенные классы, интерфейсы or подсчеты, кроме того, что являются публичными, также неявно объявлены How static. К примеру, данные объявления также эквивалентны:

class InnerClass {
}

static class InnerClass {
}

Стиль, который вы выберете — это ваше личное предпочтение, однако знание этих простых свойств интерфейсов может спасти вас от ненужного ввода.

3. Интерфейс-маркер

Интерфейс маркеры — это особый вид интерфейса, у которого нет методов or других вложенных конструкций. Как это определяет библиотека Java:

public interface Cloneable {
}

Интерфейс-маркеры — не контракты по сути, но отчасти полезная техника, чтобы «прикрепить" or «связать" некоторую специфическую черту с классом. К примеру, относительно Cloneable, класс помечен How доступный для клонирования, однако, способ, которым это можно or следует реализовать, — не является частью интерфейса. Еще один очень известный и широко используемый пример интерфейс-маркера — это Serializable:

public interface Serializable {
}

Этот интерфейс помечает класс, How пригодный для преобразования в последовательную форму (сериализацию) и десериализацию (deserialization), и снова, это не указывает способ, How это можно or следует реализовывать. Интерфейс-маркеры занимают свое место в an objectно-ориентированном программировании, хотя они не удовлетворяют главную цель интерфейса, чтобы быть контрактом.

4. ФУНКЦИОНАЛЬНЫЕ ИНТЕРФЕЙСЫ, МЕТОДЫ ПО УМОЛЧАНИЮ И СТАТИЧЕСКИЕ МЕТОДЫ

С выпусков Java 8, интерфейсы получor новые очень интересные возможности: статические методы, методы по умолчанию и автоматическое преобразование из лямбд (функциональные интерфейсы). В разделе интерфейсы, мы подчеркивали тот факт, что интерфейсы в Java могут только объявлять методы, но не обеспечивают их реализацию. С методом по умолчанию, все иначе: интерфейс может отметить метод ключевым словом default и обеспечить реализацию для него. Например:

package com.javacodegeeks.advanced.design;

public interface InterfaceWithDefaultMethods {
    void performAction();

    default void performDefaulAction() {
        // Implementation here
    }
}

Будучи на уровне экземпляра, методы по умолчанию могли быть переопределены каждой реализацией интерфейса, но теперь интерфейсы также могут включать статические методы, например: package com.javacodegeeks.advanced.design;

public interface InterfaceWithDefaultMethods {
    static void createAction() {
        // Implementation here
    }
}

Можно сказать, что предоставление реализации в интерфейсе наносит поражение целому замыслу контрактного программирования . Но есть много причин, почему эти функции были введены в язык Java и независимо от того, насколько они полезны or сбивающие с толку, они есть там для вас и вашего пользования. Функциональные интерфейсы это совсем другая история и они опробованы, How очень полезные дополнения к языку. В основном, функциональный интерфейс — это интерфейс всего лишь с одним абстрактным методом, объявленным в нем. Runnable интерфейс из стандартной библиотеки — это очень хороший пример этой концепции.

@FunctionalInterface
public interface Runnable {
    void run();
}

Компилятор Java по-разному обрабатывает функциональные интерфейсы и может превратить лямбда-функцию в реализацию функционального интерфейса, где это имеет смысл. Давайте рассмотрим следующее описание функции:

public void runMe( final Runnable r ) {
    r.run();
}

Для вызова этой функции в Java 7 и ниже должна предоставляться реализация интерфейса Runnable (например используя анонимные классы), но в Java 8 достаточно передать реализацию метода run() используя синтаксис лямбды:

runMe( () -> System.out.println( "Run!" ) );

Кроме того, annotation @FunctionalInterface (аннотации будут раскрыты в деталях в 5 части учебника) намекает, что компилятор может проверить, содержит ли интерфейс только один абстрактный метод, поэтому любые изменения, внесенные в интерфейсе в будущем не будет нарушать это предположение.

5. АБСТРАКТНЫЕ КЛАССЫ

Еще одна интересная концепция, поддерживаемая языком Java, — понятие абстрактных классов. Абстрактные классы отчасти похожи на интерфейсы в Java 7 и очень близки интерфейсу с методом по умолчанию в Java 8. В отличие от обычных классов, нельзя создавать экземпляры абстрактного классы, но он может быть подклассом (обратитесь к разделу "Наследование" для получения более подробной информации). What еще более важно, абстрактные классы могут содержать абстрактные методы: особый вид методов без реализации, так же, How и интерфейс. Например:

package com.javacodegeeks.advanced.design;

public abstract class SimpleAbstractClass {
    public void performAction() {
        // Implementation here
    }

    public abstract void performAnotherAction();
}

В этом примере, класс SimpleAbstractClass объявлен How абстрактный и содержит один объявленный абстрактный метод. Абстрактные классы очень полезны, большинство or даже некоторые части деталей реализации могут совместно использоваться с многими подклассами. Как бы там ни было, они по-прежнему оставляют дверь приоткрытой и позволяют настроить поведение присущее каждому из подкласса с помощью абстрактных методов. Стоит упомянуть, в отличие от интерфейсов, которые могут содержать только публичные объявления, абстрактные классы могут использовать всю мощь правил доступности, чтоб управлять видимостью абстрактного метода.

6. НЕИЗМЕНЯЕМЫЕ КЛАССЫ

Неизменяемость становится все более и более важной в разработке программного обеспечения в наше время. Подъем многоядерных систем вызвало много вопросов, связанных с совместным использованием данных и параллелизмом. Но одна проблема определенно возникла: небольшое (or даже отсутствие) изменяемого состояния приводит к лучшей расширяемости (масштабируемости) и более простому рассуждению о системе. К сожалению, язык Java не обеспечивает достойную поддержку классовой неизменности. Однако, пользуясь комбинацией техник, становится возможно проектировать классы, которые неизменны. Прежде всего, все поля класса должны быть окончательные (помечены How final). Это хорошее начало, но не дает гарантий.

package com.javacodegeeks.advanced.design;

import java.util.Collection;

public class ImmutableClass {
    private final long id;
    private final String[] arrayOfStrings;
    private final Collection<String> collectionOfString;
}

Во вторых, следите за правильной инициализацией: если поле является ссылкой на коллекцию or массив, не назначайте те поля непосредственно из аргументов конструктора, вместе этого делайте копии. Это будет гарантировать, что состоянии коллекции or массива не будет изменено за пределами.

public ImmutableClass( final long id, final String[] arrayOfStrings,
        final Collection<String> collectionOfString) {
    this.id = id;
    this.arrayOfStrings = Arrays.copyOf( arrayOfStrings, arrayOfStrings.length );
    this.collectionOfString = new ArrayList<>( collectionOfString );
}

И наконец, обеспечение надлежащего доступа (гетеры). Для коллекций, неизменяемый вид должен быть предоставлен в виде обертки Collections.unmodifiableXxx: С массивами единственный способ обеспечить настоящую неизменяемость – это предоставить копию instead of возвращения ссылки на массив. Это может быть неприемлемо с практической точки зрения, так How это очень зависит от размера массива и может возложить огромное давление на сборщика мусора.

public String[] getArrayOfStrings() {
    return Arrays.copyOf( arrayOfStrings, arrayOfStrings.length );
}

Даже этот маленький пример дает хорошую идею, что неизменяемость еще не гражданин первого класса в Java. Все может быть усложнено, если неизменяемый класс имеет поле, ссылающийся на an object другого класса. Те классы должны быть также неизменны, однако нет ниHowого способа это обеспечить. Есть несколько достойных анализаторов исходного codeа в Java, How FindBugs и PMD, которые могут существенно помочь, проверяя ваш code и указывая на общие недостатки программирования Java. Эти инструменты - большие друзья любого разработчика Java.

7. АНОНИМНЫЕ КЛАССЫ

В предварительной Java 8 era, анонимные классы были единственным способом обеспечить оперативное определение классов и немедленное создание экземпляра. Целью анонимных классов было уменьшить шаблон и обеспечить краткий и легкий путь представления классов How запись. Давайте взглянем на типичный старомодный путь породить новый поток в Java:

package com.javacodegeeks.advanced.design;

public class AnonymousClass {
    public static void main( String[] args ) {
        new Thread(
            // Example of creating anonymous class which implements
            // Runnable interface
            new Runnable() {
                @Override
                public void run() {
                    // Implementation here
                }
            }
        ).start();
    }
}

В этом примере реализация Runnable interface предоставляется сразу How анонимный класс. Хотя есть некоторые ограничения, связанные с анонимными классами, основные недостатки их использования — весьма подробный синтаксис конструкций, которым обязывает Java How язык. Даже просто анонимный класс, который ничего не делает, требует по меньшей мере 5 линий codeа каждый раз при записи.

new Runnable() {
   @Override
   public void run() {
   }
}

К счастью, с Java 8, лямбдой и функциональными интерфейсами все эти стереотипы скоро уйдут, наконец написание codeа Java будет выглядеть по настоящему кратко.

package com.javacodegeeks.advanced.design;

public class AnonymousClass {
    public static void main( String[] args ) {
        new Thread( () -> { /* Implementation here */ } ).start();
    }
}

8. ВИДИМОСТЬ

Мы уже немного говорor о правилах видимости и доступности в Java в части 1 учебника. В этой части мы собираемся вернуться к этой теме снова, но в контексте создания подклассов. Проектирование Классов и Интерфейсов (Перевод статьи) - 2

Проектирование Классов и Интерфейсов (Перевод статьи) - 2

Видимость различных уровней разрешает or запрещает классам просматривать другие классы or интерфейсы (например, если они находятся в разных пакетах or вложены друг в друга) or подклассам видеть и получать доступ к методам, конструкторам и полям их родителей. В следующем разделе, наследование, мы увидим это в действии.

9. НАСЛЕДОВАНИЕ

Наследование — одно из ключевых понятий an objectно-ориентированного программирования, выступающее в качестве основы построения класса связей. В сочетании с видимостью и правилами доступности, наследование позволяет проектировать классы иерархии, с возможностью расширения и поддерживания. На понятийном уровне, наследование в Java реализуется с помощью создание подклассов и ключевого слова extends, вместе с родительским классом. Подкласс наследует все публичные и защищенные элементы родительского класса. Кроме того, подкласс наследует package-private элементы родительского класса, если оба (подкласс и класс) находятся в одном пакете. При этом, очень важно, независимо от того, что вы пытаетесь спроектировать, придерживаться минимального набора метода, которые класс выставляет публично or для его подклассов. Например, давай те рассмотрим класс Parent и его подкласс Child, чтобы продемонстрировать разницу в уровнях видимости и их эффекты.

package com.javacodegeeks.advanced.design;

public class Parent {
    // Everyone can see it
    public static final String CONSTANT = "Constant";

    // No one can access it
    private String privateField;
    // Only subclasses can access it
    protected String protectedField;

    // No one can see it
    private class PrivateClass {
    }

    // Only visible to subclasses
    protected interface ProtectedInterface {
    }

    // Everyone can call it
    public void publicAction() {
    }

    // Only subclass can call it
    protected void protectedAction() {
    }

    // No one can call it
    private void privateAction() {
    }

    // Only subclasses in the same package can call it
    void packageAction() {
    }
}

package com.javacodegeeks.advanced.design;

// Resides in the same package as parent class
public class Child extends Parent implements Parent.ProtectedInterface {
    @Override
    protected void protectedAction() {
        // Calls parent's method implementation
        super.protectedAction();
    }

    @Override
    void packageAction() {
        // Do nothing, no call to parent's method implementation
    }

    public void childAction() {
        this.protectedField = "value";
    }
}

Наследование — очень большая тема сама по себе, с большим количеством тонких деталей, характерных для Java. Однако, есть несколько правил, которым легко следовать, и которые могут очень помочь сохранить краткость в классовой иерархии. В Java, каждый подкласс может переопределять любые унаследованные методы его родителя, если он не был объявлен How окончательный (final). Однако, нет специального синтаксиса or ключевого слова, чтобы пометить метод, How переопределенный, что может привести к путанице. Вот почему была введена annotation @Override: всякий раз , когда ваша цель – переопределить наследуемый метод, пожалуйста, используйте аннотацию @Override, чтобы кратко обозначить это. Другая дилемма, с которой Java разработчики постоянно сталкиваются в проектирование — это построение классов иерархии (с конкретными or абстрактными классами) в сравнении с реализацией интерфейсов. Настоятельно рекомендуем отдавать предпочтение интерфейсам по отношению к классам or абстрактным классам, где это возможно. Интерфейсы более легкие, их проще тестировать и поддерживать, плюс ко всему, они минимизируют побочные эффект изменений реализации. Многие продвинутые техники программирования, такие How создание прокси (proxy) классов в стандартной библиотеке Java, в большей степени полагаются на интерфейсы.

10. МНОЖЕСТВЕННОЕ НАСЛЕДОВАНИЕ

В отличие от С++ и некоторых других языков, Java не поддерживает множественное наследование: в Java каждый класс может иметь только одного прямого родителя (с классом Object в вершине иерархии). Однако, класс может реализовывать несколько интерфейсов, и, таким образом, стекование (stacking) интерфейсов — единственный способ достигнуть (or имитировать) множественное наследование в Java.

package com.javacodegeeks.advanced.design;

public class MultipleInterfaces implements Runnable, AutoCloseable {
    @Override
    public void run() {
        // Some implementation here
    }

    @Override
    public void close() throws Exception {
       // Some implementation here
    }
}

Реализация нескольких интерфейсов на самом деле довольно мощная, но часто необходимость снова и снова использовать реализацию приводит к глубокой классовой иерархии, How способ преодолеть отсутствие поддержки множественного наследования в Java.

public class A implements Runnable {
    @Override
    public void run() {
        // Some implementation here
    }
}

// Class B wants to inherit the implementation of run() method from class A.
public class B extends A implements AutoCloseable {
    @Override
    public void close() throws Exception {
       // Some implementation here
    }
}

// Class C wants to inherit the implementation of run() method from class A
// and the implementation of close() method from class B.
public class C extends B implements Readable {
    @Override
    public int read(java.nio.CharBuffer cb) throws IOException {
       // Some implementation here
    }
}

И так далее.. Недавний выпуск Java 8 несколько решает проблему с внедрением методов по умолчанию. Из-за методов по умолчанию, интерфейсы фактические стали предоставлять не только контракт, но и реализацию. Следовательно, классы, которые реализуют эте интерфейсы, также автоматически унаследуют эти реализованные методы. Например:

package com.javacodegeeks.advanced.design;

public interface DefaultMethods extends Runnable, AutoCloseable {
    @Override
    default void run() {
        // Some implementation here
    }

    @Override
    default void close() throws Exception {
       // Some implementation here
    }
}

// Class C inherits the implementation of run() and close() methods from the
// DefaultMethods interface.
public class C implements DefaultMethods, Readable {
    @Override
    public int read(java.nio.CharBuffer cb) throws IOException {
       // Some implementation here
    }
}

Имейте в виду, что множественное наследование очень мощный, но и в тоже время опасный инструмент. Хорошо известную проблему «Ромб смерти» часто называют основным дефектом реализации множественного наследования, поэтому разработчики вынуждены проектировать классы иерархии весьма тщательно. К сожалению, интерфейсы Java 8 с методами по умолчанию также становится жертвой этих дефектов.

interface A {
    default void performAction() {
    }
}

interface B extends A {
    @Override
    default void performAction() {
    }
}

interface C extends A {
    @Override
    default void performAction() {
    }
}

Например, следующий фрагмент codeа не удастся скомпorровать:

// E is not compilable unless it overrides performAction() as well
interface E extends B, C {
}

На данный момент, справедливо сказать, что Java How язык всегда пытался избежать угловых случаем an objectно-ориентированного программирования, но, так How язык развивается, некоторые из тех случаем стали внезапно появляется.

11. НАСЛЕДОВАНИЕ И КОМПОЗИЦИЯ

К счастью, наследование не единственный путь спроектировать ваш класс. Другой альтернативой, которая, по мнению многих разработчиков, является намного лучшей, чем наследование, — является композиция. Идея очень проста: instead of создания иерархии классов, их нужно компоновать из других классов. Давайте посмотрим на этот пример:

// E is not compilable unless it overrides performAction() as well
interface E extends B, C {
}

Класс Vehicle состоит из двигателя (engine) и колес (плюс многие другие части, которые оставлены в стороне для простоты). Однако, можно сказать, что класс Vehicle так же является machine (engine), так что может быть спроектирована с использованием наследования.

public class Vehicle extends Engine {
    private Wheels[] wheels;
    // ...
}

Какое решение проектирования будет правильным? Общие основные рекомендации известны How IS-A (является) и HAS-A (содержит) принципы. IS-A — это связь наследования: подкласс также удовлетворяет классовую спецификацию родительского класса и разновидность родительского класса (Прим. Переводчика: В книге Heading in Java принцип IS-A описан так: "Когда один класс наследует другой, мы говорим, что дочерний класс (подкласс) расширяет родительский. Если вы хотите узнать, расширяет ли одна сущность другую, проведите проверку на соответствие - IS-A (является).»). Следовательно, HAS-A — это связь композиции: класс владеет (or содержит) an object, который ему принадлежит. В большинстве случаем, принцип HAS-A работает лучше, чем IS-A по ряду причин:

Проектирование более гибкое;
Модель более стабильная, так How изменения не распространяются через классовую иерархию;
Класс и его композиция слабо связаны по сравнению с композицией, которая плотно связывает родителя и его подкласс.
Логический ход мысли в классе проще, так How все его зависимости включены в нем же, в одном месте.

Как бы там ни было, наследование имеет свое место, решает ряд существующих проблем проектирования различными способами, так что не следует им пренебрегать. Пожалуйста, удерживайте эти две альтернативы у себя в голове при проектировании вашей an objectно-ориентированной модели.

12. ИНКАПСУЛЯЦИЯ.

Понятие инкапсуляции в an objectно-ориентированном программировании заключается в скрытие всех деталей реализации (How режим работы, внутренние методы и т.д.) от внешнего мира. Преимущества от инкапсуляции в удобстве сопровождения и легкости изменений. Внутренняя реализация класса скрывается, работа с данными класса происходит исключительно через публичные методы класса (реальная проблема, если вы разрабатываете библиотеку or фреймфорки (структуры), использованную многими людьми). Инкапсуляция в Java достигается с помощью правил видимости и доступности. В Java, считается, что лучше всего никогда не выставлять поля напрямую, только посредством гетеров (getters) и сетеров (setters) (если поля не помечены How окончательные (final)). Например:

package com.javacodegeeks.advanced.design;

public class Encapsulation {
    private final String email;
    private String address;

    public Encapsulation( final String email ) {
        this.email = email;
    }

    public String getAddress() {
        return address;
    }

    public void setAddress(String address) {
        this.address = address;
    }

    public String getEmail() {
        return email;
    }
}

Этот пример напоминает то, что называется JavaBeans в языке Java: стандартные классы Java, написаны соответственно набору соглашений, один из которых дает доступ к полям только с помощью гетер и сеттер методов. Как мы уже подчеркивали в разделе наследования, пожалуйста, всегда придерживайте минимальному контракту публичности в классе, используя принципы инкапсуляции. Все, что не должно быть публичным - должно стать приватным (or protected/ package private, зависит от проблемы, что вы решаете). В долгосрочной перспективе это вам окупится, давая вам свободу в проектировании без внесения критических изменений (or, по крайней мере, минимизируют их).

13. ОКОНЧАТЕЛЬНЫЕ КЛАССЫ И МЕТОДЫ

В Java, есть способ предотвратить возможность класса стать подклассом от другого класса: другой класс должен быть объявлен How окончательный (final).

package com.javacodegeeks.advanced.design;

public final class FinalClass {
}

Это же ключевое слово final в объявление метода предотвращает возможность переопределения метода в подклассах.

package com.javacodegeeks.advanced.design;

public class FinalMethod {
    public final void performAction() {
    }
}

Нет общих правил, чтобы решить должен класс or методы быть окончательными or нет. Окончательные классы и методы ограничивают расширяемость и очень сложно думать наперед, должен or не должен класс быть унаследованным, or должен or не должен метод быть переопределен в будущем. Это особенно важно для разработчиков библиотеки, поскольку решения проектирования подобны этому могли бы существенно ограничить применимость библиотеки. Стандартная библиотека Java имеет несколько примеров окончательный классов, причем наиболее известный - это класс String. На ранней стадии, было принято данное решение, чтобы предотвратить любые попытки разработчиков появиться с собственным, «лучшим» решением реализации string.

14. ЧТО ДАЛЬШЕ

В этой части урока мы рассмотрели концепции an objectно-ориентированного программирования в Java. Мы также кратко прошлись по контрактному программированию , затронули некоторые функциональные понятия и увидели, How язык развивался с течением времени. В следующей части урока мы собираемся встретиться с generics и How они меняют способ приближения типовой безопасности в программировании.

15. СКАЧАТЬ ИСХОДНЫЙ КОД

Скачать исходник вы можете тут — advanced-java-part-3 Источник: How to design Classes an

Mga komento

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION