Programowanie obiektowe - zadanie

Programowanie obiektowe - zadanie
NU
  • Rejestracja:ponad 3 lata
  • Ostatnio:ponad 3 lata
  • Postów:3
0

Witam,
niedawno dostałem kolejne zadanie do wykonania, z którym mam pewien problem. Tym razem zadanie dotyczy programowania obiektowego ( a w zasadzie to jego podstaw, bo jak pisałem jakiś czas temu w poście na temat innego zadania, dopiero się uczę ) i pewnego błędu, którego muszę się pozbyć, a nie mam pojęcia jak bo nie rozumiem z czego on może wynikać.
Zadanie polega na tym, żeby stworzyć abstrakcyjną klasę Figura, która zawiera dwie abstrakcyjne metody ( double pole() i double obwod() ), a następnie trzy kolejne, dziedziczące po klasie Figura, klasy ( Kolo, Kwadrat i Prostokat )
Każda z nich ma zawierać:

prywatne pola określające wielkość figury (długość boku, promień itp.) pozwalające na obliczenie pola i obwodu tej figury

konstruktory (po dwa dla każdej figury); Jeden bez parametrów (inicjuje pola dowolnie przyjętymi wartościami domyślnymi) oraz drugi z parametrami inicjującymi odpowiednio pola określające wielkość figury.

implenetację metod:
a) double pole()
b) double obwod()

Napisałem kod, który wydawało mi się, że powinien działać bez zarzutu ( jednak wyszło jak zwykle ... ) i wygląda on tak:

Kopiuj
package obiektyzadanie2;

import java.util.Scanner;

public class ObiektyZadanie2 {

    public static void main(String[] args) {

        Scanner sc = new Scanner(System.in);

        Figura kolo = new Kolo();
        Figura kwadrat = new Kwadrat();
        Figura prostokat = new Prostokat();

        System.out.print("Podaj promień koła: ");
        double r = sc.nextDouble();

        double poleKola = kolo.pole(r);
        poleKola *= 100;
        poleKola = Math.round(poleKola);
        poleKola /= 100;

        System.out.println("Pole koła wynosi: " + poleKola);

    }
}

abstract class Figura {

    abstract public double pole();

    abstract public double obwod();

}

class Kolo extends Figura {

    private double promien;

    public Kolo() {
        this.promien = 5;
    }

    public Kolo(double r) {
        this.promien = r;
    }

    @Override
    public double pole() {
        return Math.PI * (this.promien * this.promien);
    }

    @Override
    public double obwod() {
        return 2 * Math.PI * this.promien;
    }
}

Nie jest to pełny kod, a jedynie ta najważniejsza część, która dotyczy tylko Koła, bo przy wszystkich pozostałych figurach błąd jest dokładnie taki sam i najprawdopodobniej wynika z tego samego, co w przypadku Koła, więc jak uda mi się poprawić to co jest nie tak tutaj, będę też w stanie poprawić resztę ( a przynajmniej tak mi się wydaje ).

Problem jest w tym, że kiedy w Mainie wpisuję " double poleKola = kolo.pole(r); " wyskakuje mi poniższy błąd:

error: method pole in class Figura cannot be applied to given types;
double poleKola = kolo.pole(r);
required: no arguments
found: double
reason: actual and formal argument lists differ in length "

Działa to dopiero kiedy usunę "r" z nawiasów i zostawię samo " kolo.pole() ", z tym, że działa, ale na tej wartości, która miała być domyślną.
Nie rozumiem dlaczego nie chce mi to działać kiedy próbuję podać ten promień z klawiatury i byłbym ogromnie wdzięczny, gdyby ktoś wytłumaczył mi "jak krowie na miedzy" czemu nie działa tak jak chcę, z czego ten błąd wynika i jak to naprawić.

edytowany 2x, ostatnio: Riddle
szweszwe
  • Rejestracja:ponad 11 lat
  • Ostatnio:12 dni
  • Lokalizacja:Kraków
  • Postów:1694
3

Przekazujesz argument do funkcji która jest bezargumentowa. Cała filozofia.
Masz w Kolo c-tor który przyjmuje promień to go użyj.

Kopiuj
Kolo kolo = new Kolo(r).
kolo.pole();

i będziesz miał co chcesz.

edytowany 1x, ostatnio: szweszwe
Grzyboo
  • Rejestracja:ponad 9 lat
  • Ostatnio:5 miesięcy
  • Postów:206
1

Proponuję wziąć w ręce książkę, albo otworzyć PDFa książki, który tłumaczy podstawy programowania obiektowego.

Stworzyłeś koło

Kopiuj
Figura kolo = new Kolo();

o promieniu 5, bo w bezargumentowym konstruktorze ustawiasz promień tego koła na 5.

Kopiuj
public Kolo() {
    this.promien = 5;
}

więc wywołanie kolo.pole() obliczy pole dla promienia 5.

Natomiast kolo.pole(r) nie zadziała, bo nie ma prawa zadziałać. Zdefiniowałeś, że metoda pole przyjmuje zero argumentów (i dobrze), więc dlaczego próbujesz mu pchać jakiś argument?

lion137
  • Rejestracja:około 8 lat
  • Ostatnio:około 2 godziny
  • Postów:4935
2

Kompilator cię informuje, co robisz źle, przekazujesz do funkcji, pole argument, a nie powinieneś. sygnatura: public double pole(). Możesz tworzyć koło z promieniem, który przekazujesz, jako, r, i wtedy policzy co chcesz, co będzie zgodne z opisem zadania:

pozwalające na obliczenie pola i obwodu tej figury


Riddle
Administrator
  • Rejestracja:prawie 15 lat
  • Ostatnio:minuta
  • Lokalizacja:Laska, z Polski
  • Postów:10085
2

Wpisanie

Kopiuj
kolo.pole(r);

jest bardzo nieobiektowe. kolo powinno samo znać swój promień, nie powinieneś go przekazywać przez parametr funkcji pole(). Poza tym zauważ, że zarówno kwadrat.pole() jak i kolo.pole() mają mieć taką samą funkcję, więc nie mogą się różnić sygnaturą.

Zobacz pozostałe 4 komentarze
Riddle
Danie wegetariańskie to danie bez mięsa. Nie można sobie zamówić miesnego dania i mówić że ma cechy wegetariańskie; podobnie jak nie można napisać nieobiektowego kodu i mówić że ma "cechy obiektowe". Absurd.
Riddle
@Silv: Jeśli weźmiesz jakiś program, napisany funkcyjnie, i napiszesz w nim linijkę która reassignuje zmienna, to w tym momencie masz niefunkcyjny kod. 99 linijek zupełnie funkcyjnych, ale przez to że zrobiłeś reassign on już nie jest funkcyjny. Tak samo jak z daniem, możesz mieć całą michę warzyw, ale jak dorzucisz chociaż kawałek mięsa, to już nie jest wegetariańskie. Takim kawałkiem mięsa jest przekazanie promienia przez parametr.
Silv
OK, przykład całkiem rozsądny na obalenie mojej tezy. :) Zgodzę się, że nie raczej nie powie się "danie pół-wegetariańskie" z uwagi na pewne ograniczenia. Przykładowo ludzie chcą być pewni, co zamawiają, nie chcą bawić się w domysły, "co poeta piszący menu miał na myśli". Natomiast w programowaniu widzę inne ograniczenia, niezwiązane z tym, jak określa się dany styl pisania kodu. Więc jeśli dla Ciebie "programowanie obiektowe" zawsze oznacza to samo, to ja się z Tobą zgadzam. Natomiast wydaje mi się, że jeśli zechciałbyś przyjąć inną definicję, też mógłbyś.
Silv
Generalnie dobrze jest umieć uzasadnić, dlaczego dany fragment kodu może być uznany za obiektowy (czy funkcyjny), a inny nie. Nie chciałbym wchodzić w dyskusję "nazwać to A czy B". Jeśli Ty uznajesz to za programowanie "nieobiektowe", w porządku. Ostatecznie liczy się, czy program działa bez błędów. :)
Riddle
@Silv: Jeśli ma wskaźniki na funkcje to nie jest obiektowy, jeśli nie ma enkapsulacji to nie jest obiektowy, jeśli funkcja jednocześnie modyfikuje obiekt i zwraca wartość to nie jest obiektowy, 95% przypadków kiedy klasa nazywa się "-er" (Manager, Controller, Validator, Sender, Updater) to nie jest obiektowy, etc.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.