Answering those questions each and every time will have students practise looking at a problem with "OO eyes". It will naturally have them work with aggregation, inheritance and polymorphism.
As the resource included below hopefully demonstrates, it is quite easy to come up with simple and intuitive examples.

The first four weeks of teaching Computer Science I in the suggested object-centered fashion are sketched out below. Several concrete object classes, specified in C++, are included as sample resources. Two things should be noted here. (1) You may view the use of C++ as a notation/shorthand to allow a less verbose presentation of the ideas. (2) You may view the bits of C++ code as parts of concrete class/lab exercises that demonstrate how in informal examination of objects in some problem domain is being translated into the syntactic constructs of a concrete programming language (Contrary to some, I believe that learning about syntax (which is generally agreed on as being the "easy part") does not have to be in the way of teaching design; the successful compiling and running of a program can be seen as valuable verification of one's design.)

Week-1:

The class informally discusses the notion of an "object" as we know it from our daily experience with the physical world. The instructor may bring along some artifacts and let students describe them. Discover that many objects are composites, and are readily described in terms of their parts and properties. Looking ahead to subsequent lectures, students may also be instructed to discuss the kinds of behaviors (= things to do) that different kinds of objects are expected to exhibit. The discussion should be held at an informal level that allows all students to contribute.

Next discuss the notion of a "program" as a set of instructions that will have the computer manipulate data (= pieces of information = objects) to arrive at solutions to a given problem. A program needs to be informed of the kinds of objects (parts and properties) to manipulate. Since computers are not capable of understanding natural languages, objects are described to the program in a socalled programming language, C++ being one of many options. The previously informally discussed description of a type of object is now written out using programming language syntax. At this point, students are also taught that the programing language knows about several basic types of objects, from which all composite objects are to be built. These basic types are int, float, char etc.

An example for a resource for Week-1 defines a "house for sale" object that lists the number of bedrooms, square feet, asking price, address etc. as parts and properties. The corresponding class definition is kept simple in that all parts and properties are basic types of objects, and declared public (a minimal explanation of public should suffice at this point).

Week-2:

The House_for_object is reexamined, and the discovery of other parts of the house is encouraged. Students will be led to suggest parts that are not representable as basic objects but are objects in their own right. For example, the house for sale can come with a garage (described in terms of how many cars it fits), and appliances (described as being of a brand name, and either powered with electricity or gas). Let students experience how new objects Garage and Appliances are defined in analogy to House_for_sale.

Effectively, the notion of aggregation has been introduced. In addition, it is fairly easy to lead over to the basics of encapsulation. At this stage, suffice it to say that parts and properties defining an object are precious and vulnerable to corruption (how about somebody indicating a negative number of bedrooms, or filling in some fantasy brandname?). Labeling parts and properties as protected will safekeep the state of an object.

Once the defining parts of an object have been rendered invulnerable, they have also been rendered inaccessible. Lead students to understanding that a carefully crafted interface will allow us to access and manipulate the parts and properties of an objects in a fashion that is intentionally restrictive; it allows only what is needed and meaningful, and disallows acts of corruption. The interface will initially be minimal and consist of exactly two member functions (= "behaviors") per part or property: one function that allows the assignment of values to the part, and one function that allows the access/retrieval of the part's value.

Week-3:

Week-2 will have motivated the notion of a function. While other types of functions exist, no harm is done in letting students believe that a function is something that an object "does". In fact, the lack of any alternative to OO will counteract the development of non-OO programming habits from the start (... there will be no "big main()", and their won't be function calles other than calls to member functions; that in turn means that all data has been conceptualized and designed as objects).

Staying with the design of a House_for_sale object, students will find the interface too restrictive. Encourage the discovery of other meaningful member functions. For example, suggest that the house be able to avertise itself. A new member function House_for_sale::advertise() could print out a brief statement such as "This beautiful new home has 4 bedrooms and ...". Notice that beyond the syntax for class definitions and member functions, only standard input and output have to be taught which leads to inevitably very simple member functions. Next encourage students to discuss in more discriminate terms what kinds of houses may be up for sale. The notion of a "fixer-upper" may come up. Let students discuss the notion of a "fixer upper" compared to the earlier notion of a house for sale. Are there differences? Let students discover, that all parts and properties describing a house for sale, also apply to a fixer-upper, yet there is additional information that is typically provided along with the latter (e.g., the year it's been built, and whether it has lead paint and asbestos). Conclude Week-3 by having students write a C++ specification of Fixer-upper in analogy to the most recent definition of class House_for-sale.

Week-4:

Discuss with students how it felt to be writing the specification for a class Fixer_upper. Did they find it repetitive at all? Would they want to repeat this experience for other types of houses on sale? Wouldn't it be nice, if you could tell the program that Fixer_upper is just like House_for_sale with some additional features? Having thus triggered their curiosity (and fed their budding discontent with the repetive exercise), they will be receptive to the notion of inheritance. A Fixer_upper can indeed by defined as a specialized subclass of House_for_sale, and not much additional syntax to express this relationship is needed. Demonstrate to students how easily the subclassing is expressed, and stress the convenience of having to add C++ specifications for only the additional features of the subclass.

Now examine the subclass Fixer_upper more carefully. It inherits all parts, properties and member functions from its superclass House_for_sale which is a good thing, except ... Point out that Fixer_upper also inherits member functions House_for_sale::advertise(), and that the function effectively advertises the object as "This beautiful new home ...". . This is clearly inappropriate for objects in the fixer-upper subclass. A fixer-upper should still be able to advertise itself, and the inheritance of this capability makes perfect sense. However, the messsage of the advertisement should be a different one. After students have appreciated the discrepancy, they will be receptive to the possiblity of redefining the message. Teach students that the inherited member functions advertise can be {\em overwritten} as part of defining Fixer_upper. The function retains the old (and entirely appropriate) name, but its body is changed to, say, "This affordable fixer-upper with great potential ...". And thus, at the week of Week-4, we have covered basic forms of polymorphism. The rest is reinforcement... Other standard topics of programming (conditionals, iteration, arrays, pointers, etc.) can now be taught in the usual sequence, but with the added motivation of allowing the expression of more sophisticated object behavior.